Slashdot Mirror

So the real question is, what DAQ's are available for python.

Comedi provides Python bindings.

I work in a laboratory - a wind tunnel and I don't think the problem is too much specialization. I don't know what the guy's setup is but from my point of view the problem is hardware support. Most hardware manufacturers simply do not acknowledge that there is an OS different from windows and for these guys open source / free software is a completely alien concept.

So basically, if you want to use free software you are going to have to do it all on your own. From low level hardware drivers (with no support or help whatsoever) up to libraries and high level environments.

But do you know what is interesting? At our lab we have some old equipment (30-40 years old) and they all have service manuals that usually includes electronic circuits diagrams. Basically you had all the information to fix anything. But now the only option available is to send the instrument to the manufacturer and hope they are in the mood of fixing it.

Software? It is a disgrace usually. You by a $200.000 equipment and you get a software that handles the instrument pretty well but does nothing else (how do you interface with anothe equipment???) and the damn software includes a hardware key!!! I ask myself who would "pirate" this software? It is useful only with the equipment the company sold for tons of money and nothing else. I mean you already payed a small fortune for it!!! Often they do not provide an API so that you can try to interface the software with another environment. This drives me insane!

Why do we still by equipment from this company? The first reason is that I will usually have the same problem with other options. Another reason is that most of these equipments are expensive so you have to make sure it will work and the best way to ensure this is to get the same stuff some other lab you know uses.

All this could change is there was an awesome open source environment. But here is the catch: most experimenters I know are very poor programmers. But there is light in the end of the tunnel there are projects like http://www.comedi.org/ that provides drivers for DAQ cards. National Instruments has binary only linux drivers for some of their boards.

Just yesterday my boss agreed to release as open source some code I'm developing. It is basically interfaces to the R (http://www.r-project.org/) environment. Much of it is very similar to matlab's daq toolbox. For now I will mostly be using the code on windows (since many instruments we have do not offer any other option) but I will try to slowly migrate to Linux or some other free environment.

obviously their userbase already have a strong interest in Linux.

If so, they sure are ignoring us. The last release of their Linux driver package (NIDAQ) was in 2005. Installing it on a recent version of Linux proved practically impossible. Finally after a few days of installing and reinstalling different distros I got it working on a 2-year-old version of SuSE. But basically determined that outside of personal use, this is totally impossible to expect customers to use if we are to integrate an NI board into our product.

Finally discovered that their "register-level driver" is way more efficient and easier to integrate into a software package. Even open source! We're using it and are happy with it, but unfortunately due to the fact that they are using a "BSD license" (although it doesn't actually say that anywhere on the product, they confirmed it in a forum post.. the software just says "copyright national instruments") GPL-incompatibility issues are stopping us from adding new features, like for instance having it play nice with udev.

After contacting them they seemed interested in rectifying the issue but since seem to have dropped it.

I dunno, they just don't seem to be able to keep up with Linux. You'd think compiling against the latest distro and putting out a driver update or two in a 2-year period wouldn't be so hard for a company that's all about hardware.

A good side of course is that their hardware is fully documented. It's possible that a community effort like comedi is just a better solution in the long run. But I'd prefer it even more if there were an effort to get a standard interface for multifunction DAQs into the Linux kernel. Basically, the OSS model of long-term reliability is to play well with others and contribute your drivers to a larger project instead of trying to do everything yourself. That way everyone helps to port things forward when interfaces change. I wish more companies would realize this, but instead they fall back to NIH syndrome over and over again, making more work for themselves than necessary, and complaining that Linux support is too hard.

Meanwhile, is it _really_ necessary for the Windows driver package to be a freaking 1 GB DOWNLOAD!? When all I need is a couple of DLLs and some header files.

Alright, I'm replying because I figure I can help you stop assuming the worst in people. I don't know exactly what I said in my post that would give you the impression that I'm a liar, but just because you didn't have the same experiences I have doesn't mean I didn't have mine. Plus I wasn't insulting gcc or autotools. In Linux, I don't really use an IDE, so they're what I thought of as "dev tools". It's great, and it's not always backward compatible, so we try to keep all devs using the same tools to avoid problems.

I ran into problems where some syntax that used to be allowed in gcc 3.x, but is no longer allowed in gcc 4.x as they become more standards compliant (a long time ago, we're all running 4.x now). So someone can write stuff that works for them, submit it, the people running 4.x try to compile it, it doesn't work. Yeah, not writing standards code is bad, but it's a problem that's solved by everyone running the latest compiler that forces you to write more standard code, right? Oh yeah, you're a skeptic...an example of a project (not mine) that doesn't compile in gcc4, but compiles in gcc3 is qemu. You can go try it out yourself.

autotools are only needed to create the configure script. You should not need to create the configure script yourself to compile the program.

So, bullshit.

The program in question was comedi. You can download the cvs snapshot and notice that they give you autogen.sh and configure.ac, but you have to generate the configure script yourself. I don't know why they do it, and I really don't mind, I can run an extra script. I wasn't lying and I don't know why you'd automatically assume I was.

When it comes to hard RT extension (even in userland), I tend to prefer Xenomai over RTAI. Xenomai has better non-x86 support (ARM is there), nifty so-called skin support for legacy API's (VxWorks, uITRON, ..), and very good community.

Talking about distro, ELDK is best what comes to mind. This is industrial grade software, free as in beer and speech, but with commercial support if needed. The toolchain is excellent. What goes into the flash image must be hand-picked because only you know the necessary stuff.

If you are in D/A A/D business, then have a look at Comedi, it is also RT enabled by the comedi-rtdm project.

All these tools/projects are used and backed by industry. I'm a simple user of these tools, and they make my day life happy.

It's free (as in freedom AND beer), and it works pretty well, especially with I/O cards that are supported by comedi drivers, which are designed with real-time use in mind.

We use them for our real-time HIL simulations at my department, and we're happy with the results.

Have you checked out COMEDI?
(http://www.comedi.org/)

Comedi is a generic programming framework for most current DAQ-boards. If your board is obsolete, but still have the HW-specs for it, writing a driver is always possible. The package includes examples for how to accomplish this.

Further; if you need RT-scheduling, it supports RTAI.

For that lab equipment you need to interface to, check out Comedi. The equipment might be on the list.

Inserting trends is done by highlighting the graph on which you have graphed your points and then going to Insert|Statistics. The regressions are only available on the XY chart type. I found this out by going to help and typing "trend line" in the search field.

The clipboard thing is getting really old. If you want to use apps with consistent cut and paste, use only KDE and GTK apps. They are unified now. Of course, if you are using an app that is unaware of their clipboard, use the old highlight and middle click thing. It's not a hard rule to explan --- the old apps look old anyway, so its easy to say, well the old apps are different. Just like old Windows apps (anyone remember those funky Delphi widgets?)

Not necessarily true. I work on research for the university I study at, and the particular branch I work on uses comedi drivers to interface with our pci data acquisition boards. Take a look, it might support what you're using.

Many things people would ordinarily think linux can't do is already, or will one day be possible, so keep looking. A lot of people tend to think you can't do real-time work on Linux, because it's not a real-time kernel "like windows nt", but we do it with a patched RTAI kernel too. My advice is to research what you need, in any operating system. Check out all your options, and choose what's best for you.

I've found it somewhat difficult to use since building their modules is really suggested on a generic rather than stock Redhat kernel (and building with what are claimed to be the RH sources and config files didn't work for me).