Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-KAL in SuSE Linux 11.4

Hi,

I'm trying to communicate with a GPIB-USB adapter. Installation of VISA drivers and ni-488.2 has gone well (no errors reported). However, when I try use the device LabView crashes with the following error:

libnipalu.so failed to initialize

Perhaps you need to run updateNIDrivers

Aborted

Running updateNIDrivers tells me the following:

Installing NI-KAL:

NI-KAL update failed.

  CC   /usr/local/natinst/nikal/src/nikal/nikal.o

/usr/local/natinst/nikal/src/nikal/nikal.c:485:4: error: unknown field ‘ioctl’ specified in initializer

/usr/local/natinst/nikal/src/nikal/nikal.c:485:4: warning: initialization from incompatible pointer type

make[2]: *** [/usr/local/natinst/nikal/src/nikal/nikal.o] Error 1

make[1]: *** [_module_/usr/local/natinst/nikal/src/nikal] Error 2

make: *** [all] Error 2

ERROR: make of nikal kernel module failed, not installing kernel module.

   updateNIDrivers should be called again after fixing the problem.

   Logging failure...

   Include the file /tmp/niSystemReport.out.gz when contacting

   National Instruments for support.

I am using SuSE Linux 11.4, kernel 2.6.37.1-1.2-desktop.

What should I do to correct this error?

Thanks.

0 Kudos
Message 1 of 47
(34,595 Views)

I don't think NI-KAL will compile against 2.6.37 as "ioctl" has been removed from the newer kernels. NI needs to update the NI-KAL driver.

Message 2 of 47
(8,712 Views)

And is it known when is it due (or if it is due at all)?

0 Kudos
Message 3 of 47
(8,712 Views)

That has not been decided. AFAIK, we're still going to support KAL for new kernel releases. The KAL maintainer has been super busy lately with other tasks. I'm sure KAL will work on newer kernel later. Sorry, no date yet on when that is.

Message 4 of 47
(8,712 Views)

Any additional information available about when the new version of NI-KAL will be released?  If not soon then LabJack will be getting a pretty big order and all of the NI6008s I have will be retired.

NI has got to understand that their support of the linux community has been quite poor.  I realize that you folks want to sell LabView, but there are a lot of developers who just need simple data acquisition and control.  Working with the NI product line is incredibly frustrating when support is so limited and very simple problems (like environment variable changes) suddenly cause perfectly good products to be immediately unusable. 

Message 5 of 47
(8,712 Views)

I could not agree more. I understand that the drivers have to be compiled against the kernel and therefore they cannot be shipped in a precompiled package. However, the compilation should be more straightforward. Man, I've got gcc and I've got the kernel sources, why is it that the compilation steps only work in the supported distros? I have compiled Nvidia drivers against the current kernel in many distros without changing a comma of the compilation commands. Surely something could be done better. After all, although different distros do things differently (like default directories to put stuff like the kernel sources), I don't think they do things *that* different.

For now, I'm migrating all Labview programs to Python scripts using the gpib-modules package because I'm not going to stick with Windows in the lab. I'll keep an eye on how the linux support progresses. However, chances are that once I have the Python scripts up and running I will not want to move back to Labview.

0 Kudos
Message 6 of 47
(8,712 Views)

I completly agree with that. In my case, the problem is not to have the NI drivers corresponding to the latest kernel releases immediatly, but the point is to have a view of a date when it will be available, without risking a complete break out of the system.

Going to Linux has been a strategic decision in my buisiness, and it is hard to plan anything without a good view of the evolutions of the core drivers, as I said to my NI sail representative.

I think that Linux is going to be more and more important in the DAQ and tests world, and NI can take a great advantage in offering a fully dedicated support solution.

For now, because of the choice of the NI drivers (among all the other drivers that can be easilly re-compiled with the newer kernels) , and because I can't take any risk in updating the system in my client configuration, I'm stuck to the OpenSuse 11.2 version....

0 Kudos
Message 7 of 47
(8,712 Views)

I apologize for the situation guys. We know that Linux support is painful for our customers. Linux moves pretty fast, and we only have limited resources dedicated for Linux internally, and we have other obligations and priorities. It's hard to keep up with Linux kernel changes. And yes, we know that there are better ways to support Linux with open source drivers and such, but that also comes with other set of problems. Sigh.

