![](https://secure.gravatar.com/avatar/0e31f673b2f054ea61da64e35bd52cc0.jpg?s=120&d=mm&r=g)
Hi Stef,
unfortunately you're not able to post your code, (btw why not ?)
Although I started developing the plot-widget in my own time (I did publish this first version on my home web-site (now defunct due to lack of time)), development continued at my workplace over 2 years or more now so now the code ownership is ambiguous. The best plan is for me to get permission to release the code. Unfortunately, upper management are a bit suspicious of OSS at my workplace. I'm working on this...
but maybe you can answer a few questions ....
Bryan Cole wrote:
Hi,
I'm an ex-LabView user, now using python for lab data-acquisition and analysis for some years now. It's well worth the switch.
I'm too a former MatLab / LabView user, and I'm quit happy with Python / Scipy / wxPython for now. At the moment I'm trying to write an open source LabView equivalent, first results can be seen here:
http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_animations_screensho...
Your best bet is
Nice work. I must confess, I'm not a huge fan of the "graphical programming" concept (otherwise I'd probably still be using labview). I don't think LabView and Visual Programming are identical. In my humble opinion, LabView violated against some vey basic rules,
Bryan Cole wrote: like flattness of information, and uniformity / simplicity.
My wish would be a nice set of technical widgets (plots, knobs, sliders, gauges etc.) which are 1) documented and 2) integrated with a wxPython GUI-designer like wxGlade. In fact, a "technical edition" of wxGlade with such things integrated would make creating data-acquisition application easy to the newcomer without compromising flexibility.
the you're lucky, ... ... I tried to get wxGlade running on 2 different machines, both failed ;-)
I'm in the middle of writing a real time plot widget, based on direct canvas drawing, don't know yet how fast it is. I hope to make a video of it next week.
The NI-DAQmx drivers probably represent as good a data-acquisition API as you'll get. It's pretty much a 1:1 mapping to LabView nodes. The task-based approach is easy to work with although the NI documentation is far from perfect. You could make NI-DAQmx task nodes for your pylab_works framework. If you need cross-platform, re-implement the required functionality on linux with Comedi.
NI-DAQmx would be a good standard, and I think I've even seen a Python wrapper for it, but I can't find it anymore. In fact the windows program I use in PyLab_Works also contains a NI-DAQmx wrapper.
The main recommendation I would make to anyone writing data-acquisition stuff in python is Use Traits/TraitsUI! The ability to auto-generate a GUI to configure hardware objects based on their Traits definitions is a *huge* productivity saving.
You might be quit right, I've heard this reasoning more than once, but .... ... I'm looking at the wrong documents or ... I'm simply too stupid or ... I'm a completely spoiled windows user but I really really don't understand one bit of Traits :-( cheers, Stef