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’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??
?
-?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@...> 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 <
[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
--
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
