At Sat, 28 Sep 2024 22:38:21 -0400
[email protected] 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辝[email protected]> wrote:
At Sat, 28 Sep 2024 21:21:40 -0400 [email protected] 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
