Using the ASCII command protocol for the Simple Motor Controller (18v7, specifically), is there a way to get a unique identifier from the controller (serial number, assigned device number, something else)? The case I have is where I have two motor controllers connected via USB to a Raspberry Pi/Linux system and I can see devices with the name scheme /dev/ttyACM*. I’ve gotten into situations where I’ve seen /dev/ttyACM0 through /dev/ttyACM3 (still with only 2 controllers connected), so I would like to be able to confirm that the port I’m using is talking to the controller I intend to.
I’m using Python with the pyserial communication library on Linux - I’m hoping there’s a way to make sure I’m communicating with the device I think I am without having to jump through too many hoops.
However, what I do in a similar situation, is to write udev rules that match the specific USB ports the devices are plugged into. Thus, I’ll write a rule that says something like “when a serial device is plugged into port 0 of bus 1, create a symlink named /dev/_FLmotor.” Repeat for each port that you hook up, with a different symlink name.
Then, in your program, open /dev/_whatever instead of /dev/ttyACM*, and you will be assured that the thing you open is hooked into the given USB port.
Update: I now recommend using /dev/serial/by-id, which has stable names in it for the all of the Simple Motor Controller COM ports. See this thread for more info.
Hello.
Each controller does have a unique serial number and it reports to the computer it in the standard way with a USB string descriptor. You can see the serial numbers with our software and probably also with the lsusb command. There might be a way to write a rule in /etc/udev/rules.d/ that assigns the Simple Motor Controller’s virtual COM port correctly depending on what the serial number of the device is (thanks for the idea, jwatte). Searching for “udev rules serial number” on Google yielded a result where someone wrote ATTRS{serial}==“50E6920B000AE8” in their rules file. I’m not sure how well this will work with composite devices like the Simple Motor Controller though, because the serial number is more a property of the device as a whole, not the virtual COM port.
udev can match (exactly) two layers in the full chain of attributes. Thus, you could say “this has to be a serial endpoint” and “this has to be endpoint 1” (or 0, or whatever,) and “this has to have serial number 1234.” As long as the kernel finds two levels of the device which, when combined, fulfills those requirements, the rule(s) defined for that device will be applied.
I usually do “SYMLINKS+=_blah” and “MODE=0666” so that I can easily find the device through a known handle, and I can open it as regular user, not needing root.
I’m away from my robot right now, so I can’t copy-and-paste, but with the combination of this information and Google, it should be possible to piece this together!
Btw: Thanks to Pololu for putting in unique serial numbers on their devices. It’s the right thing to do, and makes USB truly plug-and-play. Many, many vendors (including Microsoft for their webcams) do not, which is when physical port identification becomes necessary, which then reminds you of the good-old ISA days…
Thank you jwatte! I am glad that the serial numbers are useful for you. In the case of the Simple Motor Controllers, it was particularly easy to implement USB serial numbers because the microcontroller we use already has a unique 96-bit indentifier on it, assigned by the manufacturer. We just convert that data to hex and add a few dashes.
Thanks for the info - I will see if I can use udev to make sure I’m talking to the write devices. I found pyudev (pyudev.readthedocs.org/en/latest/) which will hopefully let me get this to work from my Python app.
