Problems with NI-VISA and USB Drivers on cRIO 9068

[FCGoat]

Wayne,

Things changed dramatically (for the better) with the update of NI-RIO 14, in fact, it solved most of my problems.  Check out the tutorial I wrote here, for more details on how to deal with the new stuff.  It's considerably more elegant than the old way of doing things for the FTDI based hardware.  If you need further help for your specific case I'd be happy to give a hand. 

Oh, and by the way, the prolific driver is working now (PL2303), so hooray!

Cheers,

~Micah

[fabio80]

Micah,

Following your suggestions, I bought a FTDI (the common FT232RL) to interface between Labview and my  Arduino. The thing is now the device is correctly detected (/dev/ttyUSB0) as a FTDI chip based device (and I verified it is used with ftdi_sio drivers) , and I was able to do everything you described in your tutorial. But, in the end, just like Wayne witnessed, the NI MAX marks it as "Not Present". So I am not able to use it.

How did you get it to work, with cRIO Labview 14??

cRIO O.S. NI Linux Real-Time ARMv7-A 3.2.35-rt52-2.0.0f0

cRIO firmware revision 2.1.0f0

Fabio

[harrisw]

Fabio (and Micah),

I was able to resolve my issue by adding the udev rule as outlined in Micah's tutorial.  I should note, that in the process, the output from udevadm info -a -n ttyUSB0 was not identical to Micah's example, but I was still able to get it to work on two different cRIO units.

Best of luck Fabio, and thanks for the guidance Micah.

Wayne

[FCGoat]

Fabio,

The "not present" is likely a permissions issues, and as Wayne mentioned, you'll need to make sure that you have correctly identified the device (with the udevadm info -a -n ttyUSB0 command) and made sure your rule works.  An easy way to ensure your rule works is to add a symlink in the rule.  When you plug in the device the rule should immediately populate that symlink.  So for instance in my case, when I plug in a device, in the /dev directory I get two entries, one "ttyUSBx" and one "MyDeviceSymlink."   If that doesn't work, then my rule is broken. 

A quick way to verify that your permissions are set correctly is to use ls -l filename in the /dev folder, it will spit out a ton of information about every file (most of which you won't care about) but the important bit will be the permissions regarding your device, ensure that you have read/write/execute privileges for the device in question (either the USBx or Symlink).  This artcle describes the output from the command as well as how to change them to what you want.

Good luck, let me know if that doens't sort the problem out for you.  Cheers

[fabio80]

Thank all of you, guys!

Following Micah's tutorial solved completely the issue.

Surprisingly the Arduino DUE, although it uses the same cdc-acm drivers as Arduino UNO, it does not require to be interfaced with a FTDI chip in order to be used by VISA.

Good to know....

The FTDI chips are unexpensive and easy to retrieve, still I did not manage to fix the EEPROM with the utility available on FTDI website, because I cannot find the serial attribute field to set in the EEPROM.ini file, but I will figure this out.

Thanks again,

Cheers,

Fabio

[FCGoat]

Fabio,

That is great news that the cdc-acm driver just works with VISA, and even better that you can get the Due working, it has some neat possibilities. 

The reason you didn't find the FTDI serial attribute on the .ini file is that the Due does not use an FTDI chip, instead it uses an ATmega16U2 microcontroller to emulate a com port, see here.  This isn't necessarily a bad thing, since apparently it works fine now, but it does mean the utility from FTDI isn't going to work.  You may be able to add a different field to the .ini file to achieve the same results. 

If I get some time I'll take a look at the native cdc-acm support and the ATmega16U2 communication, we have one in our system (it's actually a Mega 2560), but at the time we needed to build an FTDI translator to get it to work, perhaps this is now uneccessary. 

Thanks for reporting back, cheers,

~Micah

[rolfk]

For the newer NI Linux RT 2014 platform the mdev rule to assign permissions won't work anymore. Instead it uses udev. For this to work you need to add a file "/etc/udev/rules.d/ttyUSB.rules" with following contents:

KERNEL==”ttyUSB[0-9]*”, GROUP=”tty”, MODE=”666”

I got with this addition a Silicon Labs cp210x device working on a cRIO-9066.

[Harlequinade]

Thanks for the help. However, for my cRIO-9067 the naming of the USB is a bit different, so I had to use:

KERNEL=="ttyACM[0-9]*", GROUP="tty", MODE="666"

[BradM]

Harlequinade,

The difference in the naming is due to a different device. The device you're using exposes a CDC-ACM interface. The SiLabs cp210x does not. The CDC-ACM devices will all use the same driver, regardless of the vendor (the HW interface is the same) while the cp210x chips have their own interface, the driver will only work for those chips. Both drivers plug into the kernel TTY system slightly differrently. This is the difference in the naming.

[DStavilaNI]

Hi guys,

                   Just wanted to say thank you for your posts - using the same techniques I managed to connect an Amulet display to myRIO using the USB port

Regards,

Denis