Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Am 30.09.2024 um 15:50 schrieb Vinny DeRobertis: When I run it from windows it continues to take a screen shot every 4 seconds until I close the DOS window but when I run it from Bob's script it takes 1 screen shot and ends. I get the screenshots until I quit JMRI. My script: import java java.lang.Runtime.getRuntime().exec(["C:/temp/screenshot.bat", ""]) I'm running Windows 10. Klaus
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Good idea... a little MORE brute force won't hurt.
|
Windows also has built in Snipping Tool which allows you to get the whole screen or just a region.
--
-splasher in somd
-NCE PowerCab with Raspberry Pi 3b+ and JMRI
-DCC-EX with Arduino Mega听w/motor shield, Raspberry Pi 3b+ and JMRI
-Using听听Engine Driver with both
-Generally running the latest dev version of JMRI & Engine Driver
|
Locked
Re: Problems with Persistent PI4 USB ports
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:
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:
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
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
It鈥檚 a bit brute force, but you could write a JMRI script or LogixNG that calls your .bat file every four seconds. Bob On Sep 30, 2024, at 9:50鈥疉M, Vinny DeRobertis via groups.io <vinny.derobertis@...> wrote:
When I run it from windows it continues to take a screen shot every 4 seconds until I close the DOS window but when I run it from Bob's script it takes 1 screen shot and ends. 鈥� Bob Jacobsen rgj1927@...
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
When I run it from windows it continues to take a screen shot every 4 seconds until I close the DOS window but when I run it from Bob's script it takes 1 screen shot and ends.
|
Locked
Re: Problems with Persistent PI4 USB ports
*I* know nothing about poll_usb.sh -- where does this file come from? At Sun, 29 Sep 2024 22:44:21 -0400 [email protected] 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辝[email protected]> wrote:
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
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Attached .bat renamed.txt
听
It takes a screenshot every 4 seconds.
|
Do a Google search for your particular OS version.
Win+ PrtScr is one suggestion for windows
Alt+PrtScn works for me in Linux Mint
--
Peter Ulvestad
JMRI Users Group Moderator ( )
Tam Valley Group Moderator ( )
Sprog-DCC Group Moderator ( )
Edmonton Model Railroad Association ( )
|
Hi,
听
How can i get screenshot of my JRMI screens (Shift + Ctrl + S doesn't work) ?
听
听
|
Hi,
听
I am new to JRMI.
听
Do you know if there is somewhere (Web, PDF, video) a place to get information for about aytomation using warrants, but a very simple example?
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Vinny,
Can you show us the batch file you are trying to run?
Daniel
On 2024-09-29 20:31, Vinny DeRobertis
wrote:
toggle quoted message
Show quoted text
Bob, I got the logix NG to call the script that calls the
batch file however, the batch file only stays in it's loop for 1
iteration. When I run the batch file outside of JMRI it opens a
DOS window and stays in its loop until I close the DOS window.
When I call the batch file using the script, the DOS window does
not open. The batch file runs and then immediately ends.
|
Locked
Re: Problems with Persistent PI4 USB ports
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:
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:
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
|
Locked
Re: Problems with Persistent PI4 USB ports
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 [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
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
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Vinny,
You can use an indirect notification from Windows using the LogixNG "File as flag" expression which can then run the Jython script. 听See听
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Execute a Windows Batch File from LogixNG or Script #logixng
Date: Sunday, September 29, 2024 9:14 PM
Vinny,
You cannot call a Jython script from outside of the JMRI/Java world.
It would be helpful to know what you are actually trying to do. 听What does the bat file do?
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Execute a Windows Batch File from LogixNG or Script #logixng
Date: Sunday, September 29, 2024 7:26 PM
...rephrasing, how can I call a jython script x.py from within a windows/DOS batch file?
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Vinny,
You cannot call a Jython script from outside of the JMRI/Java world.
It would be helpful to know what you are actually trying to do. 听What does the bat file do?
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Execute a Windows Batch File from LogixNG or Script #logixng
Date: Sunday, September 29, 2024 7:26 PM
...rephrasing, how can I call a jython script x.py from within a windows/DOS batch file?
|
Locked
Re: test release 5.9.4 linux withrottle server problem
Jim,
If you feel more adventurist, you can download a nightly build which already has the fix.
I use these all the time.
--
Peter Ulvestad
JMRI Users Group Moderator ( )
Tam Valley Group Moderator ( )
Sprog-DCC Group Moderator ( )
Edmonton Model Railroad Association ( )
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
...rephrasing, how can I call a jython script x.py from within a windows/DOS batch file?
|
Locked
Re: Execute a Windows Batch File from LogixNG or Script
#logixng
Well, that did not work.
What about this... how would I call the jython script from the command line? That would solve this for me.
|
Locked
Re: JMRI Error: Service mode programmer NCE is offline.
#nce
Hi En-TACT. As Ken has suggested, the LEDs on the USB Interface blink briefly while there is communication, on steady, you have a problem. Please install ALL the USB Interface Jumpers, see Dave Heap's suggestion at: /g/jmriusers/topic/28324670?p=Created,,,20,2,0,0 This morning I was having trouble with my USB Interface, after I removed it from my Jiffy Box, to observe the LEDs. Problem turned out to be the Cab Bus RJ12 Socket "Wipers" were pushed down too far. Adjusted Wipers with an Exacto Knife & tested okay. During this above troubleshooting, sometimes one LED remained illuminated. Can you please make sure the Wipers in the RJ12 socket are not pushed down too far - please adjust them up but make sure the Wipers are located in their respective Slots at the Rear. Your issue could be one or more of the RJ12 Socket Wipers could be too far down - loosing connection. Please check ALL RJ12 Sockets on the Power Cab, PCP & USB Interface. Regards Marcus
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of Ken Cameron Sent: Monday, 30 September 2024 2:48 AM To: [email protected]Subject: Re: [jmriusers] 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 -- This email has been checked for viruses by Avast antivirus software. www.avast.com
|
splasher
Bob Jacobsen
Peter Ulvestad
John Bauchiero