Is NI-DAQmx 8.0.2 still supported? Bug on DevX/port0 on M-series cards

[mig-31]

Hi,

I discovered working with digital input port 0 (Dev1/port0) on my PCI-6250. When I connect 5V to the one of line on digital input port (Dev1/port0) and then run ReadDigPort C example program, I always get 0 in integer format. When I change digital input port to Dev1/port1, I get right value: for example 1 in integer format: 5V connect to Dev1/port1/line0.

I think it a bug.

It is possible to make a patch to correct it?

[ninevoltz]

It would appear to me that NI does not support Linux at all anymore, as DAQmx for Linux has not been updated in four years. Shawn Bohrer no longer works for NI, and I don't know if anyone else there even works on the Linux platform. Soon there will be no more 32-bit Linux distributions left, so unless they add 64-bit support, it will be dead.

I may have to revise our test equipment here someday, and toss out all of this NI gear. I've never really been happy with the way this equipment performs, or the clunky API it uses. My biggest grievance with the DAQ boards is that a 5V logic input to the digital inputs will NOT register as a high. The threshold is something around 6 volts. That's in the hardware, if I remember right, it's because it is optically isolated. My other disappointment is the extremely poor accuracy of the low-end multiplexed sample-and-hold ADC inputs. Seriously, multi-channel high-speed ADCs have been around for decades, and are dirt cheap. Why do we have to pay a premium for something so basic?

Well, I hope some of that answered your question. I'm done ranting here now, I'll go away.

[Tom_W_[DE]]

Hi mig-31:

It has been some time since we ran test suites that would access M Series hardware on Linux, but I am fairly confident we would have caught this issue.  I don't doubt that you tested it correctly, since you are able to see believable results on port1.  My suggestion would be to try to rule out a problem with your hardware and setup.  Do you have another 6250 (or other M Series board) that also shows this behavior?  If not, could you try your same 6250 on a Windows PC running NI-DAQmx for Windows?  These two testing scenarios should be able to conclusively prove whether it is a problem with NI-DAQmx for Linux.

ninevoltz:

I am sorry that you have the impression that NI is not interested in supporting Linux.  We definitely miss Shawn, but I can assure you that a large and growing subset within NI R&D is invested in and actively developing Linux support.  For example, we recently (over the last 1-2 years) transitioned many of our cRIO and cDAQ controllers and other embedded devices to use NI Linux RT with LabVIEW RT instead of their older embedded O/S configurations.  On top of that, we're working on other projects for release over the next few years that I *hope* will also put us in a position to better support and innovate on Linux desktop platforms going forward, but those are still being defined and scheduled.  In the meantime, NI is committed to monitoring the Linux community and supporting requests as best we can from users like you.  So, I appreciate your input and also ask you to continue speaking up with specific device and feature needs that would help you be more successful.  And I assure you that there are plenty of Linux enthusiasts within NI and that the company is investing in and adopting Linux support in our products at a faster rate than at any time since the DAQmx 8.0.x timeframe

-Tom

[mig-31]

Hi Tom_W:

I'm glad that someone from NI made some comments about state of NI-DAQmx drivers for Linux and generally information about supporting other devices under Linux.

I'm interesting for using Linux, because generally it more stable and you can buy support directly from producer. Also you don't need todo PC agenda instalations.

NI-DAQmx 8.0.2:

I have tested it with PCI-6250 under Scientific Linux 6.4 32-bit and digital port0 doen't work. If I connect 5V signal to any pin of port0, I read 0 in integer format from port0, but with port1 everything is ok.  It looks, that correlated port doesn't work.

I have tested this under Windows with NI-DAQmx 9.x.x driver and port0 works. Also with NI-DAQmxBase 3.7.0 under Scientific Linux 6.4 port0 works.

We have another M-Series board PCI-6224, but we use it in the measurement PC (Scientific Linux 6.4 NI-DAQmxBase 3.7.0), which runs all the time (long test procedure up to 1000 hours). Measurement application, written on FreePascal using C API (libnidaqmxbase.so), use port0 and it works correctly.

If you need additional info please post it here.

[mig-31]

Hi,Tom_W_

Tom_W_[DE] wrote:

For example, we recently (over the last 1-2 years) transitioned many of our cRIO and cDAQ controllers and other embedded devices to use NI Linux RT with LabVIEW RT instead of their older embedded O/S configurations. 

-Tom

I have a question. I think for cRIO and cDAQ (it's runs under LinuxRT or LabViewRT), but you still need LabView to develop app for cDAQ and still need Windows PC as operator panel for this devices. Is it correct?

I think what Linux users and developers want is totally independent on Windows.

One my example of using NI hardware:

1. NI PCI-6224 application used 8 analog inputs and 6 digital ouput,

2. Internal Windows instalation with secure application (antivirus, firewal and so on) needs minimally 2core CPU Ivy Bridge based with 4G RAM. Because all job does by DAQ card, application can run on PC 1 core CPU and 1GB RAM. Usually industrial PC doesn't use newest components and very expensive in high performance  configuration. Of course, you can install your own Windows instalation, but you need actviate it through internet, but usually you can't connect PC without secure app to internal network. Telephone activation is awful. Less permformance configuration consume less power.

3. Next lack is -  Windows update come,change something and your application crashed. Windows usually needs restart after appling any update. Linux do need restart after update, except kernel update (still depend on user desicion).

4. I think it better to insvest money into hardware not into no needed software and paid it month by month, year by year.