Re: Trying to load JMRI 5, and JAVA 11
#java
I think I may got JMRI 5/JAVA 11 working on my NEW LAPTOP.
Not sure when an UPDATE might happen, but if what I have works, I might leave it alone
I believe when you get the MACROs setup up? you are able to SAVE as a file for a backup later, if needed.
?
I am only at the Club Rooms once a week, so will see how I go.
?
A silly question to ask and I might know the answer already, is there a way of locking this file so no one else can mess with it, as they can change any MACRO on the hand set
?
?
thanks Graeme
|
Re: Losing occupancy when trying to record a warrant
#warrants
On Wed, May 14, 2025 at 09:28 PM, <dnbroraback@...> wrote:
NX warrants work perfectly. Any ideas would be appreciated.
So when you run this through the problem block it works fine?
--
H.O. Australia (Layout in Progress)
Digikeijs DR5000 LocoNet
JMRI v5.10 DecoderPro/Warrants/CPE/SML/LogixNG
Java: OpenLogic jre-17.0.12.7 ? Windows 10
|
Execute Delayed tripping me up
Sorry, I'm back with another question.? This works perfectly:
?
?
The module specified at A2 gets called four times in quick succession and the local variables passed to it are as expected.? But, I need to introduce a delay between the four times that the module gets called (because I need to slow down the rate at which the four messages get sent to CBUS).? As a first step, I will just add a constant delay and, when that is working, I will make the four delay lengths slightly different, but one step at a time!
?
I read that local variables are handled nicely by Execute Delayed:
?
?
So, I just did this (the only change is at A2):
?
?
My expectation was that the module would still be called four times in quick succession, but with a noticeable delay before. But it didn't get that far!? I got four of these:
?
?
And four of these in the System Console:
?
?
I am probably doing something illogical or even stupid, but I am struggling to see what that message is telling me, or why I am ending up with what appears to be a null local variable.
?
Thanks,
?
Nick
|
Re: NX routing sensor direction
Mike,
If you upload your layout data?xml file to the group's ProblemsBeingWorkedOn file folder, I can review it and provide some feedback.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] NX routing sensor direction Date: Wednesday, May 14, 2025 12:00 PM
That's how it supposed to work, but sometimes I only get one choice, and its the wrong direction. ? Sometimes both sensors are in the right direction but setting a route between them fails to validate. ? Mike Johnson ?
|
Re: How do I hook up a bar code reader to JMRI
That¡¯s unexpected. The same open(..) statement with the same device name worked in the other script. If you want to go back to the jython/serialinput/SerialPortDevice.py script, delete these lines: # now skip 10 lines in hope to flush buffers of partial lines count = 0 while (count < 10) : next = 0 while (next != 13) : next = self.inputStream.read() # 13 is Newline count = count+1 That discards the first 10 lines received on the input, which was why I suggested doing a bunch of reads at the start. If you take the out, it should start printing its input so long as the reader is sending newline (0x0D) characters. The manual says it should be doing the by default, but we¡¯ll see Bob On May 14, 2025, at 10:41?AM, Nick Brownsberger via groups.io <nbrownsbe@...> wrote:
Thanks Bob,
On Wed, May 14, 2025 at 07:55 AM, Bob Jacobsen wrote:
Then start Panelpro and run the script _once_. You don¡¯t have to put anything in the Script Entry window, this script starts itself. The modified code I ran:
.
.
# create one of these; provide the name of the serial port
a = SerialPortTest("/dev/cu.usbserial-ftE1GQVJ¡±)
# set the thread name, so easy to cancel if needed
a.setName("SerialPortTest sample script")
# start running
a.start()
# setup now complete, try to send some bytes
# a.write('H')
# a.write('e')
# a.write('l')
# a.write('l')
# a.write('o')
# a.write('!')
# a.write(0x0D)
# a.flush()
print "End of Script"
Here's the sys console:
09:43:16,744 jmri.script.swing.InputWindow ERROR - Error executing script [AWT-EventQueue-0]
javax.script.ScriptException: purejavacomm.NoSuchPortException: purejavacomm.NoSuchPortException in <script> at line number 71
at org.python.jsr223.PyScriptEngine.scriptException(PyScriptEngine.java:222) ~[jython-standalone-2.7.4.jar:2.7.4]
I can see the port in JMRI if I go to Preferences and elect RFID as the manufacturer. It shows under Serial Port.
I tried a few things in the code but couldn't get it to work. I also noticed when I run jython/serialinput/SerialPortDevice.py it never reaches the print line "ready to process". So it probably never gets to the inputStream statement which might be why it didn't read the barcodes.
Nick
¡ª Bob Jacobsen rgj1927@...
|
Re: ESP32 always updates each time I start EX-installer
Your question is better suited for a DCC-EX forum -- Peter Ulvestad Linux Mint 22.1, JMRI 5.11.6, Java 21.0.7 JMRI Users Group Moderator ( /g/jmriusers ) JMRI Developers Group Moderator ( ) Tam Valley Group Moderator ( ) Sprog-DCC Group Moderator ( ) Edmonton Model Railroad Association ( )
|
Re: Can a single DCC-EX CSB1 run trains AND control turnouts?
Your question is better suited for a DCC-EX forum -- Peter Ulvestad Linux Mint 22.1, JMRI 5.11.6, Java 21.0.7 JMRI Users Group Moderator ( /g/jmriusers ) JMRI Developers Group Moderator ( ) Tam Valley Group Moderator ( ) Sprog-DCC Group Moderator ( ) Edmonton Model Railroad Association ( )
|
Re: Is there a convenient way (mounting a shield, not individual wiring) to turn a switch with an arduino Mega
Your question is better suited for a DCC-EX forum -- Peter Ulvestad Linux Mint 22.1, JMRI 5.11.6, Java 21.0.7 JMRI Users Group Moderator ( /g/jmriusers ) JMRI Developers Group Moderator ( ) Tam Valley Group Moderator ( ) Sprog-DCC Group Moderator ( ) Edmonton Model Railroad Association ( )
|
ESP32 always updates each time I start EX-installer
ESP32 always updates each time I start EX-installer.
How do I make the update stick so that it doesn't do this each time?
--
~gary
|
Can a single DCC-EX CSB1 run trains AND control turnouts?
Can a single CSB1 run trains and control turnouts?
I would like to power the turnouts from the motor shield?
My guess is to designate the turnouts in the arduino?myautomation.h file.
i am new to DCC, so any help would be great
?
~gary
?
|
Is there a convenient way (mounting a shield, not individual wiring) to turn a switch with an arduino Mega
Is there a convenient way (mounting a shield, not individual wires between boards) to turn a Kato solenoid switch with an arduino Mega? I also need the turnout to be throwable in EX-throttle or Wi-throttle in a JMRI panel.?
I would like to do it on the CHEAP, so no accessory or stationary decoders ¡ª just a cheap motor shield to turn 2, 4, or even 8 ?or 16 points.?
The L293D shield looked so promising at first even though it is unsupported hardware (Hah! I said).
?
is there a cheap stackable solution?
there has to be a way (I think?)
--
~gary
|
Re: NX routing sensor direction
That's how it supposed to work, but sometimes I only get one choice, and its the wrong direction.
?
Sometimes both sensors are in the right direction but setting a route between them fails to validate.
?
Mike Johnson
?
|
Audio Icon on Web Panel - Java
Dave S. & Daniel B.
I just picked-up where we left off on DEC 5 2024. We had a thread going and Daniel provided Java code.
Based on Dave's comments on the code I believe I would be left with what's shown in the attached snip.
I saved it as .js but that didn't work when I ran it from Panel Pro.
NY&HV_RR_Yard_Scenes is the name of my panel and?Harbor is the ID of the Audio Icon.
What file extension should I use, .java? Will it run from Panel Pro or from Command line?
?
--
Many thanks in advance!
Vinny DeRobertis ~ Apex, NC
New York & Hudson Valley RR
Windows 7 Pro / Java 11 / JMRI v5.10
Command Station: Digikeijs DR5000.
Booster: Digikeijs DR5033
(4) Samsung A7 10.4" Tablets
Fully Kiosk/Engine Driver v2.37.187
DCC/DMX Gateway: Pricom LLS.
LocoNet Input Modules: Digikeijs DR4088LN
DCC Output Modules:
Digikeijs DR4018 / Yamorc YD8116.
Sensors: Model Train Technology: DETECTOR-HO.
Turnout Motors: MTB MP1
|
Re: Improving JMRI response to sensors
On 14/05/2025 19:16, Dave Sand wrote:
Chris,
What does the ConditionalNG look like? ?Post a screenshot or
the Browse output.
ABC_UD1a is the relay that controls the block directly before the
signal and is set to Closed when the signal is red. That happened
ages in the past as for testing purposes I'm holding the signal at
red. ABC_UD1 is the relay that controls the previous block and has
to be closed when a train pulling coaches that have lighting bar
wiring in them so that they dont interfere with the ABC signal.
The timing shown was with a single train running so the only JMRI
work will be due to block occupancy changing which from the
original trace is signal protecting the previous block becoming
yellow and therefore the ABC relays for that block changing.
However now I have only one LogixNG running on the thread.
I kept the test running and the timing seems to have improved but
since I did not change anything I don't think I can rely on that.
Thanks
You might also add a couple of simple "Log data" messages to
get the LogixNG timing.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] Improving JMRI response to sensors
Date: Wednesday, May 14, 2025 12:45 PM
On 14/05/2025 18:28, Chris
Gerhard via groups.io wrote:
It seems when creating a new
thread for logixNG that does not take effect until you
restart JMRI.
I now have the stop processing
running in it's own thread and will see how that works.
It's much better but it still takes nearly second to respond:
JMRI? < <? CBUS |? 18:33:03.586 ACON NN:256 EN:2? Sensor Active: UDIR1 Long
Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1
JMRI? > >? CBUS |? 18:33:04.523 ACOF NN:266 EN:6? Turnout Closed: ABC_UD1
Long Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
This is running on a raspberry pi 5 which does nothing else
and appears to be idle. I could bypass JMRI in the electronics
but that feels wrong as the logic then appears twice.
--chris
Sorry for the noise
chris
On 14/05/2025 18:16, Chris
Gerhard via groups.io wrote:
I'm trying to get asymetric brake control (ABC) working
and for cases where I have coaches with lighting wiring I
have to switch the ABC circuit based on a sensor. Tis
works, but is very unreliable and it appears to be because
JMRI can take a significant time to process the event. In
this case the first event shown is the sensor detecting
the train and the last event shown is the relay turning on
the ABC circuit to the coaches.
JMRI < < CBUS | 18:08:24.355 ACON NN:256 EN:2 Sensor Active: UDIR1
Long Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1
JMRI < < CBUS | 18:08:24.357 ACON NN:259 EN:14 Sensor Active: UBD2a
Long Event On [+n259e14] Dyn Pri: 2 Min Pri: 3 CAN ID : 4
JMRI > > CBUS | 18:08:25.313 ACON NN:267 EN:15 Turnout Thrown: BBD3
Relay Long Event On [+n267e15] Dyn Pri: 2 Min Pri: 3 CAN
ID : 126 JMRI > > CBUS | 18:08:25.372 ACOF NN:267 EN:16 Turnout Closed: BBD3a
Relay Long Event Off [-n267e16] Dyn Pri: 2 Min Pri: 3 CAN
ID : 126 JMRI > > CBUS | 18:08:26.398 ACOF NN:269 EN:8 Turnout Closed:
MT+N269E8 Long Event Off [-n269e8] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.399 ACOF NN:269 EN:7 Turnout Closed:
MT+N269E7 Long Event Off [-n269e7] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.399 ACON NN:269 EN:6 Turnout Thrown:
MT+N269E6 Long Event On [+n269e6] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.546 ACON NN:262 EN:8 Turnout Thrown: UBD5a
Long Event On [+n262e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.549 ACON NN:269 EN:5 Turnout Thrown:
MT+N269E5 Long Event On [+n269e5] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:4 Turnout Closed:
MT+N269E4 Long Event Off [-n269e4] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:3 Turnout Closed:
MT+N269E3 Long Event Off [-n269e3] Dyn Pri: 2 Min Pri: 3
CAN ID : 126 JMRI > > CBUS | 18:08:26.591 ACOF NN:266 EN:6 Turnout Closed: ABC_UD1
Long Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID :
126 The other events are related to the train leaving the
previous block and so the system clearing the signal and
the ABC relays. The swtiching is being done by LogixNG
which a simple if then else so should not take over 2
seconds, unless it is blocked behind other processing,
even that seems slow.
Is there anyway to speed up processing and or make the
stop actions have a higher priority or run in dedicated
threads?
Thank you
Chris
Attachments:
|
Re: Improving JMRI response to sensors
Chris,
What does the ConditionalNG look like? ?Post a screenshot or the Browse output.
You might also add a couple of simple "Log data" messages to get the LogixNG timing.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Improving JMRI response to sensors Date: Wednesday, May 14, 2025 12:45 PM
On 14/05/2025 18:28, Chris Gerhard via
groups.io wrote: It seems when creating a new thread
for logixNG that does not take effect until you restart JMRI.
I now have the stop processing
running in it's own thread and will see how that works.
It's much better but it still takes nearly second to respond: JMRI? < <? CBUS |? 18:33:03.586 ACON NN:256 EN:2? Sensor
Active: UDIR1 Long Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID
: 1 JMRI? > >? CBUS |? 18:33:04.523 ACOF NN:266 EN:6? Turnout
Closed: ABC_UD1 Long Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN
ID : 126 This is running on a raspberry pi 5 which does nothing else and
appears to be idle. I could bypass JMRI in the electronics but
that feels wrong as the logic then appears twice. --chris
Sorry for the noise
chris
On 14/05/2025 18:16, Chris Gerhard
via groups.io wrote: I'm trying to get asymetric brake control (ABC) working and
for cases where I have coaches with lighting wiring I have to
switch the ABC circuit based on a sensor. Tis works, but is
very unreliable and it appears to be because JMRI can take a
significant time to process the event. In this case the first
event shown is the sensor detecting the train and the last
event shown is the relay turning on the ABC circuit to the
coaches. JMRI < < CBUS | 18:08:24.355 ACON NN:256 EN:2 Sensor Active: UDIR1 Long
Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1 JMRI <
< CBUS | 18:08:24.357 ACON NN:259 EN:14 Sensor Active: UBD2a Long
Event On [+n259e14] Dyn Pri: 2 Min Pri: 3 CAN ID : 4 JMRI >
> CBUS | 18:08:25.313 ACON NN:267 EN:15 Turnout Thrown: BBD3 Relay
Long Event On [+n267e15] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:25.372 ACOF NN:267 EN:16 Turnout Closed: BBD3a Relay
Long Event Off [-n267e16] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.398 ACOF NN:269 EN:8 Turnout Closed: MT+N269E8
Long Event Off [-n269e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACOF NN:269 EN:7 Turnout Closed: MT+N269E7
Long Event Off [-n269e7] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACON NN:269 EN:6 Turnout Thrown: MT+N269E6
Long Event On [+n269e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.546 ACON NN:262 EN:8 Turnout Thrown: UBD5a Long
Event On [+n262e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI
> > CBUS | 18:08:26.549 ACON NN:269 EN:5 Turnout Thrown: MT+N269E5
Long Event On [+n269e5] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:4 Turnout Closed: MT+N269E4
Long Event Off [-n269e4] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:3 Turnout Closed: MT+N269E3
Long Event Off [-n269e3] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.591 ACOF NN:266 EN:6 Turnout Closed: ABC_UD1 Long
Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 The other events are related to the train leaving the
previous block and so the system clearing the signal and the
ABC relays. The swtiching is being done by LogixNG which a
simple if then else so should not take over 2 seconds, unless
it is blocked behind other processing, even that seems slow. Is there anyway to speed up processing and or make the stop
actions have a higher priority or run in dedicated threads? Thank you Chris
Attachments:
|
Re: Improving JMRI response to sensors
On 14/05/2025 18:28, Chris Gerhard via
groups.io wrote:
It seems when creating a new thread
for logixNG that does not take effect until you restart JMRI.
I now have the stop processing
running in it's own thread and will see how that works.
It's much better but it still takes nearly second to respond:
JMRI? < <? CBUS |? 18:33:03.586 ACON NN:256 EN:2? Sensor
Active: UDIR1 Long Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID
: 1
JMRI? > >? CBUS |? 18:33:04.523 ACOF NN:266 EN:6? Turnout
Closed: ABC_UD1 Long Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN
ID : 126
This is running on a raspberry pi 5 which does nothing else and
appears to be idle. I could bypass JMRI in the electronics but
that feels wrong as the logic then appears twice.
--chris
Sorry for the noise
chris
On 14/05/2025 18:16, Chris Gerhard
via groups.io wrote:
I'm trying to get asymetric brake control (ABC) working and
for cases where I have coaches with lighting wiring I have to
switch the ABC circuit based on a sensor. Tis works, but is
very unreliable and it appears to be because JMRI can take a
significant time to process the event. In this case the first
event shown is the sensor detecting the train and the last
event shown is the relay turning on the ABC circuit to the
coaches.
JMRI < < CBUS | 18:08:24.355 ACON NN:256 EN:2 Sensor Active: UDIR1 Long
Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1 JMRI <
< CBUS | 18:08:24.357 ACON NN:259 EN:14 Sensor Active: UBD2a Long
Event On [+n259e14] Dyn Pri: 2 Min Pri: 3 CAN ID : 4 JMRI >
> CBUS | 18:08:25.313 ACON NN:267 EN:15 Turnout Thrown: BBD3 Relay
Long Event On [+n267e15] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:25.372 ACOF NN:267 EN:16 Turnout Closed: BBD3a Relay
Long Event Off [-n267e16] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.398 ACOF NN:269 EN:8 Turnout Closed: MT+N269E8
Long Event Off [-n269e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACOF NN:269 EN:7 Turnout Closed: MT+N269E7
Long Event Off [-n269e7] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACON NN:269 EN:6 Turnout Thrown: MT+N269E6
Long Event On [+n269e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.546 ACON NN:262 EN:8 Turnout Thrown: UBD5a Long
Event On [+n262e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI
> > CBUS | 18:08:26.549 ACON NN:269 EN:5 Turnout Thrown: MT+N269E5
Long Event On [+n269e5] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:4 Turnout Closed: MT+N269E4
Long Event Off [-n269e4] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:3 Turnout Closed: MT+N269E3
Long Event Off [-n269e3] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.591 ACOF NN:266 EN:6 Turnout Closed: ABC_UD1 Long
Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
The other events are related to the train leaving the
previous block and so the system clearing the signal and the
ABC relays. The swtiching is being done by LogixNG which a
simple if then else so should not take over 2 seconds, unless
it is blocked behind other processing, even that seems slow.
Is there anyway to speed up processing and or make the stop
actions have a higher priority or run in dedicated threads?
Thank you
Chris
|
Re: Improving JMRI response to sensors
It seems when creating a new thread for
logixNG that does not take effect until you restart JMRI.
I now have the stop processing running
in it's own thread and will see how that works.
Sorry for the noise
chris
On 14/05/2025 18:16, Chris Gerhard via
groups.io wrote:
toggle quoted message
Show quoted text
I'm trying to get asymetric brake control (ABC) working and for
cases where I have coaches with lighting wiring I have to switch
the ABC circuit based on a sensor. Tis works, but is very
unreliable and it appears to be because JMRI can take a
significant time to process the event. In this case the first
event shown is the sensor detecting the train and the last event
shown is the relay turning on the ABC circuit to the coaches.
JMRI < < CBUS | 18:08:24.355 ACON NN:256 EN:2 Sensor Active: UDIR1 Long
Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1 JMRI <
< CBUS | 18:08:24.357 ACON NN:259 EN:14 Sensor Active: UBD2a Long
Event On [+n259e14] Dyn Pri: 2 Min Pri: 3 CAN ID : 4 JMRI >
> CBUS | 18:08:25.313 ACON NN:267 EN:15 Turnout Thrown: BBD3 Relay
Long Event On [+n267e15] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI
> > CBUS | 18:08:25.372 ACOF NN:267 EN:16 Turnout Closed: BBD3a Relay
Long Event Off [-n267e16] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.398 ACOF NN:269 EN:8 Turnout Closed: MT+N269E8 Long
Event Off [-n269e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.399 ACOF NN:269 EN:7 Turnout Closed: MT+N269E7 Long
Event Off [-n269e7] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.399 ACON NN:269 EN:6 Turnout Thrown: MT+N269E6 Long
Event On [+n269e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.546 ACON NN:262 EN:8 Turnout Thrown: UBD5a Long
Event On [+n262e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.549 ACON NN:269 EN:5 Turnout Thrown: MT+N269E5 Long
Event On [+n269e5] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.550 ACOF NN:269 EN:4 Turnout Closed: MT+N269E4 Long
Event Off [-n269e4] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.550 ACOF NN:269 EN:3 Turnout Closed: MT+N269E3 Long
Event Off [-n269e3] Dyn Pri: 2 Min Pri: 3 CAN ID : 126 JMRI >
> CBUS | 18:08:26.591 ACOF NN:266 EN:6 Turnout Closed: ABC_UD1 Long
Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
The other events are related to the train leaving the previous
block and so the system clearing the signal and the ABC relays.
The swtiching is being done by LogixNG which a simple if then
else so should not take over 2 seconds, unless it is blocked
behind other processing, even that seems slow.
Is there anyway to speed up processing and or make the stop
actions have a higher priority or run in dedicated threads?
Thank you
Chris
|
Improving JMRI response to sensors
I'm trying to get asymetric brake control (ABC) working and for
cases where I have coaches with lighting wiring I have to switch
the ABC circuit based on a sensor. Tis works, but is very
unreliable and it appears to be because JMRI can take a
significant time to process the event. In this case the first
event shown is the sensor detecting the train and the last event
shown is the relay turning on the ABC circuit to the coaches.
JMRI < < CBUS | 18:08:24.355 ACON NN:256 EN:2 Sensor Active: UDIR1 Long Event On [+n256e2] Dyn Pri: 2 Min Pri: 3 CAN ID : 1
JMRI < < CBUS | 18:08:24.357 ACON NN:259 EN:14 Sensor Active: UBD2a Long Event On [+n259e14] Dyn Pri: 2 Min Pri: 3 CAN ID : 4
JMRI > > CBUS | 18:08:25.313 ACON NN:267 EN:15 Turnout Thrown: BBD3 Relay Long Event On [+n267e15] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:25.372 ACOF NN:267 EN:16 Turnout Closed: BBD3a Relay Long Event Off [-n267e16] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.398 ACOF NN:269 EN:8 Turnout Closed: MT+N269E8 Long Event Off [-n269e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACOF NN:269 EN:7 Turnout Closed: MT+N269E7 Long Event Off [-n269e7] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.399 ACON NN:269 EN:6 Turnout Thrown: MT+N269E6 Long Event On [+n269e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.546 ACON NN:262 EN:8 Turnout Thrown: UBD5a Long Event On [+n262e8] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.549 ACON NN:269 EN:5 Turnout Thrown: MT+N269E5 Long Event On [+n269e5] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:4 Turnout Closed: MT+N269E4 Long Event Off [-n269e4] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.550 ACOF NN:269 EN:3 Turnout Closed: MT+N269E3 Long Event Off [-n269e3] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
JMRI > > CBUS | 18:08:26.591 ACOF NN:266 EN:6 Turnout Closed: ABC_UD1 Long Event Off [-n266e6] Dyn Pri: 2 Min Pri: 3 CAN ID : 126
The other events are related to the train leaving the previous
block and so the system clearing the signal and the ABC relays.
The swtiching is being done by LogixNG which a simple if then else
so should not take over 2 seconds, unless it is blocked behind
other processing, even that seems slow.
Is there anyway to speed up processing and or make the stop
actions have a higher priority or run in dedicated threads?
Thank you
Chris
|
Re: NX routing sensor direction
Mike,
NX sensors are placed at block boundaries. ?The "direction" of a NX sensor is defined by which block is being "protected".
Here is a turnout with two block boundaries. In this example, "B-SOO-Jct is the protected block and the NX sensors are placed at the straight and diverging legs of the turnout.
Here is an example of a NX sensor at an anchor point. Normally, signal masts will be placed at the same block boundaries. ?The signal mast logic (SML) will be generated based on the block topology. ?NX will use the SML for route selection. ?If SML has not been created, it will create internal SML at run time. ?If the NX pairs were created using "Full Interlock", then the blocks in the selected route will change to the "alternate track color".
Unused sensors can be deleted from the sensor table. ?A warning will be show if they are still being used.
Dave Sand
----- Original message ----- Subject: [jmriusers] NX routing sensor direction Date: Wednesday, May 14, 2025 2:24 AM
I am trying to set up NX routing, but some turnouts have only one direction shown for the sensor, often the wrong one. This could be because I'm new to JMRI and have tried and failed several times, and this seems to leave junk (sensors) in the xml file. What in the xml file gives the direction for a sensor ? ? Is there any way to list what route will be selected between sensors.? ? Mike Johnson ? ?
|
JMRI v5.11.6 initial run OK
Folks,
I just loaded v5.11.6 and all seems fine.? My previous issue with icon scaling in "Dark Mode" with Layout Editor has been fixed.
?
Thanks,
--
Tom Kane
Purcellville, VA
|
Bob Jacobsen
Peter Ulvestad
gd101
