Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

Support for ethernet cDAQ modules under Linux?

We're interested in using the ethernet cDAQ-9184 chassis with a variety of ADC cDAQ modules. Unfortunately I gather that they are not currently supported under Linux. Are there any plans for Linux support of ethernet cDAQ modules in the future? If not, is it possible to obtain details of the protocol to stream data from one of these modules?

Thanks,

Tom

0 Kudos
Message 1 of 8
(9,893 Views)

Hi Tom-

We do not have plans at this time to release Linux-based support for the ethernet or wireless CompactDAQ chassis.  The particular command protocol and other nuances in the host-device communication are sufficiently complicated and contain some proprietary information, so we aren't able to document them externally at this time.

Which analog cDAQ modules are you interested in using?  As I mentioned, we don't have plans to support those chassis now, but, should plans develop, it is always good to have an idea of which modules are most important to our users.

Tom W
National Instruments
0 Kudos
Message 2 of 8
(8,387 Views)

Hi,

We're interested in the 1MS/s 16 bit 4ch 9223, the 100kS/s 16 bit 4ch 9215 and the 50kS/s 24 bit 9239 along with the cDAQ-9184 chassis. We are using ethercat extensively for slow acquisition (up to 1kS/s) including using the 9215 ADC listed above in a 9144 chassis, but this is unsuitable for high data rates.

Would it be possible to disclose enough of the protocol just to get data off the ADCs? I notice in labs that you have an "NI Network browser" to setup the hardware in the first place, so if we could just get data off it that might be do to start with.

I'm surprised that you are so reluctant to disclose the protocol for these modules, especially as there are no current plans to develop Linux support for these modules. Surely we can't be the only site wanting to control ethernet cDAQ cards under Linux?

Thanks,

Tom

0 Kudos
Message 3 of 8
(8,387 Views)

Hey Tom-

Thanks for the input on module support.  I'll sock it away for possible future feature and support planning.

Unfortuantely the NI Network Browser (which, by the way, is a shipping product now that we install with NI-DAQmx for Windows) is only helpful in finding network-based NI devices and loading their network-based configuration interfaces.  The configuration interface to the device is totally separate from the interfaces we use to configure and stream data from the devices.

The data interface protocol is very complicated and is mostly undocumented, even for NI internal developers.  I may have overstated the reluctance to publish it on the grounds of guarding trade secrets (though there is some concern there).  We simply don't have the necessary documentation to share, unfortunately, and if we did I'm not sure that end users would be able to use it to be successful without replicating the same multi-year efforts that NI put into making it all work. 

You aren't the first person to ask, and we are always looking for ways to simplify and make things more open, but unfortunately I can't promise anything at this time.  Your feedback is helpful and useful in encouraging our marketing and engineering teams to consider future O/S and device support for NI-DAQmx.

Thanks again-  Tom

Tom W
National Instruments
0 Kudos
Message 4 of 8
(8,387 Views)

Hi Tom,

I am trying to configure a system using multiple CompactDAQ modules and a Linux based operating system. I understand that NI does not support CompactDAQ modules on Linux, however, would it be possible to use a NI cDAQ-918x chassis with windows running the VI then utilize network streams to send data to another VI running on a Linux machine?

Thanks

0 Kudos
Message 5 of 8
(8,387 Views)

The data interface protocol is very complicated and is mostly undocumented, even for NI internal developers. 

 *ROFL*

 

By the way: why didn't you folks just use standard protocols in the first place ?

 

I may have overstated the reluctance to publish it on the grounds of guarding trade secrets (though there is some concern there).  We simply don't have the necessary documentation to share, unfortunately, and if we did I'm not sure that end users would be able to use it to be successful without replicating the same multi-year efforts that NI put into making it all work. 

 Just give us everything you have (including the source code for reference) - we'll find out. 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 6 of 8
(8,178 Views)

@metux,

I honestly think it's all part of a higher-level strategy to keep people locked into the NI ecosystem and on the expensive treadmill. 

If us Linux users could simply deploy drivers in an unfettered, normal, well-supported Linux environment it would break the need to use the twisted NI RT Linux on the expensive cRIO/cDAQs.

0 Kudos
Message 7 of 8
(5,198 Views)

@jefferyanderson wrote:

@metux,

I honestly think it's all part of a higher-level strategy to keep people locked into the NI ecosystem and on the expensive treadmill. 

Perhaps.  But it keeps people away from bying NI hardware.

It's pretty trivial: no drivers -> not usuable -> no purchase -> no revenue.

 

If us Linux users could simply deploy drivers in an unfettered, normal, well-supported Linux environment it would break the need to use the twisted NI RT Linux on the expensive cRIO/cDAQs.

I really wonder why anybody should use their strange "NI RT Linux", except as a base for the LV stuff.

 

It seems that NI just doesn't see that LV is only applicable for a tiny amount of usecases where the HW could be useful. IOW: completely failing to recognize the potential, locking themselves out of a huge market.

 

Ergo: the golden rule remains: DONT buy NI hardware.

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 8 of 8
(5,192 Views)