On Sep 29, 2024, at 12:20?AM, 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 -----

From: John Bauchiero <john4dhmr@...>

To:?[email protected]

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 ?’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?

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.?

?

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@...> 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

http://www.deepsoft.com/ ?-- Linux Administration Services

heller@... ??????-- Webhosting Services