cDAQ-9188 with Linux

[Eric111]

Hi, the cDAQ-9188 chassis is ideal for my application.  Since it is ethernet based, I was hoping that there was a well-defined packet format and that I could just write a UDP application to configure the DAQ and then receive the data and post process it (this is how the LabJack UE9 works, for example).  However, as far as I can tell, this is not the case, and NI proprietary code is required to collect data from the 9188.  Does anyone know if there is a way to use this chassis with Linux?  We have a large automated test infrastructure built around Linux, so Linux support is essential.

Thank you.

- Eric

[Tom_W_[DE]]

Hi Eric-

Unfortunately, as you have observed, the cDAQ-9188 communication protocol is too complicated to effectively document, and NI does not currently plan (as of May 2011) to release Linux driver support in the foreseeable future. 

One suggestion, depending on your I/O and timing needs might be to have a Windows box running NI-DAQmx that is configured to publish single-point data via the DAQmx I/O Server and then consumed via OPC or similar on your Linux servers.  If this sounds interesting I would suggest that you review the MAX-based configuration described here.

Alternatively, you could use PXI DAQ with an RT system using the LabVIEW RT Hypervisor.  This basically lets you run some of the newest PXIe hardware (for example, PXIe X Series multifunction DAQ) on a dual-core PXIe controller where the second core runs Linux and could plug into your existing infrastructure.

One last option that comes to mind would be to use NI-DAQmx 8.0.x for Linux and use some of the older NI DAQ hardware (for example, PCI or PXI M Series multifunction DAQ) to achieve the same effect on a more standard Linux-based PC.  There is a lot of chatter in this forum from various users that have been successful in getting NI-DAQmx up and running on various newer distros.

We are always interested in improving our Linux support, but the market demands are sometimes difficult to gauge.  If you haven't already done so, please engage your local NI Field Sales Engineer and pass the needs of your application to him so that we can get better feedback for future support needs.

Hopefully this helps-

Tom

NI R&D

[Eric111]

Hi Tom, thanks for the fast and helpful response.  Please see inline:

TomW[DE] wrote:

Hi Eric-

Unfortunately, as you have observed, the cDAQ-9188 communication protocol is too complicated to effectively document, and NI does not currently plan (as of May 2011) to release Linux driver support in the foreseeable future. 

I had just assumed it was proprietary for the sake of being proprietary.  I deal with many very complicated network protocols in my work (eg RFC 5050) and all can be effectively documented.  The fact that it can be coded seems to be proof of this.

One suggestion, depending on your I/O and timing needs might be to have a Windows box running NI-DAQmx that is configured to publish single-point data via the DAQmx I/O Server and then consumed via OPC or similar on your Linux servers.  If this sounds interesting I would suggest that you review the MAX-based configuration described here.

I thought of this, but we can't deal with the additional overhead of managing another machine, particularly a Windows machine.  It's easier to just buy a Linux-capable DAQ, even if it's not as nice and high-quality as NI's hardware.

Alternatively, you could use PXI DAQ with an RT system using the LabVIEW RT Hypervisor.  This basically lets you run some of the newest PXIe hardware (for example, PXIe X Series multifunction DAQ) on a dual-core PXIe controller where the second core runs Linux and could plug into your existing infrastructure.

This seems like something worth looking into.  I'll have to look into how the cost/features compare to the 9188.  We're pretty allergic to LabVIEW here, so I'm not sure that would fly unless it's just being used to relay the data to the Linux side.

One last option that comes to mind would be to use NI-DAQmx 8.0.x for Linux and use some of the older NI DAQ hardware (for example, PCI or PXI M Series multifunction DAQ) to achieve the same effect on a more standard Linux-based PC.  There is a lot of chatter in this forum from various users that have been successful in getting NI-DAQmx up and running on various newer distros.

Hmm, the fact that this is supported by forum chatter seems to indicate that either the driver is rather old or is half-baked.

We are always interested in improving our Linux support, but the market demands are sometimes difficult to gauge.  If you haven't already done so, please engage your local NI Field Sales Engineer and pass the needs of your application to him so that we can get better feedback for future support needs.

Having worked with many DAQs in the past, I can say this is a perennial problem with NI.  Great hardware, but lacking Linux support.  IMHO I suspect you may not be getting a full view of the potential market since your products seem to be targeted primarily at scientists as opposed to EE/CE people.  From my experience, the perspective in the EE/CE community is that NI hardware isn't even considered for the following reasons: 1) It is viewed as being intricately tied to LabVIEW (not trying to start a flame war, but right or wrong most people I know who are comfortable with conventional programming languages detest LabVIEW), 2) lack of Linux support, particularly in ethernet-enabled DAQs for which there really is no reason to require proprietary drivers and 3) perceived high cost (I say perceived because it seems newer products like the 9188 offer very competitive value for the money).

