Date

Locked Re: test release 5.9.4 linux withrottle server problem

 

From the 5.9.4 Release notes:
WiThrottle Server does not work properly in this release. (crashes when sending Turnouts or Routes), It will be fixed in 5.9.5 and 5.10. Workaround is to disable Turnouts and Routes under Preferences, WiThrottle Server, Allowed Controls


Locked Re: test release 5.9.4 linux withrottle server problem

 

Jim,

Start JMRI. Try to connect to the WiThrottle server with the Engine Driver app on your Android phone. Then go to JMRI menu Help -> System Console. Click the button "Copy to clipboard". Paste it in a reply to this email.

Daniel

On 2024-09-29 16:26, Jim Albanowski wrote:

Building a rescued PC for a friend to run his railroad using JMRI/WiThrottle server.
This is Linux Mint 20.3 and 21.3 with various kernels.
Started with 5.9.4 and found that WiThrottle server starts and sees its stand alone router showing the IP that it's listening on. It will connect to a throttle (TCS or Android WiThrottle app) at the router level but not to the server... no connected throttle is shown. Though the TCS throttle shows a connected and "WT". Android WiThrottle displays the JMRI IP but does not respond when attempting to connect.
Dropping back to official 5.8 release is fine. I did not test if this is unique to 5.9.4 perhaps starting with lower 5.9.x...
Jim Albanowski


Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

Well those cable ends look great. But the two lights on the USB should
never stay lit, they should only blink briefly as traffic passes
between the units. It becoming stuck on is not good. But somebody else
might recall what it means about which one becomes stuck.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com


Locked Re: Any way to view System Console on remote browser? #webserver

 

If you enable "Frames" under Web Server you can see the system console if you've already opened it.
Dan


Locked Any way to view System Console on remote browser? #webserver

 

Howdy all, with thoughts and prayers for those affected by the storm.
Is there any way to view the System Console on a remote browser? I am using JMRI 5.9.4 with Java 11.0.23.
During Op Sessions at the Club (tsmri.org), I have panels that I load and scripts that can print info to the system console. I start the Web Server (and WiThrottle and LN over TCP servers) and then as "Station Operator", I use a tablet, phone, or laptop on one Panel to click on sensors reporting OS's of trains at stations (Ready, Depart, Arrive or Terminate). The Dispatcher has a browser open and views the other panel (screenshot embedded) to see the track plan and where the trains are (according to the Station Operator's reports: no occupancy sensing or signals). I also display (on that Panel), the last five reports with time, Station, Train and Action and they roll off when a new one is sent.
I originally had just four lines each with an indicator that is lit until acknowledged), but added a fifth since sometimes the reports are sent fast and furious (in a two hour session, reporting 17 trains at 8 different stations). However, it occurred to me that since I tailored the scripts to print each report (sequentially of course), I realized that if the Dispatcher could view the System Console (maybe a different browser window), he would be able to "catch up" if he missed any and verify his logs.
I searched for any relevant topics here, and cannot find any setting in JMRI to allow that view. Thanks for any help!
Phil


Locked test release 5.9.4 linux withrottle server problem

 

Building a rescued PC for a friend to run his railroad using JMRI/WiThrottle server.
This is Linux Mint 20.3 and 21.3 with various kernels.
Started with 5.9.4 and found that WiThrottle server starts and sees its stand alone router showing the IP that it's listening on. It will connect to a throttle (TCS or Android WiThrottle app) at the router level but not to the server... no connected throttle is shown. Though the TCS throttle shows a connected and "WT". Android WiThrottle displays the JMRI IP but does not respond when attempting to connect.
Dropping back to official 5.8 release is fine. I did not test if this is unique to 5.9.4 perhaps starting with lower 5.9.x...
Jim Albanowski


Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

Hello Marcus and Ken,
Following the manual, I played around with the jumpers and baud rate and was able to get a power light on the USB connection-side. I set the baud rate to 9600 and jumpers are: 1 = ON | 2 = OFF | 3 = ON | 4 = ON
However, no light for the CAB Bus side.
Here are the endpoints of my cables included in the NCE Power Cab. BTW when everything is connected, I get a red light on the Power Cab panel.
a. Flat cable for NCE Power Cab to Power Cab panel.
B. Coiled cable for NCE USB Interface to Power Cab panel.