Anyway, I got KAL on Open SUSE 11.4 working. We're going to merge the changes to the main KAL source.

In the meantime, here's the diff that you can try out:

@@ -241,6 +241,9 @@

static int nNIKAL100_open(nLinux_inode *the_inode, nLinux_fileHandle *filePtr);

static int nNIKAL100_release(nLinux_inode *the_inode, nLinux_fileHandle *filePtr);

static int nNIKAL100_ioctl(nLinux_inode *the_inode, nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);

+#ifdef HAVE_UNLOCKED_IOCTL

+static long nNIKAL100_unlockedIoctl(nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);

+#endif

#ifdef HAVE_COMPAT_IOCTL

static long nNIKAL100_compatIoctl(nLinux_fileHandle *filePtr, unsigned int command, unsigned long param);

#endif

@@ -512,7 +515,11 @@

{

    .open = nNIKAL100_open,

    .release = nNIKAL100_release,

+#ifdef HAVE_UNLOCKED_IOCTL

+   .unlocked_ioctl = nNIKAL100_unlockedIoctl,

+#else

    .ioctl = nNIKAL100_ioctl,

+#endif

#ifdef HAVE_COMPAT_IOCTL

    .compat_ioctl = nNIKAL100_compatIoctl,

#endif

@@ -1798,6 +1805,13 @@

    return status;

}

+#ifdef HAVE_UNLOCKED_IOCTL

+static long nNIKAL100_unlockedIoctl(nLinux_fileHandle *filePtr, unsigned int command,

+   unsigned long param)

+{

+   return (long)nNIKAL100_ioctl(NULL, filePtr, command, param);

+}

+#endif

#ifdef HAVE_COMPAT_IOCTL

static long nNIKAL100_compatIoctl(nLinux_fileHandle *filePtr, unsigned int command,

    unsigned long param)

  1. Modify /usr/local/natinst/nikal/src/nikal.c using the diff above (manually, or using patch command). NOTE: Pay no attention to the line number. It's going to be different from your installed version. Look for similar lines and make the proper modifications.
  2. After that, I think you just need to run updateNIDrivers script

I've tested those changes, it seems to work.

I still don't know when the next official KAL release containing those changes will be released. We still need to discuss it internally to figure it out.

at least with this, you guys can make progress in parallel.

Post to this forum if you have prob. I'll try to answer.


Unfortunately, I can't attach files in here, otherwise, I'd have sent you guys the new kal file directly. Oh well.

Sorry again for the painful support here.

Message 8 of 47
(8,712 Views)

I agree that NI as a company is not doing a good job in supporting Linux. Technical support on this forum is excellent, but it is upsetting that Linux developers at NI are always "super busy" with other tasks. Is Linux development a priority for NI management at all or is it an "NI community effort"?

In our instrument development, we have an embedded computer communicating with an embedded custom board over USB going to an FTDI chip going to a serial link. I've been using NI-KAL and NI-VISA to talk to a virtual serial port that the FTDI driver creates, but in the next revision of the software I am considering dropping NI-VISA and switching to an FTDI shared library. That should make me independent of NI-KAL.

LabJack mentioned here is a great product and their support is very good too. I think NI will gradually be losing their low-end hardware sales to LabJack.

0 Kudos
Message 9 of 47
(8,712 Views)

Hi Irwan

Thanks for the update, but I've just spent many, many hours getting the system "kind of" working with SUSE 11.2 and have zero desire to start over.  Keep in mind that I had already gone the 11.4 route only to discover that it was incompatible (until now). 

The only reason I would go back to 11.4 and to use your changes is if the 60-second delay in the DAQmxBaseCreateTask method (caused by the use of the LabView 10 library) has been fixed.  Can you verify this one way or the other?  And yes...I've tried the suggested fix (also found in these forums) of mixing and matching the different LabView libraries.  That broke my system and I had to do a re-install, so I won't be using that particular patch. 

Thank you in advance for any info you can provide and for your efforts.  I realize that the lack of linux support is a management decision and not an engineering decision.  It just amazes me that management could be so blind as to what is potentially a huge lost market.  Actually, it doesn't amaze me at all...it's just aggravating.

0 Kudos
Message 10 of 47
(8,713 Views)