ACM USB Serial Devices not working in RIO 15 / LabVIEW 2015

[MRedRaider]

Back in RIO 14 and LabVIEW 2014 I was able to get ATMEL based USB serial devices working by updating the device permissions through a few different options:

1. Adding users to the dialout group (lvuser, admin, web...)

2. Adding a udev rule

Both worked great and were consistent across reboots and LinuxRT devices.... Enter LabVIEW 2015 with RIO 15. The previous fixes appear to work, I can configure/open the port via VISA but I get a timeout on the first write every time.

I tried modifying the 70-usb-serial-permisssions.rule that was added in RIO15 by adding an additional directive... same as before: port opens, but I get a timeout on the first write.

I'm specifically using the Amulet 4.3 Resistive kit. The code works great from my computer, worked great in previous releases... and now it's just timing out without details.

Anyone have thoughts on this or run into it on another device?

Thanks!

[Deborah_B]

Thanks for your patience, MRedRaider, we're getting a representative system setup today!

[MRedRaider]

Awesome, Thanks for the heads up. Let me know if you need some code.

[gratian.crisan]

Yes, if you can provide some code, it will help a lot with troubleshooting.

[MRedRaider]

I just tested the shipping LabVIEW example for the Amulet devices and it has the same issue on 2015. Let me know if I need to share that or if you've already downloaded it.

Thanks!

[BradM]

MRedRaider,

Does the shipping example work if you use the built-in RS-232 port on your controller?

To give a bit of information as to what's going on, I would recommend checking what the strace command shows when attached to the LabVIEW RT execution system while running some LVRT code that's attempting to access the USB serial port. Alternately (although unlikely to show anything useful), you can check the kernel logs after running the code with the dmesg command.

[MRedRaider]

Thanks for the reply BradM.

I don't know that we have the power/RS232 daughterboard for the amulet. I'll dig around and see if there's an old one laying around from when we still bought them.

I've not used the strace command. Looks like I'd do this:

1. ps -aux to get the <PID> of the process (lvrt?)
2. strace -p <PID> -o amuletTrace.txt

Logged in as admin I should be able to attach to the process running as lvuser...

I'm going to have to pull the demo box and reload to check. I've got it running on LV2014 right now.

[BradM]

MRedRaider wrote:

...

I've not used the strace command. Looks like I'd do this:

1. ps -aux to get the <PID> of the process (lvrt?)
2. strace -p <PID> -o amuletTrace.txt

Logged in as admin I should be able to attach to the process running as lvuser...

...

Yes, logged in as admin, you can attach to processes running as another user (lvuser). You can shorten the command to something like

strace -p `pidof lvrt` -f -o amuletTrace.txt

(the -f flag will handle the case that the amulet VIs spawn a separate process)

[MRedRaider]

I got this setup, installed strace and ran it in debug from my laptop through an RT LInux sbRIO (9607). Same timeout... the strace file is MASSIVE for the short period of time it ran... 9.3MB.

I searched the file for ACM, two instances, a stat and an open. When the open is complete it returns 25... When I google for that error code I get: #define ENOTTY          25      /* Not a typewriter */

Would this mean we're not actually opening the port successfully on RIO15? I'm not sure what the /proc/consoles call is attempting to do, but it too fails with the same code right after the stat64.

copy paste of a small section of the strace below:

1499  stat64("/dev/ttyACM0", {st_mode=S_IFCHR|0660, st_rdev=makedev(166, 0), ...}) = 0

1499  open("/proc/consoles", O_RDONLY|O_LARGEFILE <unfinished ...>

1476  <... clock_nanosleep resumed> NULL) = 0

1499  <... open resumed> )              = 25

1476  clock_gettime(CLOCK_REALTIME,  <unfinished ...>

1499  read(25,  <unfinished ...>

1476  <... clock_gettime resumed> {1458136428, 960407645}) = 0

1499  <... read resumed> "", 8191)      = 0

1476  clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>

1499  close(25 <unfinished ...>

1476  <... clock_gettime resumed> {444, 572353890}) = 0

1499  <... close resumed> )             = 0

1476  clock_gettime(CLOCK_REALTIME,  <unfinished ...>

1499  open("/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK <unfinished ...>

1476  <... clock_gettime resumed> {1458136428, 961054988}) = 0

1476  clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, {444, 581605913},  <unfinished ...>

1306  <... nanosleep resumed> NULL)     = 0

1306  gettimeofday( <unfinished ...>

1499  <... open resumed> )              = 25

[BradM]

Yeah, sorry, I should have warned you. strace tells you everything that's happening between userspace and kernelspace. The traces are going to be large.

The return value from open() is the file descriptor (fildes or fd). Basically, it's the process's handle to a file, not meant to be zero (that's stdin by default). You can see that the fd from opening /proc/consoles (25) is then read from (read(25,...)), and that returns as well.

I would imagine that there's going to be a read() to the fd that's created (or, in this case, reused) for /dev/ttyACM0. I would further guess that this read will timeout. Hopefully something useful is in the log just below what you posted.