Locked Re: Dispatcher Scripting support #dispatcher #scripting

 

Hi Ken, Thanks for the answer I successfully create the next transit but my need is to be able to trigger some allocation in scripting.


Locked Re: Dispatcher Scripting support #dispatcher #scripting

 

Hi Steve, thanks for your reply and your time. Maybe I am not looking at the good routines.
I am running the trains manually, in most case autoallocating to next safe section is perfectly doing the job. But in some specific cases I really would be happy to allocate to the train one more section than the next safe section. I don't think this has something to do with starting a new train.
I can successfully manage it manually by clicking the "Allocate" button as shown in my previous message but given that I know the specific circumstance where I want to do so I would be happy to be able to automate those clicks on "Allocate". Any more thoughts?


Locked Re: Problems with Persistent PI4 USB ports

 

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 <hellere[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


Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

EnTact,

Your logs show the com port is acting fine. But when JMRI asks if the
command station is there, it gets no answer. I think you said you had
all the jumpers on (pin 1 doesn't matter) so the baud rate is
matching. There are two very little LEDs on the USB interface card.
They should flash when traffic goes from either side. If the LEDs get
stuck on, that's a bad sign but meaningful.

Usual case here is a faulty cable between the USB board and the cab
bus. Those cables must be a data type cord meaning straight through,
not the phone type cord which flips the wires between the ends. If you
hold both ends of the cord next to each other, side by side by the
cords, the colors of wire in the cords should match exactly. If they
mirror each other instead, that's a telco type cord.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com


Locked Re: Problems with Persistent PI4 USB ports

 

I’m 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

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







Locked Re: Problems with Persistent PI4 USB ports

 

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







Locked Re: Problems with Persistent PI4 USB ports

 

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








Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

Hi En-TACT

Is your Power Cab plugged in to the PCP (Panel) ?

Do you have the PCP Red LED illuminated ?

Regards

Marcus

From: [email protected] <[email protected]> On Behalf Of En-TACT
Sent: Sunday, 29 September 2024 10:54 AM
To: [email protected]
Subject: Re: [jmriusers] JMRI Error: Service mode programmer NCE is offline. #nce

20:52:47,554 apps.util.Log4JUtil INFO - * JMRI log ** [main]
20:52:47,578 apps.util.Log4JUtil INFO - This log is stored in file: C:\Users\ncred\JMRI\log\session.log [main]
20:52:47,578 apps.util.Log4JUtil INFO - This log is appended to file: C:\Users\ncred\JMRI\log\messages.log [main]
20:52:47,608 apps.AppsBase INFO - DecoderPro version 5.8+Rbc21ce2ce7 starts under Java 11.0.21 on Windows 10 amd64 v10.0 at Sat Sep 28 20:52:47 EDT 2024 [main]
20:52:47,743 apps.gui3.Apps3 INFO - Starting with profile My_JMRI_Railroad.3f401755 [main]
20:52:47,910 jmri.util.node.NodeIdentity INFO - Using e0cbe18a-b6bd-4cd2-9171-60bb6dd788d2 as the JMRI storage identity for profile id 3f401755 [AWT-EventQueue-0]
20:52:47,993 xml.AbstractSerialConnectionConfigXml INFO - Starting to connect for "NCE" [main]
20:52:48,062 .jmrix.nce.usbdriver.UsbDriverAdapter INFO - Connecting NCE USB to COM4 USB Serial [main]
20:52:48,066 .jmrix.nce.usbdriver.UsbDriverAdapter INFO - Port COM4 USB-SERIAL CH340 (COM4) opened at 19200 baud, sees DTR: true RTS: true DSR: false CTS: false DCD: false flow: NONE [main]
20:52:48,463 jmri.jmrit.roster.Roster INFO - Reading roster file with rootFromName(C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\roster.xml) [main]
20:52:48,735 jmri.util.FileUtilSupport INFO - File path program: is C:\Program Files (x86)\JMRI\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path preference: is C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path profile: is C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path settings: is C:\Users\ncred\JMRI\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path home: is C:\Users\ncred\ [main]
20:52:48,737 jmri.util.FileUtilSupport INFO - File path scripts: is C:\Program Files (x86)\JMRI\jython\ [main]
20:52:58,206 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 0 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:52:58,316 jmri.jmrix.nce.NceConnectionStatus WARN - Incorrect or no response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:08,318 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 1 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:08,429 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:18,443 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 2 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:18,555 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:28,559 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 3 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:28,667 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:38,677 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 4 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:38,786 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
----------- Begin Stack Trace -----------

_._,_._,_


Virus-free.


Locked Re: Problems with Persistent PI4 USB ports

 

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


Locked Problems with Persistent PI4 USB ports

 

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




Locked Re: NCE Accessory Event Monitoring and possibly CS-105 #nce

 

On Sat, Sep 28, 2024 at 06:07 PM, <trevor@...> wrote:
Just wanted to thank you @Dan - I didn't know that the PHPro reported turnout status and I switched all my points to "Monitoring" and it works a charm. Super excellent. Thank you.
You're welcome, it was the very first Java program I wrote for JMRI in 2007. There's also the ability to lock a NCE turnout.
Dan


Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

20:52:47,554 apps.util.Log4JUtil INFO - * JMRI log ** [main]
20:52:47,578 apps.util.Log4JUtil INFO - This log is stored in file: C:\Users\ncred\JMRI\log\session.log [main]
20:52:47,578 apps.util.Log4JUtil INFO - This log is appended to file: C:\Users\ncred\JMRI\log\messages.log [main]
20:52:47,608 apps.AppsBase INFO - DecoderPro version 5.8+Rbc21ce2ce7 starts under Java 11.0.21 on Windows 10 amd64 v10.0 at Sat Sep 28 20:52:47 EDT 2024 [main]
20:52:47,743 apps.gui3.Apps3 INFO - Starting with profile My_JMRI_Railroad.3f401755 [main]
20:52:47,910 jmri.util.node.NodeIdentity INFO - Using e0cbe18a-b6bd-4cd2-9171-60bb6dd788d2 as the JMRI storage identity for profile id 3f401755 [AWT-EventQueue-0]
20:52:47,993 xml.AbstractSerialConnectionConfigXml INFO - Starting to connect for "NCE" [main]
20:52:48,062 .jmrix.nce.usbdriver.UsbDriverAdapter INFO - Connecting NCE USB to COM4 USB Serial [main]
20:52:48,066 .jmrix.nce.usbdriver.UsbDriverAdapter INFO - Port COM4 USB-SERIAL CH340 (COM4) opened at 19200 baud, sees DTR: true RTS: true DSR: false CTS: false DCD: false flow: NONE [main]
20:52:48,463 jmri.jmrit.roster.Roster INFO - Reading roster file with rootFromName(C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\roster.xml) [main]
20:52:48,735 jmri.util.FileUtilSupport INFO - File path program: is C:\Program Files (x86)\JMRI\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path preference: is C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path profile: is C:\Users\ncred\JMRI\My_JMRI_Railroad.jmri\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path settings: is C:\Users\ncred\JMRI\ [main]
20:52:48,736 jmri.util.FileUtilSupport INFO - File path home: is C:\Users\ncred\ [main]
20:52:48,737 jmri.util.FileUtilSupport INFO - File path scripts: is C:\Program Files (x86)\JMRI\jython\ [main]
20:52:58,206 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 0 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:52:58,316 jmri.jmrix.nce.NceConnectionStatus WARN - Incorrect or no response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:08,318 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 1 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:08,429 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:18,443 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 2 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:18,555 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:28,559 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 3 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:28,667 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
20:53:38,677 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 4 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:38,786 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]
----------- Begin Stack Trace -----------
-----------------------------------------
[2] Reference Handler
[email protected]/java.lang.ref.Reference.waitForReferencePendingList(Native Method)
[email protected]/java.lang.ref.Reference.processPendingReferences(Unknown Source)
[email protected]/java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
-----------------------------------------
[24] nce.NceTrafficController Receive thread
app//com.fazecast.jSerialComm.SerialPort.readBytes(Native Method)
app//com.fazecast.jSerialComm.SerialPort.readBytes(SerialPort.java:827)
app//com.fazecast.jSerialComm.SerialPort$SerialPortInputStream.read(SerialPort.java:2025)
[email protected]/java.io.DataInputStream.read(Unknown Source)
app//jmri.jmrix.AbstractMRTrafficController.readByteProtected(AbstractMRTrafficController.java:994)
app//jmri.jmrix.AbstractMRTrafficController.loadChars(AbstractMRTrafficController.java:1025)
app//jmri.jmrix.AbstractMRTrafficController.handleOneIncomingReply(AbstractMRTrafficController.java:1098)
app//jmri.jmrix.AbstractMRTrafficController.receiveLoop(AbstractMRTrafficController.java:907)
app//jmri.jmrix.AbstractMRTrafficController$2.run(AbstractMRTrafficController.java:830)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
[5] Attach Listener
-----------------------------------------
[15] AWT-Shutdown
[email protected]/java.lang.Object.wait(Native Method)
[email protected]/java.lang.Object.wait(Unknown Source)
[email protected]/sun.awt.AWTAutoShutdown.run(Unknown Source)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
[23] nce.NceTrafficController Transmit thread
[email protected]/java.lang.Object.wait(Native Method)
app//jmri.jmrix.AbstractMRTrafficController.transmitWait(AbstractMRTrafficController.java:537)
app//jmri.jmrix.AbstractMRTrafficController.transmitLoop(AbstractMRTrafficController.java:504)
app//jmri.jmrix.AbstractMRTrafficController$1.run(AbstractMRTrafficController.java:805)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
[18] AWT-EventQueue-0
java.base/java.lang.Thread.getStackTrace(Unknown Source)
apps.SystemConsole.performStackTrace(SystemConsole.java:529)
apps.SystemConsole.lambda$createFrame$3(SystemConsole.java:256)
java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
java.desktop/java.awt.Component.processEvent(Unknown Source)
java.desktop/java.awt.Container.processEvent(Unknown Source)
java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
java.desktop/java.awt.EventQueue$4.run(Unknown Source)
java.desktop/java.awt.EventQueue$4.run(Unknown Source)
java.base/java.security.AccessController.doPrivileged(Native Method)
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
java.desktop/java.awt.EventQueue$5.run(Unknown Source)
java.desktop/java.awt.EventQueue$5.run(Unknown Source)
java.base/java.security.AccessController.doPrivileged(Native Method)
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
-----------------------------------------
[3] Finalizer
[email protected]/java.lang.Object.wait(Native Method)
[email protected]/java.lang.ref.ReferenceQueue.remove(Unknown Source)
[email protected]/java.lang.ref.ReferenceQueue.remove(Unknown Source)
[email protected]/java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
-----------------------------------------
[4] Signal Dispatcher
-----------------------------------------
[19] TimerQueue
[email protected]/jdk.internal.misc.Unsafe.park(Native Method)
[email protected]/java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
[email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
[email protected]/java.util.concurrent.DelayQueue.take(Unknown Source)
[email protected]/javax.swing.TimerQueue.run(Unknown Source)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
[12] Common-Cleaner
[email protected]/java.lang.Object.wait(Native Method)
[email protected]/java.lang.ref.ReferenceQueue.remove(Unknown Source)
[email protected]/jdk.internal.ref.CleanerImpl.run(Unknown Source)
[email protected]/java.lang.Thread.run(Unknown Source)
[email protected]/jdk.internal.misc.InnocuousThread.run(Unknown Source)
-----------------------------------------
[28] DestroyJavaVM
-----------------------------------------
[14] Java2D Disposer
[email protected]/java.lang.Object.wait(Native Method)
[email protected]/java.lang.ref.ReferenceQueue.remove(Unknown Source)
[email protected]/java.lang.ref.ReferenceQueue.remove(Unknown Source)
[email protected]/sun.java2d.Disposer.run(Unknown Source)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
[16] AWT-Windows
[email protected]/sun.awt.windows.WToolkit.eventLoop(Native Method)
[email protected]/sun.awt.windows.WToolkit.run(Unknown Source)
[email protected]/java.lang.Thread.run(Unknown Source)
-----------------------------------------
----------- End Stack Trace -----------
20:53:48,795 mri.jmrix.AbstractMRTrafficController WARN - Timeout on reply to message: AA consecutive timeouts = 5 in nce.NceTrafficController [nce.NceTrafficController Transmit thread]
20:53:48,904 jmri.jmrix.nce.NceConnectionStatus WARN - No response from NCE command station [nce.NceTrafficController Transmit thread]


Locked Re: JMRI Error: Service mode programmer NCE is offline. #nce

 

Hello Marcus,
I'm on Windows 10 64-bit and here are CH340's settings and driver info in Device Manager: