Problems with NI-VISA and USB Drivers on cRIO 9068

[FCGoat]

Hello All,

We've been experiencing some difficulties getting our two cRIO 9068s to communicate well with our other miscellaneous instruments, and it generally seems to be a problem on the Labview/Visa side of the equation.

The project we're working on is related to using high temperature fuel cells for energy storage applications, and thus as you might imagine we have a relatively large number of instruments working on concert to both control and monitor the system.  Quite a large percentage of our instruments still run some variation of serial communication and thus we've been working specifically on ways to easily network large numbers of serial devices into the cRIOs with easy expandability.  Through a series of events we decided on using COTS usb hubs to break out the single USB port on the cRIO to connect to all of the miscellaneous devices with some sort of intermediate USB-Serial connection.  This allows for easy expansion, inexpensive hardware, isolation between the devices and the cRIO, and relys on the linux kernel to handle all of the drivers.  However, we've run into some problems getting everything to play nice, thus far the devices have fallen into three categories.

1:  FTDI Based chipset Devices:  These devices (mostly homegrown equipment) work with very little effort. By adding the lines below to /etc/mdev.conf we are able to see the devices mount in linux ("lsusb"), load the appropiate drivers ("dmesg | grep tty"), and they immediately show up in NiMAX with their appropriate "ttyUSBn" port and Max reads Status: Present. 

ttyUSB[0-9]*    root:tty 666     

Note:  The adding of this line to the mdev.conf was referenced by a number of different tutorials (1, 2 ) Creating symlinks was unneccesary in this case.

These devices are immediately available for access using the standard VISA serial communication methods, and respond as expected.  We've performed simple loop back tests, as well as actually communicated with devices and everything has worked. The "ftdi_sio" is noted here, as a driver known to work and so this result was expected.

2:  Prolific based chipset devices:  These devices (COTS USB-Serial converters) seem to load fine into the kernel, the driver PL2303 is loaded, a new ttyUSBn shows up, and they also pop up in Ni-MAX.  Again, no symlink is needed to make Visa realize a new interface is available, however, the Status in Max reads as "Not Present."  Attempting to run a loop back test using the Simple Serial.VI results in this error: "Error -1073807360 occurred at Property Node (arg 1) in VISA Configure Serial Port."  Attempting to remove the driver using "rmmod pl2303" has the desired effect o removing it from linux (as noted here) but also removes it from VISA.  These devices do not seem to work though the driver is noted as supported here.

3: Atmel based USB to Serial Chipsets.  These devices (things like Arduino Unos) are loaded into the kernal as "USB Modem Modules," using the driver cdc-acm providing the line below is entered into /etc/mdev.conf.  They register as ttyACMn, as expected, and do not show up in Visa.  Creating a Symlink to something like ttySn does allow them to show up in VISA however, they also register as "Status: not present" in Max and they fail the Simple Serial.VI with this error: Error -1073807360 occurred at Property Node (arg 1) in VISA Configure Serial Port.  However, these devices are publishing data regularly over serial and by using "cat < /dev/ttyACMn"  we can read the serial output of the device.

ttyACM[0-9]*    root:tty 666

Furthermore it is possible to remove the cdc-acm driver from the kernal (rmmod cdc-acm), and this causes the devices to show up as raw USB devices but this doesn't seem to enable any useful communication..

Any ideas guys?  We're planning on building all of our new hardware to only use FTDI chips, but it'd be nice to use the stuff we currently have.  And particularly since it seems like the kernel doens't have any problems running these devices it'd be nice to figure out how to get LabView to place nice.  Cheers ~ Micah

System:            cRIO-9068

Firmware:          1.0.1f0

OS:                    NI Linux Real-Time ARMv7-A 3.2.35-rt52-1.0.0f1

NI-RIO V:          13.1

NI-VISA:          5.4.1

Labview RT          13.0.1

Labview                    2013

[Sanjay_C.]

Hey,

Any chance that you or someone from your team will be at NIWeek next week? We have an Advanced NI Linux Real-Time session in which we'll be doing a demo that serendipitously address most of this topic. It would be a good time to dive further into this issue.

We'll be following up shortly on the forum as well -- excuse the delay as we're in the midst of getting everything ready for NIWeek!

[FCGoat]

Sanjay,

