search

LabPy / lantz

Lantz is an automation and instrumentation toolkit with a clean, well-designed and consistent interface. It provides a core of commonly used functionalities for building applications that communicate with scientific instruments allowing rapid application prototyping, development and testing. Lantz benefits from Python’s extensive library flexibility as a glue language to wrap existing drivers and DLLs.
http://lantz.readthedocs.org/
Other
135 stars 65 forks source link

nidaq driver is very rudimentary #37

Open vascotenner opened 9 years ago

vascotenner commented 9 years ago

The NIDaqmx driver to talk with daq cards from national instruments is not working. Some functions a written, but untested.

There are some nidaq wrappers written already, but non of them is running with python 3 out of the box.

I like pylibnidaq, because it has a more or less "high-leve" api; https://code.google.com/p/pylibnidaqmx/ I just made some adjustments to to source, so that this project runs on python3: https://code.google.com/p/pylibnidaqmx/issues/detail?id=39

Can someone comment how we could implement this wrapper in the lantz framework? The cleanest solution would just be to import this module, however, I can imagine that in order to get is neatly in the lantz framework, some additional tweaks are necesary.

hgrecco commented 9 years ago

I think it is good to have a few guidelines for this. We should:

The first thing is to decide if pylibnidaqmx is the right choice. I agree with your assessment but I am not sure how active it is. In any case, we could collaborate with it (if the project leaders agree, of course) And in fact you have already by providing Python3 compatibility. If they accept the contribution, we can go forward.

Going to the wrapping. We tried to wrap Tasks and Channels in the past but did not worked very well for the final users. It was a good idea but was just too low level. The difficult but interesting thing about DAQmx is that tasks go beyond single instruments. This allows you to do complex stuff, but at the same time breaks the abstraction that we use in Lantz (1 instrument = 1 object). However, in my experience, there are lot of "single DAQ" uses and therefore my suggestion would be to provide those common scenario solutions.

Some wild thoughts: I think we should start by wrapping a device (in a similar way to what is done in drivers/ni/daqmx/base.py) but proving DictFeats for analog/digital input/outputs, and certain methods to create tasks on the fly for common operations. All these should leverage from pylibnidaqmx.

Because DAQmx has good introspection capabilities, we could create drivers on the fly. In other words, we do not need to create a NIXXXX class for all possible values of XXXX. We just need to have a functions that create the class or an object on demand based on introspection.

My suggestion would be (this is how I usually design an API): write an application using Lantz with DAQmx. Not the one we have, but the one you would like to have. The implementation will follow.

claypipkin commented 9 years ago

Just curious... was any progress made on this? I just discovered Lantz and am trying to get it to communicate with my ni9234 daq without much luck.

hgrecco commented 9 years ago

There is not. I would love to move forward in this direction but I have my hands full at the moment. Sorry

vascotenner commented 9 years ago

There is a working pyhton3 version of pylibnidaqmx: https://code.google.com/p/pylibnidaqmx/issues/detail?id=39 It has not been merged yet to master. I'm using it, but did not include it in the Lantz framework. I read only one channel at the time, or write to an analog output