[GTALUG] Problem with /dev/ttyUSB* serial port

xerofoify xerofoify at gmail.com
Thu Oct 31 16:14:49 EDT 2019


On Thu, Oct 31, 2019 at 1:07 PM Jim Ruxton via talk <talk at 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,
>
> Jim
>
>
>>
>>
>
> ---
> Post to this mailing list talk at gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
>
> ---
> Post to this mailing list talk at gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
Just chipping in but in my experience a directory or file is created
but not uncreated when mounting devices hot. However a udev rule will
fix the mount point as
as otherwise udev and the kernel would just mount where there is a
open device file or create a new one(this happens more often in my
experience).
So whoever mentioned udev rules that would be the easiest way,
Nick


More information about the talk mailing list