The structure of a Lantz Driver

Lantz is a Python automation and instrumentation toolkit that allows you to control scientific instruments in a clean and efficient manner writing pure Python code.

All Lantz drivers classes are derived from Driver, which provides the infrastructure and boiler plate code to perform common operations. Logging, timing, async calls and other features are enabled by sub-classing from Driver.

But usually you do not subclass from Driver directly, but rather from a specialized class depending on the way you communicate with your instrument. For example, if the instrument is controlled over RS-232 (Serial), you sub-class from SerialDriver. If it is controlled over TCP, you sub-class from TCPDriver. There is also a class for GPIB and there be soon will for USB.

All these classes belong to the same family as they communicate with instruments by exchanging  textual messages. They share a common interface and therefore it is very easy to build drivers that support different communication channels:
Loading ....




Of a different kind are instruments that are controlled by calling function in a library (e.g. a ,dll or .so). Typical examples for these are cameras and acquisition boards (under the hood, they also exchange messages but the library handles that). In this case, you driver will sub-class LibraryDriver which provides a simple and cross platform way to perform library calls.

Other important pieces of Lantz are Feat, DictFeat and Action. We will discuss those in future posts.


What's new

  • New multi device example (Thanks to Pablo Jais)
  • Better support for units in Qt Widgets (Thanks to Martín Masip)
  • Preliminary support for NI-DAQmx 
  • Support for NI-VISA in Windows (Thanks to Martín Caldarola)
  • get-lantz.py installation script to simplify installation in Windows

There are still a lot of things to do, but Lantz is already very useful. Join us! 

What's next

  • Complete NI-DAQmx support
  • Better support for async execution in GUI using Qt Threads
  • Qt Signal/Slots like syntax for events
  • More drivers!
  • [put your ideas here]

For more details take a look at the tutorials.

... and tell us what are you doing and how we might help.

Project documentation: main server and GitHub mirror

Public source code repository: GitHub

Comments

  1. Hi Hernan,
    It's the first time I hear about Lantz, and it looks very interesting. I work at Delmic, a start-up company that focuses on microscopes. We have started developing a software for our microscopes, and it shares quite a few goals common with Lantz.

    The software is called Odemis, it is also written in Python, and licensed under the GPLv2. It's available there: https://github.com/delmic/odemis . It's made mostly of 3 parts: the drivers, the back-end, and the GUI. We also have support for the Andor SDK2 and SDK3, but also Physik Instrumente piezo motors, and Lumencor light engine. Who knows, maybe one day you need to support such hardware, in which case don't hesitate to have a look at our implementation :-)

    I had a quick look at the tutorial and API. You've really done a nice job. Not only is it pretty well documented, but also I like the usage of the decorators for the Feat and inheritance. The automatic unit conversion is also pretty cool (although I'm not sure I'd fully trust it, I prefer to enforce the usage of standard units everywhere). Unfortunately, for now the documentation of Odemis is not very thorough (partly because we are still in beta, with an evolving API). One thing, I'm happy with our design is the ability to run every driver in a separate process and see everything (almost) like a normal Python object. It's based on Pyro and 0MQ. Also, we have the notion of VigilantAttributes, a bit similar to your Feat but to which it's possible to "subscribe" so that code can be called-back when the value changes.

    I'm also going to try to support NI DAQ cards in the soon future. However, I'd rather try to use Comedi instead of the NI SDK. It should permit less dependence on NI (both in respect to hardware, and software support). Have you considered it as well? Were there specific short-comings?

    Best,
    Éric Piel

    ReplyDelete

Post a Comment

Popular posts from this blog

Communicating with instruments using PyVISA but without NI-VISA

Moving to Lantz

PyVISA-sim. Test your PyVISA applications without connected instruments