Hopefully this helps-

Tom

NI R&D

[Tom_W_[DE]]

Hi Eric-

Thanks for the additional perspective.

I can agree with you that ethernet protocols themselves need not be overly complicated.  In truth, it is the complication in the embedded protocol for all cDAQ devices that is really of concern.  Couple that complication with some business-minded protection for some patent-protected and patent-pending technologies in those embedded protocols and you end up with an uphill challenge to cleanly documenting the behavior.  I can see how this is frustrating to end users,  but hopefully you can appreciate NI's perspective on this.  We are trying to find new ways to make these devices accessible on non-Windows platforms.

I agree that LabVIEW has a polarizing effect.  Most NI employees are fans (naturally) and we have many rabid users in the community.  Of course you are entitled to your own opinion, and I'll leave the sales pitch to your local NI sales engineer.

I wouldn't say that healthy user interaction with NI-DAQmx for Linux points to it being poorly-maintained so much as it is a vindication of the versatility of Linux users and growing strength of that community's interest in NI products.  Yes, the NI-DAQmx core binaries are a few years old, but we have been able to largely keep it viable through ongoing efforts (in NI-KAL, et al) to maintain compatibility with ever-changing Linux APIs.  We had a hiccup with some kernel API deprecations a year or so ago, but all indications are that NI drivers are back in the saddle again. 

I can tell you that there are many SW developers at NI that would like to provide better and ongoing Linux support.  Our business cases for that support depend largely on the interests of users like you.  So, if you like NI hardware and have suggestions for improvement in your domain, please feed that back to NI R&D and management via your local NI sales contact.

[PatFord]

Interestingly enough our local rep has pretty much said not to buy LV for Linux. It would be a good door opener if there was a discounted price for the Linux suite if you already have one of the other suites. As it stands I have a professional dev suite for windows, and do almost noting on the with LV on linux as it is hard to justify 2X the license fees.

Pat

[Joey2]

Hi Tom

 my customer also want to use 9188 with linux，but up to now， we still can't use it in this way？if he want to build driver himself， can we provide some information？

thanks

Best Regards

wenjie zheng

NISH AE

[metux]

---

@Tom_W_[DE] wrote:

Unfortunately, as you have observed, the cDAQ-9188 communication protocol is too complicated to effectively document, and NI does not currently plan (as of May 2011) to release Linux driver support in the foreseeable future. 

Just give us the code, we'll see how complicated it really is.

And if these devices already are eth-based - why don't you just add some decent protocol (eg. iiod's one) and give a firmware upgrade to the unlucky customers ?

One suggestion, depending on your I/O and timing needs might be to have a Windows box running NI-DAQmx that is configured to publish single-point data via the DAQmx I/O Server and then consumed via OPC or similar on your Linux servers.

OLE ? On Linux ? Seriously ? This proprietary old crap was obsolete before it even was invented. Industrial signalling via Window messages - and then even trying to get that into a distributed system. Totally ridiculous.

Alternatively, you could use PXI DAQ with an RT system using the LabVIEW RT Hypervisor.  This basically lets you run some of the newest PXIe hardware (for example, PXIe X Series multifunction DAQ) on a dual-core PXIe controller where the second core runs Linux and could plug into your existing infrastructure.

You seriously ask your customers to run their stable GNU/Linux system under an proprietary, non-auditable (therefore by definition insecure and unstable) Hypervisor ?

And how does the data come into the Linux system ? 

One last option that comes to mind would be to use NI-DAQmx 8.0.x for Linux and use some of the older NI DAQ hardware (for example, PCI or PXI M Series multifunction DAQ) to achieve the same effect on a more standard Linux-based PC. 

Proprietary kernel modules. And the glue code is really badly written.

Don't use that for anything but toys.

We are always interested in improving our Linux support, 

Are you ? Seriously ?

Considering my conversations w/ support and dev folks, I really doubt that.

I would't even consider "Linux support" existing at all.

Just had a look at the recent nikal - this is just ridiculous and practically unusable (yes, even C++ in *kernel* modules!).

If you *would* be *seriously* interested in Linux support (and not just some fragile stuff that only works on *some* *specific* kernel versions and configurations), you would have hired a few *good* kernel hackers (the guys who wrote the nikal code are rookies), who would use the IIO infrastructure and bring the drivers mainline.

