Problem with /dev/ttyUSB* serial port
I have a device plugged into an active USB extender that usually shows up as /dev/ttyUSB0 when I first plug it in (occasionally it will show up as /dev/ttyUSB1 when first plugging it in) . If it is /dev/ttyUSB0 when I unplug it and plug it back in it occasionally changes to /dev/ttyUSB1 . Is there a way that I can always have it show up as /dev/ttyUSB0 . I'm not sure why /dev/ttyUSB0 isn't being released and restarted after unplugging and replugging it. If I look in /dev it does disappear as /dev/ttyUSB0 from there when I unplug it but like I said it reappears as /dev/ttyUSB1? I am on Ubuntu 18.04.3 LTS . Thanks for any pointers. Jim
I have a device plugged into an active USB extender that usually shows up as /dev/ttyUSB0 when I first plug it in (occasionally it will show up as /dev/ttyUSB1 when first plugging it in) . If it is /dev/ttyUSB0 when I unplug it and plug it back in it occasionally changes to /dev/ttyUSB1 . Is there a way that I can always have it show up as /dev/ttyUSB0 . I'm not sure why /dev/ttyUSB0 isn't being released and restarted after unplugging and replugging it. If I look in /dev it does disappear as /dev/ttyUSB0 from there when I unplug it but like I said it reappears as /dev/ttyUSB1? I am on Ubuntu 18.04.3 LTS .
Thanks for any pointers. My guess would be that if the USB is unplugged or otherwise disrupted
On 10/31/19 2:25 AM, Jim Ruxton via talk wrote: the kernel will start taking down the interface but this will take some time. If in that intervening time the device is plugged back in then there will be some remnants of ttyUSB0 left so the kernel will pick the next device ttyUSB1. You could test this by quickly plugging/unplugging your usb device and compare the results to plugging and unplugging with a few second delay between the events. -- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
On 10/31/19 2:25 AM, Jim Ruxton via talk wrote:
I have a device plugged into an active USB extender that usually shows up as /dev/ttyUSB0 when I first plug it in (occasionally it will show up as /dev/ttyUSB1 when first plugging it in) . If it is /dev/ttyUSB0 when I unplug it and plug it back in it occasionally changes to /dev/ttyUSB1 . Is there a way that I can always have it show up as /dev/ttyUSB0 . I'm not sure why /dev/ttyUSB0 isn't being released and restarted after unplugging and replugging it. If I look in /dev it does disappear as /dev/ttyUSB0 from there when I unplug it but like I said it reappears as /dev/ttyUSB1? I am on Ubuntu 18.04.3 LTS .
Thanks for any pointers.
Thinking on this some more. You could try using /dev/serial/by-path or /dev/serial/by-id "ls /dev/serial/by-path/" -> pci-0000:00:12.2-usb-0:3.5:1.0-port0 "ls /dev/serial/by-id" -> usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 These should stay device and connection tree uinque -- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
Thanks. I tried /dev/serial/by-id and although my python program looks like it should work ie. it accepts serial_connection = Connection(port="/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL03EO23-if00-port0", baudrate=57142) Its not sending out serial data. This is the same result if I have to use /dev/ttyUSB1 . For some reason my python program only works when using /dev/ttyUSB0 . For this reason I am not sure if adding a udev rule will work though I will give it a try. If the device shows up as /dev/ttyUSB1 and I rename it to /dev/ttyUSB0 this works but then I need to remove it manually when unplugging it. I also tried waiting a long time between unplugging and plugging the usb device but /dev/ttyUSB0 is not restored. It's a strange problem. I am wondering if it has to do with the baud rate I am using , maybe /dev/ttyUSB0 works with baudrate=57142 but /dev/ttyUSB1 doesn't in python? Jim On 2019-10-31 8:16 a.m., Alvin Starr via talk wrote:
On 10/31/19 2:25 AM, Jim Ruxton via talk wrote:
I have a device plugged into an active USB extender that usually shows up as /dev/ttyUSB0 when I first plug it in (occasionally it will show up as /dev/ttyUSB1 when first plugging it in) . If it is /dev/ttyUSB0 when I unplug it and plug it back in it occasionally changes to /dev/ttyUSB1 . Is there a way that I can always have it show up as /dev/ttyUSB0 . I'm not sure why /dev/ttyUSB0 isn't being released and restarted after unplugging and replugging it. If I look in /dev it does disappear as /dev/ttyUSB0 from there when I unplug it but like I said it reappears as /dev/ttyUSB1? I am on Ubuntu 18.04.3 LTS .
Thanks for any pointers.
Thinking on this some more. You could try using /dev/serial/by-path or /dev/serial/by-id "ls /dev/serial/by-path/" -> pci-0000:00:12.2-usb-0:3.5:1.0-port0 "ls /dev/serial/by-id" -> usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0
These should stay device and connection tree uinque
Is your user a member of the dialout group? You can't access serial ports unless you are. Also, 'baudrate=57142' looks a bit odd. 57600 is more standard, but I've seen that number used for a couple of motor controllers. Is there a way you can try it without the USB extender? 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. 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. Cheers Stewart
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@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
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
On Thu, Oct 31, 2019 at 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,
Jim
--- 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
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
On Thu, 31 Oct 2019 at 02:25, Jim Ruxton via talk <talk@gtalug.org> wrote:
Is there a way that I can always have it show up as /dev/ttyUSB0
I think the proper way is to provide a udev rule to identify the device and assign a fixed name to it. https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-... -- Scott
I will try this but I am worried that if the device symlinks to /dev/ttyUSB1 it's not going to work since whenever I use anything but /dev/ttyUSB0 my device doesn't work. Jim On Thu., Oct. 31, 2019, 9:12 a.m. Scott Allen via talk, <talk@gtalug.org> wrote:
On Thu, 31 Oct 2019 at 02:25, Jim Ruxton via talk <talk@gtalug.org> wrote:
Is there a way that I can always have it show up as /dev/ttyUSB0
I think the proper way is to provide a udev rule to identify the device and assign a fixed name to it.
https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-...
-- Scott --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On 2019-10-31 9:11 a.m., Scott Allen via talk wrote:
On Thu, 31 Oct 2019 at 02:25, Jim Ruxton via talk <talk@gtalug.org> wrote:
Is there a way that I can always have it show up as /dev/ttyUSB0
I think the proper way is to provide a udev rule to identify the device and assign a fixed name to it.
https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-...
The other option is to write your software so that it gets notified when a USB device is installed/removed. You will be told the actual device name. I needed to do this to detect insertion/removal of a barcode reader. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include <disclaimer/favourite> | --Chris Hardwick
Is there a way that I can always have it show up as /dev/ttyUSB0
I think the proper way is to provide a udev rule to identify the device and assign a fixed name to it.
https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-...
The other option is to write your software so that it gets notified when a USB device is installed/removed. You will be told the actual device name. I needed to do this to detect insertion/removal of a barcode reader.
The problem isn't really identifying the USB device. It is the fact that the software I am using only works when the device shows up as /dev/ttyUSB0 . When it shows up as /dev/ttyUSB1 it doesn't work. For some reason the motor control software I am using will only work if the serial port shows up as /dev/ttyUSB0 so I was hoping I could have it show up as this every time the device is inserted. I will try setting up a udev rule to do this . Jim
On Thu, Oct 31, 2019 at 09:13:15PM -0400, Jim Ruxton via talk wrote:
The problem isn't really identifying the USB device. It is the fact that the software I am using only works when the device shows up as /dev/ttyUSB0 . When it shows up as /dev/ttyUSB1 it doesn't work. For some reason the motor control software I am using will only work if the serial port shows up as /dev/ttyUSB0 so I was hoping I could have it show up as this every time the device is inserted. I will try setting up a udev rule to do this .
Well looking at that python code you linked to, it appears that if you forget to tell it the port when making a connection, it defaults to ttyUSB0. Maybe you have a spot in the code that forgets to pass the port rgumentand that makes it only work when the name is ttyUSB0. I am curious if changing that default in the code to something different (like /dev/ttyUSBwrong) would make it always fail even when it is ttyUSB0. If so, you could then hunt down where the connection is being done without a port parameter and fix it once and for all. -- Len Sorensen
On 10/31/19 6:24 PM, Kevin Cozens via talk wrote:
On 2019-10-31 9:11 a.m., Scott Allen via talk wrote:
On Thu, 31 Oct 2019 at 02:25, Jim Ruxton via talk <talk@gtalug.org> wrote:
Is there a way that I can always have it show up as /dev/ttyUSB0
I think the proper way is to provide a udev rule to identify the device and assign a fixed name to it.
https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-...
The other option is to write your software so that it gets notified when a USB device is installed/removed. You will be told the actual device name. I needed to do this to detect insertion/removal of a barcode reader.
Looking at the actual code it is setting a default value of /dev/ttyUSB0. It should not be defaulting when you try to set it in the call but it may be interesting to set the default to /dev/null so that it will not do something that may be reasonable part of the time. When you say that you cannot get anything but /dev/ttyUSB0 to work it makes me ask is there a problem that is causing the default to always be taken. Forcibly breaking things can be a useful tool. -- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
The other option is to write your software so that it gets notified when a USB device is installed/removed. You will be told the actual device name. I needed to do this to detect insertion/removal of a barcode reader.
Looking at the actual code it is setting a default value of /dev/ttyUSB0. It should not be defaulting when you try to set it in the call but it may be interesting to set the default to /dev/null so that it will not do something that may be reasonable part of the time.
When you say that you cannot get anything but /dev/ttyUSB0 to work it makes me ask is there a problem that is causing the default to always be taken.
Forcibly breaking things can be a useful tool.
Thanks very much for looking at the code. I believe I found my culprit. I had another daemon running in the background for a lighting program that was trying to get a lock on /dev/ttyUSB1 . If I stop that daemon loading /dev/ttyUSB1 will now work for me. I'm going to reconfigure that daemon to leave the serial ports alone since I am not using that feature of the lighting program. Thanks again to everyone who helped me with this. In the process I also set up a udev rule so I can now just load my serial port as /dev/motor and let udev create the symlinks . Cheers, Jim
participants (8)
-
Alvin Starr -
Jim Ruxton -
Kevin Cozens -
lsorense＠csclub.uwaterloo.ca -
Russell Reiter -
Scott Allen -
Stewart Russell -
xerofoify