Unfortunately none of our team will be at NIWeek, we're shooting to bring our system up sometime the following week and so we'll all be busy ringing out any last minute bugs. 

Are you folks live streaming the demo/presentation?  If not, perhaps we could get a copy of the presentation after you've made it. 

Thanks for the quick response, cheers

~Micah

[Sanjay_C.]

Hey,

We've posted a guide on adding kernel modules to the community, and we'll be uploading the presentation itself soon for reference. Hopefully the new kernel module documentation is helpful?

[FCGoat]

I upgraded my cRIO 9068s to NI-RIO 14, as well as the firmware upgrade and had some success.  The Prolific drivers now work without problem once the permissions on the port are set correctly,however still no luck on the ACM type devices.  On the way I made some exciting discoveries regarding a really slick way to set up known devices on the cRIOs leveraging the new capabilities that the updated firmware gives us, I'll put together a tutorial when I get a few minutes.  Thanks for the kernal guide, it wasn't required in this project but I'm sure it will be helpful in the future, cheers

~Micah

[BradM]

FCGoat wrote:

...

Are you folks live streaming the demo/presentation?  If not, perhaps we could get a copy of the presentation after you've made it. 

Thanks for the quick response, cheers

~Micah

The slides will be up shortly, but the source used in the presentation is here: NI Linux Real-Time part 2 - Advanced Topics

[fabio80]

I am facing the very same issue here with my cRIO 9068, and Atmel-based (Arduino): the situation is just like you described.

One question only:

Furthermore it is possible to remove the cdc-acm driver from the kernal (rmmod cdc-acm), and this causes the devices to show up as raw USB devices but this doesn't seem to enable any useful communication..

what do you mean by "show up as raw USB device"? when I 'rmmod cdc-acm'  I just loose my /dev/ttyACM0...

System:            cRIO-9068

Firmware:          1.0.1f0

OS:                    NI Linux Real-Time ARMv7-A 3.2.35-rt52-1.0.0f1

NI-RIO V:          13.1

NI-VISA:          5.4.1

Labview RT          13.0.1

Labview                    2013

[BradM]

fabio80 wrote:

...

what do you mean by "show up as raw USB device"? when I 'rmmod cdc-acm'  I just loose my /dev/ttyACM0...

...

Basically, my understanding is the set of functionality expected by NI-VISA of a port is more than what a CDC-ACM device supports and therefore has issues communicating with it.

Removing the CDC-ACM driver prevents the kernel from handing the device (creating the /dev/ttyACM0 device file for example) and instead leaves it to MAX to handle if it was able (through the /sys/ filesystem entry that corresponds to the USB device).

Depending on what you need to use the device for, you may be better served using the kernel's CDC-ACM driver and writing some code in C/C++ to interact with the device, and communicate with that code from LVRT.

[FCGoat]

Sorry for the delay fabio80, we were testing the last couple weeks.  We found that you can get some atmel devices which use the cdc-acm driver to show up in max as "raw devices."  Which means instead of a more common ASLR-type name the devices shows up in Max as a big long string of things which appeared to be pulled from the kernals information about the device.  (serial number, manufacturer, etc..) 

However, I was never able to actually do anything with this entry in Max, period. 

The good news is, the most recent updated software (2.0x) fixes a ton of these problems, and adds lots of other miscellaneous functionality that you may find helpful.  I really really hate saying this, but "have you tried updating everything?"

One thing that may help you directly with respect to the Arduinos; get one that uses the older FTDI based USB-Serial chip.  The newer ones (Unos, Mega 2560 etc) all use an atmel chip programmed to provide usb-serial communications and we never got them to work properly with labview.  You can get one from sparkfun here, that uses the more common FTDI chip, and I imagine it would communicate flawlessly.  In fact we actually rigged up special FTDI boards to do all of our communication with instruments, I detailed the software side here.

Hope that helps, good luck

~Micah

[harrisw]

Have you had any problems with your devices that use "ftdi_sio" since upgrading your firmware and NI-RIO 14?  I recently had an issue that was resolved with your solution #1 in Labview 2013, however since upgrading to 2014 the problem came back (the device is listed in MAX, however with the status "Not Present").  Unfortunately since the upgrade there is no /etc/mdev.conf file anymore so I can't even try that solution.  Any ideas?

Thanks,

Wayne