![](https://secure.gravatar.com/avatar/9ae4ce9eef0ed502005163f51792af3a.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). 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.
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.
I'll look forward to checking it out.
But I wonder if you've a good data-acquisition module. I've one now (can use Soundcard , some NI-modules and several dedicated DAQ cards), but it's in fact a windows executable that I can control from Python.
Our data-acquisition modules are designed around the specific data/hardware we work with and hence are not particularly generic. I tend to write wrappers for C-based device drivers as required. We have a near-complete SWIG-generated wrapper-set for the (now obsolete) NI-DAQ drivers. Comedi (the linux DAQ-card drivers) already come with python wrappers. I couldn't get SWIG-wrappers for NI-DAQmx (the new driver API from NI) to build but now use a ctypes interface for the bits of the API we need. In fact, we've just migrated all our main driver-wrappers to ctypes. The benefit of not having to recompile C-code for each python version / platform outweighs the disadvantage of having to write/maintain the wrappers manually (as compared to auto-generation from header-files). I'm always happy to discuss this topic so if anyone want more details drop me an email. 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. 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.
And of course I', looking for a more OS-indepedant solution.
Amen. cheers, Bryan
cheers, Stef