Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Linux USB-6218 PWR/ACT LED off

Solved!
Go to solution
Solution
Accepted by topic author tog000

tog000 wrote:

 

There must be some log file or some firmware update procedure that I'm missing. Any help would be really appreciated!


I can explain a little more about how NI-DAQmx Base initializes USB devices. Perhaps with this information, you can update your Ubuntu system. Since NI doesn't have debian package installer support, you'll have to update this by hand and without NI support. If you need help, please use the Ubuntu forums and share what you've learned here; the experts over there can guide you in configuring Ubuntu USB device events.

First, why does the 6008 work while the 6218 does not?

  • The 6008 uses flash storage for its firmware, so the firmware persists across device power cycles.
  • The 621x devices use RAM for their firwmare, so the firmware must be transferred to the device every time it is plugged in to the host.

 

Second, how does DAQmx Base transfer the firmware to USB devices?

  • For flash devices like the 6008, the firmware update utility can reprogram the flash -- /usr/local/natinst/nidaqmxbase/bin/FWUpdate
  • For RAM devices like the 621x, a different utility is used when the kernel reports a new attached device -- /usr/local/natinst/nidaqmxbase/bin/niusb9162dlfw
    • The nidaqmxbase-usb-support RPM also includes udev rules to react to the insertion and removal of NI USB devices -- /usr/local/natinst/nidaqmxbase/etc/hotplug/usb
    • The post-installation script in the RPM also creates symlinks and reloads the udev rules.
      • I suspect this is where the problem is for you. Either alien incorrectly translated the scripts or Ubuntu has a newer interface for controlling udev or Ubuntu isn't using udev and instead has a different kernel event messaging system.
  • For both types of devices, since the firmware is transferred from the host to the device, it must be kept on the host -- /usr/local/natinst/nidaqmxbase/bin/support

The basic order of operations for RAM devices is:

  • Subcribe for kernel events for USB device insertion/removal.
  • Filter for NI vendor and product IDs.
  • On insertionof the USB 621x loader device (PID 7269), change owner and permissions and run niusb9162dlfw.
  • On insertionof the USB 6218 device (PID 7272, screw terminals; or 73FE, BNC terminals), change owner and permissions.
Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
Message 11 of 17
(2,888 Views)

Thanks Ernesto, I know Ubuntu isn't supported, but I thought that since the 6008 worked, I assumed any others should.

 

Joe Friedchicken, the info you are providing is spot on. Its exactly what I needed to know to move on to try to make it work in Ubuntu.

 

I started investigating, and found through udev (which you mentioned, I never thought of looking in there, rookie mistake) that /etc/natinst/nidaqmxbase/bin/niusb9162dlfw is failing to run because NI-PAL never got installed correctly. Looking at the scripts, I found that /usr/local/natinst/nipal/bin/nipalkiInstallerUtility.sh didn't run because /usr/local/natinst/nipal/bin/palModuleMgr.sh was using sh instead of bash. Replaced the first line, instead of executing with #!/bin/sh changed it to #!/bin/bash.

 

Now that palModuleMgr works, ran:

 

sudo /usr/local/natinst/nipal/bin/palModuleMgr.sh -i -o linux:dir=nipal -t kernelDriver -s demand -c -f /usr/local/natinst/nipal/src/objects/nipalk-unversioned.o

 

Next, /etc/natinst/nidaqmxbase/bin/niusb9162dlfw complains of a missing NiViPciK module (I saw that one over in OpenSUSE! we are getting somewhere!)

 

Ran:

 

sudo /usr/local/natinst/nipal/bin/palModuleMgr.sh -i -o linux:dir=nipal -t kernelDriver -s demand -c -f /usr/local/vxipnp/src/objects64/NiViPxiK-unversioned.o


and then

sudo /usr/local/natinst/nipal/bin/palModuleMgr.sh -i -o linux:dir=nipal -t kernelDriver -s demand -c -f /usr/local/vxipnp/src/objects64/NiViPciK-unversioned.o 

 

EDIT: I also ran:

 

sudo updateNIDrivers

 

And now /etc/natinst/nidaqmxbase/bin/niusb9162dlfw is running without errors. I can only hope that when I get home and connect the DAQ, the firmware will be downloaded correctly.

 

$ lsmod | grep "ni"
nipalk               1601326  2 NiViPciK
nikal                 109014  1 nipalk
ghash_clmulni_intel    13259  0 
aesni_intel            55624  0 
aes_x86_64             17131  1 aesni_intel
lrw                    13286  1 aesni_intel
glue_helper            13990  1 aesni_intel
ablk_helper            13597  1 aesni_intel
cryptd                 20359  3 ghash_clmulni_intel,aesni_intel,ablk_helper

I will evaluate tonight and post my results.

 

Could you provide me with a link to the Ubuntu NI forum to share my progress? It might help people in the same scenario.

 

Thanks again for all your help Joe, your explanation of how firmware is loaded was the key to moving forward with this problem.

 

Thanks again!

0 Kudos
Message 12 of 17
(2,874 Views)

