|
When assigning connections for my two NCE CS, I used to be able to select for each NCE CS connection the communication port by the names as assigned in persistent bindings. This came to light when my RS232 to USB adapter needed replacement. The new adapter has different idVendor and idProduct codes than its predecessor. The bindings dialog was updated and binds as desired but in Preferences > Connections does not show up as the available serial ports. All that is available is USB0 and USB1, when I used to see 'NCE_PHPro' and 鈥楴CE_PowerCab鈥�. Thereby, always attaching to the correct product by its assign names to its intended port.听 I鈥檓 trying to determine what caused this change, an upgrade of PiOS, JMRI or the introduction of the new adapter? 听Now it is hit or miss as to which device gets which port. 听If I check ' ls -l /dev/ttyUSB* ' I see the devices as they were assigned.听
Has anyone experienced this issue? 听I am assuming new versions of the PiOS may not respond to the bindings the same as older version but why would that have changed?.听 John 听Bauchiero
- D&H Model Railroad -听NCE PH-Pro & PowerCab, Pi4b, DCC-EX - JMRI current test version
|
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote: When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port. I am not sure what the bindings dialog is, but the usual way of creating persistent names for devices is with udev rules. These rules use the idVendor and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a name ending in .rules that needs to be updated with the new idVendor and idProduct codes for your new RS232 to USB adapter. Then the rules need to be reloaded ("sudo udevadm control -R") and the device unpluged and plugged in again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Robert,
Incorrect terminology. 听As you stated, I updated the 听'10-usb-serial.rules鈥� file to the new idVendor and idProduct codes for the new PHPro adapter, then reloaded 听鈥檚udo udevadm trigger鈥� 听and devices un-plugged and plugged, with the results 听鈥榣s -l /dev/ttyUSB*鈥� showing the assigned bindings.听
My deviation to your process was not using - the rules need to be reloaded ("sudo udevadm control -R") and the device unpluged and plugged in again - which I will try tomorrow. 听Different process but same results, that I don鈥檛 know?
It鈥檚 the fact that JMRI doesn鈥檛 acknowledge the bound devices in port connections is what perplexes me. They were there once before, when it stopped I don鈥檛 know.听 听
John 听Bauchiero
- D&H Model Railroad -听NCE PH-Pro & PowerCab, Pi4b, DCC-EX - JMRI current test version
toggle quoted message
Show quoted text
On Sep 28, 2024, at 9:35鈥疨M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating persistent names for devices is with udev rules. These rules use the idVendor and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a name ending in .rules that needs to be updated with the new idVendor and idProduct codes for your new RS232 to USB adapter. Then the rules need to be reloaded ("sudo udevadm control -R") and the device unpluged and plugged in again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
-- Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software 听听听听听听听-- Custom Software Services http://www.deepsoft.com/ 听-- Linux Administration Services heller@... 听听听听听听-- Webhosting Services
|
John,
What version of JMRI are you running? 听
The serial library changed after 5.6. 听I believe the symbolic device link issue was fixed with 5.9.3.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Saturday, September 28, 2024 9:38 PM
Robert,
Incorrect terminology. 听As you stated, I updated the 听'10-usb-serial.rules鈥� file to the new idVendor and idProduct codes for the new PHPro adapter, then reloaded 听鈥檚udo udevadm trigger鈥� 听and devices un-plugged and plugged, with the results 听鈥榣s -l /dev/ttyUSB*鈥� showing the assigned bindings.听
My deviation to your process was not using - the rules need to be reloaded ("sudo udevadm control -R") and the device unpluged and plugged in again - which I will try tomorrow. 听Different process but same results, that I don鈥檛 know?
It鈥檚 the fact that JMRI doesn鈥檛 acknowledge the bound devices in port connections is what perplexes me. They were there once before, when it stopped I don鈥檛 know.听
听
John 听Bauchiero
- D&H Model Railroad
-听NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35鈥疨M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
|
I鈥檓 running 5.9.3 currently and could update to .4 as a test.听 John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4B, DCC-EX- JMRI current test version
toggle quoted message
Show quoted text
On Sep 29, 2024, at 12:20鈥疉M, Dave Sand via groups.io <ds@...> wrote:
锘� John,
What version of JMRI are you running? 听
The serial library changed after 5.6. 听I believe the symbolic device link issue was fixed with 5.9.3.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Saturday, September 28, 2024 9:38 PM
Robert,
Incorrect terminology. 听As you stated, I updated the 听'10-usb-serial.rules鈥� file to the new idVendor and idProduct codes for the new PHPro adapter, then reloaded 听鈥檚udo udevadm trigger鈥� 听and devices un-plugged and plugged, with the results 听鈥榣s -l /dev/ttyUSB*鈥� showing the assigned bindings.听
My deviation to your process was not using - the rules need to be reloaded ("sudo udevadm control -R") and the device unpluged and plugged in again - which I will try tomorrow. 听Different process but same results, that I don鈥檛 know?
It鈥檚 the fact that JMRI doesn鈥檛 acknowledge the bound devices in port connections is what perplexes me. They were there once before, when it stopped I don鈥檛 know.听
听
John 听Bauchiero
- D&H Model Railroad
-听NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35鈥疨M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
|
At Sat, 28 Sep 2024 22:38:21 -0400 jmriusers@groups.io wrote:
Robert,
Incorrect terminology. As you stated, I updated the '10-usb-serial.rules'
file to the new idVendor and idProduct codes for the new PHPro adapter, then
reloaded "sudo udevadm trigger" and devices un-plugged and plugged, with
the results "ls -l /dev/ttyUSB*" showing the assigned bindings.
My deviation to your process was not using - the rules need to be reloaded
("sudo udevadm control -R") and the device unpluged and plugged in again -
which I will try tomorrow. Different process but same results, that I
don't know? The udevd deamon does need to reload the rules when you update rules files. Merely editing the rules files does not change how udevd behaves -- the deamon "caches" the rules, until the rules are reloaded (with the udevadm control -R command). Note: rebooting will also (re-)load the rules, Re-triggering the rules without telling the udevd deamon to reload the rules just retriggers the *old* rules, which is exactly the behavior you saw. It's the fact that JMRI doesn't acknowledge the bound devices in port
connections is what perplexes me. They were there once before, when it
stopped I don't know. *JMRI* is not what "acknowledges" the bound devices. JMRI just sees whatever is in /dev/ that is a tty-ish device. What names that are there are what udevd puts there.
John Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35芒聙炉PM, Robert Heller via groups.io <heller辝psoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port. I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
-- Linux Administration Services
heller@... -- Webhosting Services
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Robert,
Followed your instructions to reload ("sudo udevadm control -R鈥�), it gives me the same results, which appears as I had before. This isn鈥檛 a new issue, after replacing the PH-Pro adapter, the Pi has been rebooted many times. It looks like the USB binding exists in /dev/ , but poll_usb.sh doesn鈥檛. The Preference > Connection also doesn鈥檛. To put to bed any uninstalled updates, I updated JMRI to 5.9.4, and java to 17.x.x, neither improved the situation. The photo shows my results. Any other thoughts?听 听 -听NCE PH-Pro & PowerCab, Pi4b, DCC-EX - JMRI 5.9.4 - Java 17.x.x
toggle quoted message
Show quoted text
On Sep 29, 2024, at 9:23鈥疉M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 22:38:21 -0400 jmriusers@groups.io wrote:
Robert,
Incorrect terminology. As you stated, I updated the '10-usb-serial.rules'
file to the new idVendor and idProduct codes for the new PHPro adapter, then
reloaded "sudo udevadm trigger" and devices un-plugged and plugged, with
the results "ls -l /dev/ttyUSB*" showing the assigned bindings.
My deviation to your process was not using - the rules need to be reloaded
("sudo udevadm control -R") and the device unpluged and plugged in again -
which I will try tomorrow. Different process but same results, that I
don't know?
The udevd deamon does need to reload the rules when you update rules files. Merely editing the rules files does not change how udevd behaves -- the deamon "caches" the rules, until the rules are reloaded (with the udevadm control -R command). Note: rebooting will also (re-)load the rules, Re-triggering the rules without telling the udevd deamon to reload the rules just retriggers the *old* rules, which is exactly the behavior you saw. It's the fact that JMRI doesn't acknowledge the bound devices in port
connections is what perplexes me. They were there once before, when it
stopped I don't know.
*JMRI* is not what "acknowledges" the bound devices. 听JMRI just sees whatever is in /dev/ that is a tty-ish device. 听What names that are there are what udevd puts there.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35脙垄脗聙脗炉PM, Robert Heller via groups.io <heller艦epsoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
-- Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software 听听听听听听听-- Custom Software Services http://www.deepsoft.com/ 听-- Linux Administration Services heller@... 听听听听听听-- Webhosting Services
|
John,
I am not sure that this is the official method but it does work.
Copy the jmri.conf file from the JMRI install to ~/.jmri.
Edit the file and add the serial port names. 听If more than one, separate them by using a comma.
When you start JMRI, the names are added to the serial port list in Preferences -> Connections.
After the Save and restart:
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Sunday, September 29, 2024 9:44 PM
Robert,
Followed your instructions to reload ("sudo udevadm control -R鈥�), it gives me the same results, which appears as I had before. This isn鈥檛 a new issue, after replacing the PH-Pro adapter, the Pi has been rebooted many times. It looks like the USB binding exists in /dev/ , but poll_usb.sh doesn鈥檛. The Preference > Connection also doesn鈥檛. To put to bed any uninstalled updates, I updated JMRI to 5.9.4, and java to 17.x.x, neither improved the situation. The photo shows my results. Any other thoughts?听
听
-听NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI 5.9.4
- Java 17.x.x
On Sep 29, 2024, at 9:23鈥疉M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 22:38:21 -0400 jmriusers@groups.io wrote:
Robert,
Incorrect terminology. As you stated, I updated the '10-usb-serial.rules'
file to the new idVendor and idProduct codes for the new PHPro adapter, then
reloaded "sudo udevadm trigger" and devices un-plugged and plugged, with
the results "ls -l /dev/ttyUSB*" showing the assigned bindings.
My deviation to your process was not using - the rules need to be reloaded
("sudo udevadm control -R") and the device unpluged and plugged in again -
which I will try tomorrow. Different process but same results, that I
don't know?
The udevd deamon does need to reload the rules when you update rules files.
Merely editing the rules files does not change how udevd behaves -- the deamon
"caches" the rules, until the rules are reloaded (with the udevadm control -R
command). Note: rebooting will also (re-)load the rules,
Re-triggering the rules without telling the udevd deamon to reload the rules
just retriggers the *old* rules, which is exactly the behavior you saw.
It's the fact that JMRI doesn't acknowledge the bound devices in port
connections is what perplexes me. They were there once before, when it
stopped I don't know.
*JMRI* is not what "acknowledges" the bound devices. 听JMRI just sees whatever
is in /dev/ that is a tty-ish device. 听What names that are there are what
udevd puts there.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35脙垄脗聙脗炉PM, Robert Heller via groups.io <heller艦epsoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
|
*I* know nothing about poll_usb.sh -- where does this file come from? At Sun, 29 Sep 2024 22:44:21 -0400 jmriusers@groups.io wrote:
Robert,
Followed your instructions to reload ("sudo udevadm control -R芒聙聺), it gives me the same results, which appears as I had before. This isn芒聙聶t a new issue, after replacing the PH-Pro adapter, the Pi has been rebooted many times. It looks like the USB binding exists in /dev/ , but poll_usb.sh doesn芒聙聶t. The Preference > Connection also doesn芒聙聶t. To put to bed any uninstalled updates, I updated JMRI to 5.9.4, and java to 17.x.x, neither improved the situation. The photo shows my results. Any other thoughts?
茂驴录
John Bauchiero
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI 5.9.4
- Java 17.x.x
On Sep 29, 2024, at 9:23芒聙炉AM, Robert Heller via groups.io <heller辝psoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 22:38:21 -0400 jmriusers@groups.io wrote:
Robert,
Incorrect terminology. As you stated, I updated the '10-usb-serial.rules'
file to the new idVendor and idProduct codes for the new PHPro adapter, then
reloaded "sudo udevadm trigger" and devices un-plugged and plugged, with
the results "ls -l /dev/ttyUSB*" showing the assigned bindings.
My deviation to your process was not using - the rules need to be reloaded
("sudo udevadm control -R") and the device unpluged and plugged in again -
which I will try tomorrow. Different process but same results, that I
don't know? The udevd deamon does need to reload the rules when you update rules files.
Merely editing the rules files does not change how udevd behaves -- the deamon
"caches" the rules, until the rules are reloaded (with the udevadm control -R
command). Note: rebooting will also (re-)load the rules,
Re-triggering the rules without telling the udevd deamon to reload the rules
just retriggers the *old* rules, which is exactly the behavior you saw.
It's the fact that JMRI doesn't acknowledge the bound devices in port
connections is what perplexes me. They were there once before, when it
stopped I don't know.
*JMRI* is not what "acknowledges" the bound devices. JMRI just sees whatever
is in /dev/ that is a tty-ish device. What names that are there are what
udevd puts there.
John Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35脙聝脗垄脙聜脗聙脙聜脗炉PM, Robert Heller via groups.io <heller脜聻epsoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port. I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
-- Linux Administration Services
heller@... -- Webhosting Services
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
-- Linux Administration Services
heller@... -- Webhosting Services
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
John,
Some additional details.
The previous serial library, purejavacom, had a process to find device names that started with a set of prefixes, 听One of them was ttyUSB. 听For technical reasons, a different serial library needed to be used after JMRI 5.6. 听This library does not include the discovery feature.
For Linux and macOS, JMRI has three methods to specify special serial device names. 听
- Specify the special names in the exported JMRI_SERIAL_PORTS environment variable.
- Add --serial-ports="???" to the command line or icon command argument
- Use the jmri.conf file.
The jmri.conf can also be used with Windows.
The jmri.conf approach is the easiest. 听The "/dev/" prefix is not needed. 听The "ttyUSB" prefix is no longer needed for discovery but can be retained to make the purpose obvious..
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Sunday, September 29, 2024 10:51 PM
John,
I am not sure that this is the official method but it does work.
Copy the jmri.conf file from the JMRI install to ~/.jmri.
Edit the file and add the serial port names. 听If more than one, separate them by using a comma.
When you start JMRI, the names are added to the serial port list in Preferences -> Connections.
After the Save and restart:
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Sunday, September 29, 2024 9:44 PM
Robert,
Followed your instructions to reload ("sudo udevadm control -R鈥�), it gives me the same results, which appears as I had before. This isn鈥檛 a new issue, after replacing the PH-Pro adapter, the Pi has been rebooted many times. It looks like the USB binding exists in /dev/ , but poll_usb.sh doesn鈥檛. The Preference > Connection also doesn鈥檛. To put to bed any uninstalled updates, I updated JMRI to 5.9.4, and java to 17.x.x, neither improved the situation. The photo shows my results. Any other thoughts?听
听
-听NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI 5.9.4
- Java 17.x.x
On Sep 29, 2024, at 9:23鈥疉M, Robert Heller via groups.io <heller@...> wrote:
At Sat, 28 Sep 2024 22:38:21 -0400 jmriusers@groups.io wrote:
Robert,
Incorrect terminology. As you stated, I updated the '10-usb-serial.rules'
file to the new idVendor and idProduct codes for the new PHPro adapter, then
reloaded "sudo udevadm trigger" and devices un-plugged and plugged, with
the results "ls -l /dev/ttyUSB*" showing the assigned bindings.
My deviation to your process was not using - the rules need to be reloaded
("sudo udevadm control -R") and the device unpluged and plugged in again -
which I will try tomorrow. Different process but same results, that I
don't know?
The udevd deamon does need to reload the rules when you update rules files.
Merely editing the rules files does not change how udevd behaves -- the deamon
"caches" the rules, until the rules are reloaded (with the udevadm control -R
command). Note: rebooting will also (re-)load the rules,
Re-triggering the rules without telling the udevd deamon to reload the rules
just retriggers the *old* rules, which is exactly the behavior you saw.
It's the fact that JMRI doesn't acknowledge the bound devices in port
connections is what perplexes me. They were there once before, when it
stopped I don't know.
*JMRI* is not what "acknowledges" the bound devices. 听JMRI just sees whatever
is in /dev/ that is a tty-ish device. 听What names that are there are what
udevd puts there.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
On Sep 28, 2024, at 9:35脙垄脗聙脗炉PM, Robert Heller via groups.io <heller艦epsoft.com@groups.io> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 jmriusers@groups.io wrote:
When assigning connections for my two NCE CS, I used to be able to select
for each NCE CS connection the communication port by the names as assigned
in persistent bindings. This came to light when my RS232 to USB adapter
needed replacement. The new adapter has different idVendor and idProduct
codes than its predecessor. The bindings dialog was updated and binds as
desired but in Preferences > Connections does not show up as the available
serial ports. All that is available is USB0 and USB1, when I used to see
'NCE_PHPro' and "NCE_PowerCab". Thereby, always attaching to the correct
product by its assign names to its intended port.
I am not sure what the bindings dialog is, but the usual way of creating
persistent names for devices is with udev rules. These rules use the idVendor
and idProduct values. So, somewhere in /etc/udev/rules.d/ is a file with a
name ending in .rules that needs to be updated with the new idVendor and
idProduct codes for your new RS232 to USB adapter. Then the rules need to be
reloaded ("sudo udevadm control -R") and the device unpluged and plugged in
again.
I'm trying to determine what caused this change, an upgrade of PiOS, JMRI or
the introduction of the new adapter? Now it is hit or miss as to which
device gets which port. If I check ' ls -l /dev/ttyUSB* ' I see the devices
as they were assigned.
Has anyone experienced this issue? I am assuming new versions of the PiOS
may not respond to the bindings the same as older version but why would that
have changed?.
John 听Bauchiero
- D&H Model Railroad
- NCE PH-Pro & PowerCab, Pi4b, DCC-EX
- JMRI current test version
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
--
Robert Heller 听听听听听听听听听听听听-- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software 听听听听听听听-- Custom Software Services
http://www.deepsoft.com/ 听-- Linux Administration Services
heller@... 听听听听听听-- Webhosting Services
|
Dave Sand, 听 That line added to the ~/.jmri/jmri.conf file did the trick. I had been in that file before but didn鈥檛 remember why. For me the file was already installed, I don鈥檛 know if it was originally installed, or if I placed it there. First test I commented out the line:
诲别蹿补耻濒迟冲辞辫迟颈辞苍蝉="-顿辫颈4箩.濒颈苍办颈苍驳=诲测苍补尘颈肠鈥�
And replaced it with听
default_options="--serial-ports=/dev/ttyUSB_NCE_PH_Pro, /dev/ttyUSB_PowrCab鈥�
In the final version I decided to leave both default_options= lines in the script, since it works either way. Should I have left it out since it is a legacy option? Later, I will experiment with truncating the tty ports 听to see how that works. After adding the ports, it did not take until I saved and _rebooted_. A simple restart of JMRI didn鈥檛 work. 听 This answers the issue I had when a new Steve Todd JMRI 5.8 image was installed on the Pi5 which would not display bound ports. It was the departure from the serial library after 5.6. I will revisit the Pi5 to add the patch.
Thanks for your help. A new page will be added to my programming info book.听
听John 听Bauchiero - D&H Model Railroad -听NCE PH-Pro & PowerCab, Pi4b, DCC-EX - JMRI 5.9.4
toggle quoted message
Show quoted text
On Sep 30, 2024, at 9:56 AM, Dave Sand via groups.io <ds@...> wrote:
John,
Some additional details.
The previous serial library, purejavacom, had a process to find device names that started with a set of prefixes, 听One of them was ttyUSB. 听For technical reasons, a different serial library needed to be used after JMRI 5.6. 听This library does not include the discovery feature.
For Linux and macOS, JMRI has three methods to specify special serial device names. 听
- Specify the special names in the exported JMRI_SERIAL_PORTS environment variable.
- Add --serial-ports="???" to the command line or icon command argument
- Use the jmri.conf file.
The jmri.conf can also be used with Windows.
The jmri.conf approach is the easiest. 听The "/dev/" prefix is not needed. 听The "ttyUSB" prefix is no longer needed for discovery but can be retained to make the purpose obvious..
<Screenshot 2024-09-30 at 8.49.39鈥疉M.png>
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Problems with Persistent PI4 USB ports
Date: Sunday, September 29, 2024 10:51 PM
John,
I am not sure that this is the official method but it does work.
Copy the jmri.conf file from the JMRI install to ~/.jmri.
Edit the file and add the serial port names. 听If more than one, separate them by using a comma.
<Screenshot 2024-09-29 at 10.35.57鈥疨M.png>
When you start JMRI, the names are added to the serial port list in Preferences -> Connections.
<Screenshot 2024-09-29 at 10.37.25鈥疨M.png>
After the Save and restart:
<Screenshot 2024-09-29 at 10.35.02鈥疨M.png>
Dave Sand
|
Dave Sand,听
I followed your suggestion to add serial port names to the jmri.conf file which worked perfectly for 5.9.3.听 You wrote: 听[I am not sure that this is the official method but it does work. Edit听the file and add the serial port names. 听If more than one, separate them by using a comma.]
After versioning up to 5.9.5 by skipping 5.9.4, I ended up with _two sets_ of听symbolic device links which only became apparent since I change the spelling of the names for the jmri.conf file.听 You wrote: 听[The serial library changed after 5.6. 听I believe the symbolic device link issue was fixed with 5.9.3].听 The symbolic device links fix must have been after 5.9.3. 听All is good again.听 听 John 听Bauchiero -听NCE PH-Pro & PowerCab, Pi4b, DCC-EX - JMRI 5.9.5 - Java 17.0.11
|
John Bauchiero