(yes! free drivers! proprietary modules just won't work reliably!)

but the market demands are sometimes difficult to gauge. 

Well, NI kept itself out of the market - by their own decisions.

NI already has a reputation of practically non-existing Linux support and hitting their customers in the face. Just by refusing to recognize the most fundamental things (like proprietary kernel drivers are just insane). Nobody in the Linux community can take NI seriously.  

If you ever want to take a share on the Linux market, the first essential step is free drivers (and bring them to mainline). Without that, no chance at all.

Funny: the cRIO's boxes themselves run w/ Linux (well, a patched-to-death vendor kernel w/ some old and incomplete RT patches), but no drivers for the cards here.

It's offered as an embedded Linux system, but that's more or less a lie. It's not usable for Linux applications - it's just a LV runtime happens to be based on Linux (even w/ cutting off the most vital security features - everything running as root).

*If* you ever take that seriously and start developing free drivers (not the nikal crap, needs a fresh start), I'll be glad to help you (give me the specs and the hw, and I'll do it for you - we all know you're lacking linux kernel developers).

But I'll never help anybody w/ ridiculous proprietary drivers. And I'll have to continue protecting my clients from purchasing NI products.

You already lost cRIO sales opportunities worth more than driver development would cost - just w/ my clients alone.

Do you have any serious interest in the Linux market ? Yes or no ? 

[metux]

---

@Tom_W_[DE] wrote:

I can see how this is frustrating to end users,  but hopefully you can appreciate NI's perspective on this.

Appreciation doesn't solve the problem. At the end of th day it's about buying or not.

From my clients, you won't get a single penny, as long as there aren't decent (that includes *free*) drivers. Period.

We are trying to find new ways to make these devices accessible on non-Windows platforms.

Several years later, nothing really changed. Just trying, w/o any actual achievement, isn't helpful. So it remains: NO DEAL.

I agree that LabVIEW has a polarizing effect. 

LV isn't the problem here - it's lack of hw drivers.

If you consider hw drivers part of LV, then you've got a *serious* conceptional problem. Drivers belong to the operating system, not individual applications.

(that's the whole idea of operating systems)

Yes, the NI-DAQmx core binaries are a few years old, but we have been able to largely keep it viable through ongoing efforts (in NI-KAL, et al) to maintain compatibility with ever-changing Linux APIs. 

Nikal is fundamentally broken by design. Completely ridiculous.

Totally unfixable. You need a fresh start and work the way the Kernel is developed. As long as you don't accept that, no chance for getting proper drivers. Period.

About proprietary/binary-only kernel modules: no way to make them work reliably. If you still try, you're lying to yourself, and your customers.

And if you *really* don't ever want to tell us the fundamentals of how to talk to your devices (IOW: refuse to tell your customers how to use them!), you better should be honest and leave the Linux world entirely - don't claim any "support" that just isn't existing.

We had a hiccup with some kernel API deprecations a year or so ago, but all indications are that NI drivers are back in the saddle again.  

Because your approach is fundamentally wrong in the first place. Starting with the insane idea of proprietary kernel modules. The more you continue this way, the bigger the damage you do to yourself in the Linux market (just like NVidia w/ their expensive electronics trash).

The longer you wait, the higher the chance anybody else comes around and takes that market share. Evolution will optimize you away from the market. It's that simple.

I can tell you that there are many SW developers at NI that would like to provide better and ongoing Linux support.

Really ? Considering my recent calls w/ NI, and looking at Nikal, I wonder whether you have the will and the capacities to do that.

Again: nikal is totally crap. Unfixable.

Our business cases for that support depend largely on the interests of users like you. 

As long as there aren't proper drivers, there is just no business case.

There isn't any notable NI Linux user base, as nobody in the Linux world would even consider NI in the first place. Because of that ridiculous situation.

First you'll have to do your homework, then you can expect people to buy your products. For now, they're practically unusable for Linux.

Sorry if that sounds harsh, but that's exacty the situation.

[David22JRA]

Hello metux

I am sorry for this situation. Nowadays, we have drivers for supporting DAQ systems but the Ethernet Chassis are not yet supported officially.

Also, some other information you can consult in the links below: https://www.ni.com/en/support/documentation/supplemental/18/measurement-hardware-driver-development-... (Measurement Hardware Driver Development Kit (MHDDK) Frequently Asked Questions)

http://forums.ni.com/t5/Driver-Development-Kit-DDK/gp-p/8517?view=overview#/?tagSet=undefined (Driver Development Kit (DDK) Programmers)

On the other hand, someone has posted about the Ethernet Chassis in Linux, let me share with you what He posted in the last iteration:

http://forums.ni.com/t5/Linux-Users/Setting-up-NI-cDAQ-9184-in-Linux-Environment/gpm-p/3462173#M2283

I hope this information might be useful for you. 

Regards