07-16-2013 07:13 PM
We've installed the FTDI drivers for a USB Serial Device and they seem to be working OK and we've got a "/dev/ttyUSB0" device. However, it doesn't show up as a serial port in VISA.
We tweaked the "/usr/local/vxipnp/linux/NIvisa/visaconf.ini" and added a new set of entries for the device, as shown below:
[ASRL-RSRC-ALIAS]
Name3="ASRL4::INSTR"
Enabled3=1
Static3=0
SystemName3="/dev/ttyUSB0"
BaudRate3=9600
Parity3=0
StopBits3=10
DataBits3=8
FlowCtrl3=0
NumOfResources=4 << changed this from 3 to 4
We were assuming this is all we'd need to do, but ASRL4::INSTR is not showing up in the list of VISA Resources (even after rebooting, etc.). Any other missing steps/tricks?
Thanks,
07-17-2013 11:46 AM
Hi Jim,
I think the Static3=0 should be Static3=1.
SystemName3="/dev/ttyUSB0" may be SystemName3="/dev/ttyUSBS0"
Can you post your file if that doesn't do it?
07-17-2013 12:53 PM
Hi Jesse,
This morning I tried changing to Static3=1 and that seemed to make things worse (MAX locked up when connecting).
Also, when I list the USB serial devices (ls /dev/ttyUSB*) all I see is /dev/ttyUSB0.
Here's our current file:
NumEntries=1
[ALIASES]
NumAliases=0
[ASRL-RSRC-ALIAS]
Name0="ASRL3::INSTR"
Enabled0=1
Static0=0
SystemName0="/dev/ttyS2"
BaudRate0=9600
Parity0=0
StopBits0=10
DataBits0=8
FlowCtrl0=0
Name1="ASRL2::INSTR"
Enabled1=1
Static1=0
SystemName1="/dev/ttyS1"
BaudRate1=9600
Parity1=0
StopBits1=10
DataBits1=8
FlowCtrl1=0
Name2="ASRL1::INSTR"
Enabled2=1
Static2=0
SystemName2="/dev/ttyS0"
BaudRate2=9600
Parity2=0
StopBits2=10
DataBits2=8
FlowCtrl2=0
Name3="ASRL4::INSTR"
Enabled3=1
Static3=1
SystemName3="/dev/ttyUSB0"
BaudRate3=9600
Parity3=0
StopBits3=10
DataBits3=8
FlowCtrl3=0
NumOfResources=4
07-17-2013 03:43 PM
Hey Jim,
As I mentioned over email, it turns out that this is a CAR. Here's the summary (including the viable workarounds):
1. NI-VISA automatically finds ports that are represented as /dev/ttySx on Linux (where x = a unique integer, usually starting at 0)
2. This device is represented in the system by the file /dev/ttyUSBx (where x = a unique integer, usually starting at 0)
3. For NI-VISA to find this port, there are two workarounds:
a. Add a static binding in visaconf.ini as detailed above and in the CAR. Specifically in the above example, Static3=0 should be changed to Static3=1.
OR
b. Create a symlink of the format /dev/ttySx => /dev/ttyUSB0 (the actual binding of the device).
4. Even with one of these workarounds, it turns out that the port isn't alwayst accessible to VISA. The reason was that the /dev/ttyUSB0 file that was created in the R&D test system belonged to user admin, group administ with permission rw-rw---- (660). I am not sure what credentials the process that runs the deployed VI has or the process that is running the sysapi framework has, but they couldn't open the file and hence VISA wouldn't report it in the VI that was running or in MAX. After changing the permission to the file to be rw-rw-rw- (666), I was able to use the port in a deployed VI as well as see it in MAX.
Hopefully that helps. You were definitely headed in the right direction initially; it's a known issue that on Linux, NI-VISA currently only finds Serial ports whose names match the pattern ttyS*, and as such, for the time being, you'll need to work around the issue as described until we can make a fix.
07-17-2013 06:21 PM
Hey Sanjay,
We were able to fix the issue using item #4. It was as simple as:
chmod o+rw ttyUSB0
The serial port now shows up in MAX.
Note: For those following along at home, you have to execute this command every time the USB serial adapter is plugged in.
Thanks,
07-18-2013 11:30 AM
Jim,
Glad to hear that you were able to get everything working. To elaborate on your note, this was what R&D was additionally able to find:
1. Once the system reboots, the /dev folder will be reset, and the symlink will be deleted and the device permission will be reset to rw-rw---- (660). Therefore, till now, I have to modify the permission of this /dev/ttyUSB0 each time the device reboots.
2. Once the device is plugged out, the /dev/ttyUSB0 and along with the symlink will be deleted. And when it is plugged in again and the /dev/ttyUSB0 can show up, but its permission is reset to rw-rw---- (660). However, if this device is not correctly closed in VISA last time, this device /dev/ttyUSB0 will not show up.
07-18-2013 04:20 PM
Great. Thanks for all the details.
07-24-2013 03:07 PM
One thing you could do to make the change persistent (would need to be recreated anytime that you format and reinstall to the target) would be to add the following to the file /etc/mdev.conf):
[file: /etc/mdev.conf]
...
ttyPS[0-9]* root:tty 666
ttyS[0-9]* root:tty 666
ttyUSB[0-9]* lvuser:ni 660 <<<<ADD THIS LINE
...
What this is doing is telling the system that creates the device files to use a particular ownership and permission set when it sees ttyUSB0, 1, ...
08-12-2014 12:44 PM
Any news on this CAR? I've been working on a similar problems, and developed a simple udev rule to make sure the correct permissions are set on the USB device, but I'm also trying to set up a static VISA point (for use in a config file) and the static binding is not currently working.
Cheers
~Micah
08-12-2014 02:14 PM
It seems like the permission issue remains (addressable with a udev/mdev rule) but in 2014 software, VISA is now aware of ttyUSB devices.