开云体育

JMRI PanelPro 4.12+Rb6a9bb1
Java 1.8.0_131
NCE Procab V1.3
MAC Mini running OSX 10.9.5.
I have modified a script based on Bob Jacobsen’s “AutomatonExample.py”.
There are four sensors, three track based (IR), to detect a vehicle moving over them, the other a push button to start the script loop. The USB to serial connection has a length of about 10 feet, with the adapter mounted in the middle of that run.
All works fine controlling a tram (streetcar) negotiating what in essence is a triangular route with stops and direction reversal at each apex. All sensors are connected to an NCE AIU which sends the state of the sensors to the control bus and hence to JMRI. Occasionally (maybe once in every 10 or so runs), it appears that the state change of a sensor is missed, despite it being reported correctly on the AIU. This causes the tram to miss a “stop” command - not at all desirable, as we now have a runaway tram! Also, at times it appears that the stop command is delayed somewhat causing the tram to overrun its intended stop location.
Any ideas as to the cause?
Thanks.
Derek

If you open the JMRI Sensor table and watch, do you see the sensor changing status when the problem happens?

The AIU inputs are polled by the command station, so really short inputs can be missed. So the first thing to track down is whether the problem is getting the into into JMRI, or whether it’s getting to JMRI getting lost.

Bob

On Dec 18, 2018, at 7:11 AM, d.uttley via Groups.Io <d.uttley@...> wrote:

JMRI PanelPro 4.12+Rb6a9bb1
Java 1.8.0_131
NCE Procab V1.3
MAC Mini running OSX 10.9.5.
I have modified a script based on Bob Jacobsen’s “AutomatonExample.py”.
There are four sensors, three track based (IR), to detect a vehicle moving over them, the other a push button to start the script loop. The USB to serial connection has a length of about 10 feet, with the adapter mounted in the middle of that run.
All works fine controlling a tram (streetcar) negotiating what in essence is a triangular route with stops and direction reversal at each apex. All sensors are connected to an NCE AIU which sends the state of the sensors to the control bus and hence to JMRI. Occasionally (maybe once in every 10 or so runs), it appears that the state change of a sensor is missed, despite it being reported correctly on the AIU. This causes the tram to miss a “stop” command - not at all desirable, as we now have a runaway tram! Also, at times it appears that the stop command is delayed somewhat causing the tram to overrun its intended stop location.
Any ideas as to the cause?
Thanks.
Derek

--
Bob Jacobsen
rgj1927@...

Hi Bob. I can see the sensor states changing when the script is running and the trams are triggering them. I have not been lucky enough to catch if the state changes, or not, when the issue occurs. However, covering the sensor that has been “missed” with my finger causes the tram to stop, indicating that the script was still waiting for a state change before continuing. Note that the problem is not dedicated to any one of the sensors. The script normally does exactly as required, but then, out of the blue, the tram fails to stop where it should. The AIU leds tell me that the sensors are operating correctly.
Could it be a data traffic/timing issue causing the change in state to be missed?
A little more info - when a tram passes over a sensor, the AIU indicates more than one change of state, when the front, middle and rear sections of the tram pass over the sensor. However, the state of the JMRI sensor only changes once.
Thoughts?