FTDI USB Serial Adapter

[FCGoat]

Indeed, I found the same results when I corrected my typos...

However, now I'm running into enumeration problems (static references work, but only 5), but that's probably a distinct enough topic to warrant a different post.

[MRedRaider]

FYI for anyone trying to use an Amulet via USB that find this discussion:

The amulet is an Atmel device, it will show up in MAX as "not present."

Jim Kring's permissions fix corrects the issue for atmel as well, adding permissions for "others" to read/write:

chmod o+rw /dev/ttyACM0

As a permanent fix I added lvuser, admin, and webserv to the group 'dialout' so that access is persistent across reboots.

[metux]

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)

*FACEPALM*

NI folks didn't even think about looking at /sys/class/tty/* ... 😮

Rookies.

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).

Seems something wrong w/ your udev config. It should belong to group "tty".

And the user, who's wants to access tty's, of course, has to be in that group.

Some distros also use different groups ("serial" or "dialout") for serial ports.

OTOH, you probably don't wanna give that broad access to some user, so you'd have to adapt your udev config anyways.

I am not sure what credentials the process that runs the deployed VI has or the process that is running the sysapi framework has,

tried "ps aux" or "top" ?

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.

*VERY INSECURE*