tog000 wrote:
Could you provide me with a link to the Ubuntu NI forum to share my progress? It might help people in the same scenario.

I had the official Ubuntu forums in mind for questions like "how do I register a script to handle USB kernel events?"

A more targeted audience is the NI Linux User Group, where there are other Ubuntu users who share what they've learned.

 

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 13 of 17
(2,866 Views)

Thanks Joe Friedchicken! It works!

0 Kudos
Message 14 of 17
(2,839 Views)

tog000 wrote:

Thanks Joe Friedchicken! It works!


Excellent 😄

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 15 of 17
(2,836 Views)

Hi there, last year I was able to get NIVISA working with the USB-6218 in Ubuntu 14.04 and later. I created some instructions that I will pase bellow. I've been able to follow it and get it working on multiple machines.

 

 

PACKAGES
 
nidaqmxbase_3.7.0
http://download.ni.com/support/softlib/multifunction_daq/nidaqmxbase/3.7/Linux/nidaqmxbase-3.7.0.iso
 
NIKAL_140
http://download.ni.com/support/softlib/kal/1.4/NIKAL14.iso
 
NIVISA_5.4.1
http://ftp.ni.com/support/softlib/visa/NI-VISA/5.4/linux/NI-VISA-5.4.1.iso
 
 
mkdir nidaqmxbase
mkdir iso
sudo mount -o nidaqmxbase-3.7.0.iso iso
cp iso/* nidaqmxbase -Rv
sudo umount iso
cd nidaqmxbase
sudo alien --target=x86_64 -k --scripts labview-2012* nidaqmxbase-cinterface* nidaqmxbase-labview2013* nidaqmxbase-board-support* nidaqmxbase-common* nidaqmxbase-usb-support*
** PATIENCE **
sudo dpkg -i *.deb
 
mkdir nikal
sudo mount -o NIKAL14.iso iso
cp iso/* nikal -Rv
sudo umount iso
cd nikal
mkdir tar
cd tar
tar -xf ../nikal-1.4.0f0.tar.gz
cd rpms
sudo alien --target=x86_64 -k --scripts *.rpm
 
** This is the nivisa dir from NIVISA_5.4.1.ISO, not the one included with nidaqmxbase **
 
mkdir nivisa
sudo mount -o loop NI-VISA-5.4.1.iso iso
cp iso/nivisa-5.4.1f0.tar.gz nivisa
cd nivisa
mkdir tar
cd tar
tar -xf ../nivisa-5.4.1f0.tar.gz
cd rpms
sudo alien --target=x86_64 -k --scripts *x86_64.rpm
sudo alien --target=x86_64 -k --scripts nivisa*.rpm
sudo alien --target=x86_64 -k --scripts *noarch.rpm
#**IMPORTANT**
rm nikali*deb
cp ../../../nikal/tar/rpms/*.deb .
sudo dpkg -i *.deb
 
sudo updateNIDrivers
 
sudo modprobe nikal
 
** disconnect USB DAQ, reconnect **
 
nidatalogger
0 Kudos
Message 16 of 17
(2,279 Views)

@JoeFriedchicken wrote:

Since NI doesn't have debian package installer support, you'll have to update this by hand and without NI support.

Why not ? Debian packaging is pretty trivial. And you always should build everything for the target distro anyways (otherwise there easily can be subtle mismatches eg. on shared libraries, etc !)

 

Second, how does DAQmx Base transfer the firmware to USB devices?

  • For flash devices like the 6008, the firmware update utility can reprogram the flash -- /usr/local/natinst/nidaqmxbase/bin/FWUpdate
  • For RAM devices like the 621x, a different utility is used when the kernel reports a new attached device -- /usr/local/natinst/nidaqmxbase/bin/niusb9162dlfw

Why aren't you just directly using the Linux firmware loader infrastructure ?

 

  • I suspect this is where the problem is for you. Either alien incorrectly translated the scripts or Ubuntu has a newer interface for controlling udev or Ubuntu isn't using udev and instead has a different kernel event messaging system.

Ubuntu *is* using udev in a pretty standard setup. You just have to place your rule files into the usual /lib/udev/rules.d/ directly. I wonder whether you ever read the manpages carefully ... 😮

 

    • The nidaqmxbase-usb-support RPM also includes udev rules to react to the insertion and removal of NI USB devices -- /usr/local/natinst/nidaqmxbase/etc/hotplug/usb
    • The post-installation script in the RPM also creates symlinks and reloads the udev rules.

Why so complicated ? The package is supposed to put its rule files into /lib/udev/rules.d/ - that's all.

 

For both types of devices, since the firmware is transferred from the host to the device, it must be kept on the host -- /usr/local/natinst/nidaqmxbase/bin/support 

Use the Linux firmware loader infrastructure. Firmware binaries shall be placed at /lib/firmware/

 

Anyways, /usr/local/... shall *never* be touched by *any* package - it's reserved for manual (self-compiled) installs.

If a vendor prefix is needed - /opt/<vendor>/ is the right place.

Did you folks ever read the FHS and LSB spec ?

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 17 of 17
(1,273 Views)