开云体育

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.

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

开云体育

开云体育

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

开云体育

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

From: "Chris Gerhard via groups.io" <chris=[email protected]>

To:?[email protected]

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:

• OpenPGP_signature.asc