PCI-6514 Linux Support?

[KNRO]

Hello, I know that the PCI-6514 is supported under Linux using NI-DAQmx 8.0, however the 'supported' distributions are getting old and obselete (I'm currently running SUSE 10.2 on Desktop and SLES 10 on Server). I understand that it might be difficult to release NI-DAQmx for the rapidly changing Linux distributions.

However, I think NI is ought to make all the Linux drivers available for "Enterprise Linux", namely RHEL and SLES since these products have longer life times (24+ months) as oppossed to the 6-9 months release cycle of common Linux distributions.

I recently ordered the PCI-6514 for our SCADA server running SLES 10 but it seems that I have to play a bit with kernel and installation parameters before anything is expected to work. So are there any plans to support SLES 10?

Regards,
Jasem Mutlaq
Kuwait National Radio Observatory

[KNRO]

I was able to compile the kernel module nikal.ko after a bit of work (full HOWTO later) on my desktop (SUSE 10.2), I will have to try that again on SLES 10 server at work in a few days. However, when I run either nilsdev or nidaqmxconfig, I get "Aborted" message, I didn't receive the PCI-6514 yet, does it display that if no PCI card is installed?

I read the FAQ regarding the "Aborted" message, and I restarted and ran updateNIDrivers several times with no changes in behavior what so ever. Any clues to this odd problem?

[KNRO]

Nevermind, /var/log/messages

Mar  2 16:27:15 KNRO nidaqmxconfig: [libnipalu.so.1.10]  Warning: source/package/posix/ulibEntry.cpp:191 - initialize: unable to load NI-PAL. status=-50204
Mar  2 16:27:23 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/lib/linux/linLoadKern.cpp:168 - libKernelDriverLoad: Failed to open nipalk, errno: 2
Mar  2 16:27:23 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/initcln/initcln.cpp:147 - Posix: Init kInitClnPackage: kernelDriver: failed! status=-50204
Mar  2 16:27:23 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/package/posix/ulibEntry.cpp:191 - initialize: unable to load NI-PAL. status=-50204
Mar  2 16:28:26 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/lib/linux/linLoadKern.cpp:168 - libKernelDriverLoad: Failed to open nipalk, errno: 2
Mar  2 16:28:26 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/initcln/initcln.cpp:147 - Posix: Init kInitClnPackage: kernelDriver: failed! status=-50204
Mar  2 16:28:26 KNRO nilsdev: [libnipalu.so.1.10]  Warning: source/package/posix/ulibEntry.cpp:191 - initialize: unable to load NI-PAL. status=-50204
Mar  2 16:37:49 KNRO nidaqmxconfig: [libnipalu.so.1.10]  Warning: source/lib/linux/linLoadKern.cpp:168 - libKernelDriverLoad: Failed to open nipalk, errno: 2
Mar  2 16:37:49 KNRO nidaqmxconfig: [libnipalu.so.1.10]  Warning: source/initcln/initcln.cpp:147 - Posix: Init kInitClnPackage: kernelDriver: failed! status=-50204
Mar  2 16:37:49 KNRO nidaqmxconfig: [libnipalu.so.1.10]  Warning: source/package/posix/ulibEntry.cpp:191 - initialize: unable to load NI-PAL. status=-50204

I attached system_report if it can help diagnose the problem.

[KNRO]

Update: I receieved the PCI-6514 and my organization just ordered as well PCI-6509, but I'm still stuck with this problem. All our control software runs on Linux, so we _have_ to get this to work ASAP or our project will suffer delays.

Can NI engineers help in this matter? Again, I don't expect NI to release a driver every few months to keep up with fast paced Linux distributions but at _minimum_ they should support SLES and RHEL which are _guranteed_ to have a long life span. This is a reasonable request and I hope NI releases a driver for SLES 10.

[Raajit_Lall]

Hello,

I think this would be something that you can put in a Product Suggestion for. Customer product suggestions are something that we take seriously. Here is a link for where you can submit a product suggestion. I will go ahead and submit one for you, but I recommend that you submit one as well.

Product Suggestion Center - National Instruments

Regards,

Raajit L

[David S.]

Hi Jasem -

I'd like to elaborate on Raajit's response.  As I understand it--I'm not a developer and can't speak directly for them--there are several factors limiting us from providing quick releases of DAQmx for Linux.  You've stated that you read our policy documents on LInux distribution releases, so I won't waste your time by going into those details.  But I do want to add that one of the limitations I'm aware of is that some of the newer distributions impose limits that would be extremely difficult to meet, such as the 4k stack size on some newer RedHat distributions.  So implementing this solution probably isn't as simple as providing recompiled drivers

The best we can offer immediately is to check out this thread for advice on getting DAQmx to work in unsupported distributions.  A lot of our forum users are Linux advocates, and they'll probably be your best resource for quick information.

[KNRO]

Hello Raajit, I submitted my suggestion. Except that we really need to resolve this issue _now_. All SCADA related work in our observatory is basically on HALT now.

David S, thank you for your response. I do realize problems of keeping up with newer kernels, and this is why I specfically suggested that NI releases NI-DAQmx for enterprise grade Linux such as SLES and RHEL since these products are stable and have _long_ life times. NI doesn't have to worry about releasing the driver every few months, one driver will suffice for a minimum of two years if not more.

[KNRO]

I forgot to add that I already read almost all threads related to getting DAQmx to work on Linux (including the one you posted) and spent the last few days trying different methods to see if it works out, it didn't.

[KNRO]

Nikal 1.5 solved the problem. I had to be very careful about installation order, NIKAL 1.5 must be installed _before_ NI-DAQmx (and it actually says that in the NIKAL downlad page).

I had to run make cloneconfig and make prepare_modules, and make a symbolic link to asm-offsets.h (the link being asm_offsets.h), and I had to define UTS_RELEASE in /usr/src/linux/include/linux/version.h to be same of kernel name returned by uname -r.

Now nilsdev displays attached devices normally. I will have to test if the board functions work normally as well.