On Thu, Oct 31, 2019, 1:07 PM Jim Ruxton via talk, <talk@gtalug.org> wrote:
Is your user a member of the dialout group? You can't access serial ports unless you are.
Yes I am a member of dialout and I have no problem when my device uses /dev/ttyUSB0 .
Also, 'baudrate=57142' looks a bit odd. 57600 is more standard, but I've seen that number used for a couple of motor controllers.
Yes this is a Dynamixel motor controller , they seem to prefer this baud rate.
Is there a way you can try it without the USB extender?
I can try this later when I have access to it again but I will need to run it eventually with the extension.
Are you using more than one usb serial device? If you are and they are both Prolific devices, there is no way of telling them apart by any device path. They will swap freely at enumeration. Unlike FTDI adapters, Prolific have no serial numbers. I try to avoid having two PL2303s on the same machine, preferring a mix of FTDI, Qinheng and SiLabs.
My problem occurs when I am only using the one adapter. It is an FTDI device.
If a /dev/ttyUSB0 path works then the /dev/serial/* equivalent must work: they're symlinks to the same device. The only time I've seen it not work was in software that hard-coded the device path to be 12 bytes.
Yes the /dev/serial equivalent works as long as it's the equivalent of /dev/ttyUSB0 .
To communicate with the motor I'm using the pyax12 communication library https://github.com/jeremiedecock/pyax12/blob/master/pyax12/connection.py
Thanks,
Persistant connections are usually managed by udisk for block devices and udev for usb. It looks to me like you need to use udevadm to retrieve the serial attributes of the device as well as a vendor id and put a rule in /etc/udev/rules.d udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1 I pulled that command from this primer from another stepper motor setup config, looks like they are an observatory. https://indilib.org/support/tutorials/157-persistent-serial-port-mapping.htm... I seem to recall from older serial modem usb modeswitching the connection required a serial message info type to be sent in order to handshake on connection. I cant be sure thats the case here but perhaps the examples of the rules which are used to create and define the symlink node on the above observatorys rules for persistant links can help. If that does help, one of the features of udev is that udevadm info --attribute-walk will list all the parent connections and you can use the actual device id and one parent id to uniquely identify and bind your adapter in the chain, when it comes to that. Jim
Russell
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk