Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

CentOS 7: Issues in using USB DAQ

 

I have have some difficulties connecting a USB DAQ 6501 and 6009 to a supported Linux system (CentOS 7). This connection has never worked before on any Linux systems as far as I know, but it is always usable on a Windows 7 installation using LabVIEW 2015. I have contacted support, but they have not been responsive. The country is small.

There is the need to compile some VIs for Linux systems, which cannot be done from a Windows system.

 

 

 

Environment Details

Computer: TOSHIBA SATELLITE C50-B

OS: CentOS 7 (release 7.5.1804) recently installed (December 2018) and only for the purpose of connecting to DAQ USB devices and compiling projects.

LabVIEW: 2014 for Linux installed from the official CD.

NI Driver: NI-DAQmx Base 15.0 installed from the official. 

Drivers were updated without issue during this week with the tool "updateNIDrivers"

I have gone through a few iterations on software and have also tried NI-DAQmx Base 3.6 as recommended at http://www.ni.com/product-documentation/6913/en/#toc1 . I did not have success with it.

I have installed NIKAL 17.5.1, because I had some issues generated from the C source code when using "updateNIDrivers" as documented elsewhere on this forum.

 

lsdaq OUTPUT

$ lsdaq
--------------------------------
Detecting National Instruments DAQ Devices
Found the following DAQ Devices:
NI USB-6501: "Dev1"    (USB0::0x3923::0x718A::01A82A09::RAW)
--------------------------------
 

NIKAL Info

$ modinfo nikal

filename: /lib/modules/3.10.0-957.1.3.el7.x86_64/kernel/natinst/nikal/nikal.ko
description: National Instruments Kernel Abstraction Layer
author: National Instruments Corporation
license: Copyright (c) 2002-2015 National Instruments Corporation. All Rights Reserved. Any and all use of the copyrighted materials is subject to the then current terms and conditions of the applicable license agreement, which can be found at <http://www.ni.com/linux/>.
retpoline: Y
rhelversion: 7.6
srcversion: A3FC5B64FE2447FCBFE64D1
depends:
vermagic: 3.10.0-957.1.3.el7.x86_64 SMP mod_unload modversions

 

I am attaching the output of the "nidatalogger" program. No inputs are automatically detected. I am not sure if they should be as I have never successfully used this program. The logs directory within (/home) is empty if you are wondering. 

 

I believe I cannot use NI DAQmx version 18 as LabVIEW 2014 is not listed in the compatibility tables.

 

I have tried to run some of the samples within LabVIEW 2014 as recommended in the README of the driver to verify if the connection to the device is operational, but not inputs are automatically discovered.

 

I have checked with the engineer who needs to use the equipment that a VI to gather data from this device cannot be created as some menus are greyed out.

 

I am filled with uncertainty about the software I have at hand. I have no way of knowing if this device is in fact operational all the way up to LabVIEW 2014 or if it is user error as I do not work with LabVIEW on regular occasion.

 

Thank you for your time.

0 Kudos
Message 1 of 4
(1,837 Views)

You may want to also try posting this in the product-line-specific forums.  (e.g., Multifunction DAQ or Digital I/O)

0 Kudos
Message 2 of 4
(1,823 Views)

I spent a couple of hours reading through that board and it gave me confidence, given all the listed issues with driver operation/installation. It seems like most of my issues are linked to the quality of the official software and are not user error.

 

I don't think I will be posting there at this time, given that the hardware and software is operational under Windows 7.

0 Kudos
Message 3 of 4
(1,811 Views)

A few updates below. Beware that I work in IT and only have some hobbyist knowledge about electronics.

 

I have compiled and run some of the C code DIO examples that come included with NI-DAQmx 15. I have managed to run the readDigPort program on Dev1/port0. The output was: "Data read: 0xFF". Can I assume the code is operational? I expected to read all lines on port0, which has a pull-up resistor (Pull-up resistor 4.7 kΩ Vbus (nominally 5 V)) as per the datasheet, and will return 8 high bits.

 

Meanwhile, the support team has responded with a single phrase telling me to "verify" http://www.ni.com/product-documentation/52786/en/ . The only hint I can take from this is to downgrade NI-KAL to 15.x , given that for CentOS only 15.0 and 15.x are listed in the compatibility tables.

 

Also, I have noticed that all the options in the program "nidatalogger" and "nidataloggerlv" are for analog inputs (voltage and temperature). Can I assume that this program it not useful to reading digital inputs? I believe I could write some C to do that for me, but it goes beyond my scope at work.

 

Finally, I have managed to use the examples within Labview 2014 for reading a single digital port (/usr/local/natinst/LabVIEW-2014/examples/daqmxbase/static/dio/Read Dig Port.vi) and writing a single digital port (/usr/local/natinst/LabVIEW-2014/examples/daqmxbase/static/dio/Write Dig Port.vi). Initially, I was unaware that I had to provide an existing task listed under Tools > NI-DAQmx Base Task Configuration Utility. I was getting error "200248", because I was not using an existing task name. It seems that I also experienced an unfortunate timing as I later find out that the driver was in error state:

# lsdaq
--------------------------------
Detecting National Instruments DAQ Devices
Found the following DAQ Devices:
USB device recognition error:  -6005

Unplugging the device and re-plugging it into the USB port may fix this issue.

For more details, visit www.ni.com/info, and enter info code:  BaseUSBError--------------------------------

Seems like the above error is not passed all the way up to LabVIEW as it still detects the device just fine in the Task Configuration Utility and allows the VI to be run without error. I just repeated everything again a few times including a reboot after each iteration and I still get this error on occasion.  Can I fix or troubleshoot this further? As of now, I would not leave this running unattended controlling expensive hardware, but it is not really my choice to make.

 

0 Kudos
Message 4 of 4
(1,810 Views)