开云体育

Block occupancy without resistive wheelsets


 

To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?


 

开云体育

Here a method used by the modular Free-mo groups that do signaling. It is call MSS for Modular Signal Standard. It uses block track detectors to see the locos and anything drawing power from the rails. But to catch all the cars that likely do not have resistive wheelsets they use an optic detector at each block boundary. What it does it holds each block as active until the optic detector is no longer triggered.

?

When I train is passing from one block to the next, first the loco triggers the optic but then continues on and keeps the track block detector active. Next the cars keep both blocks active until the last car passes the optic detector. At that point the prior block clears. Now if the loco hasn’t reached the other end of the block, that block is active because of the loco. However it the loco has hit the next block, then the cars behind it are triggering the local block (and the next block too). This keeps this block active as if all those cars had resistors.

?

If you look at the website, you might get the clues from the graphics and other explanations there. Now you don’t need that interconnecting for a normal layout. All that’s because we never know which way the modules end up getting placed into the layout.

?

But the idea of combining current detection with the optic at the boundaries is really pretty good at giving the right results regardless of how many cars have resistive wheelsets. Only catch is they won’t detect a broken train that lost a car in the middle of a block.

?

-Ken Cameron, Member JMRI Dev Team

?

?


 

yes adding further physical detectors is a solution.? however surely there is a software solution?


 

What do you mean by "record its length"? ?

Dave Sand


----- Original message -----
From: "p.lavers via groups.io" <p.lavers=[email protected]>
Subject: [jmriusers] Block occupancy without resistive wheelsets
Date: Tuesday, March 18, 2025 7:28 PM

To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?


 

That JMRI has the facility to store the train length. This would allow the calculation of the position of the end of the train.


 

Operations has a max train length value. ?This is used to limit train sizes between switching locations.

Dispatcher has a max train length for automatically controlled trains.

I am not aware of any other places where train length might be stored. ?

Dave Sand


----- Original message -----
From: "p.lavers via groups.io" <p.lavers=[email protected]>
Subject: Re: [jmriusers] Block occupancy without resistive wheelsets
Date: Tuesday, March 18, 2025 9:48 PM

That JMRI has the facility to store the train length. This would allow the calculation of the position of the end of the train.


 

It can be done in Java. I? fact, I am doing something in Java on topmof JMRI that has train lengths (standard jmri doesn't have it for running trains, only for the relatively stand-alone "operations").

Using the information for positioning is not at all straightforward, though, because the positioning "brains" must at all times be aware of speed changes, too.

A further complication is, that this would be relatively easy for standard trains, but when adding and removing wagons the overhead of people having to add those changes to the "train" (a concept not present in java!) is considerable unless it can be automated with strategically placed RFID units. So a layout that uses unchanging passenger trains would be better served than one with lots of shunting of goods trains.

In short: it sounds much easier than it is.

Wouter


On Wed, 19 Mar 2025, 00:28 p.lavers via , <p.lavers=[email protected]> wrote:
To ensure the whole train is considered when assessing block occupancy by current sensors and not just the current drawing locomotive the standard solution is resistive wheelsets. However JMRI knows (with speed profiling) the speed of a train and can also record its length. Along with block length these values would allow a calculation of the block occupied by the end of the train. Would it therefore not be possible to show a block as occupied until the end of the train had left it? I can't find any information on this functionality within JMRI. Is this something that could be implemented on top of JMRI in (say) python or java? Anyone explored this? Any ideas?


 

My mainline freights always have a last car with a FRED which is drawing power. A lighted caboose would be the same. So the occupancy light trips as soon as the loco enters, and doesn't release until the last car leaves. No need for resistor wheels on intermediate rolling stock.


 

Hi
Dispatcher runs trains automatically or with manual drivers need only the head of the train detectable and a length for the train.
After the head leaves a block it shows that the block is unoccupied but allocated (so it cannot be allocated to another train) until the calculated end of the train exits the block.
It uses pessamistic assumptions about the position of the head in an occupied block.
You can also use Head and tail detection so a single car detected car at the rear is required. Lighted caboose , track powered FRED.
The major down side of head only is the failure to detect broken trains, so I would never use them for an exhibition piece.
Steve G.
?


 

The dispatcher functionality was only implemented from 5.10. I need to update and have a look. I was impressed by which implements a solution in the detector hardware (arduino) to calculate (estimate) the end of train position. It will be interesting to compare all the options!?


 

Roger,

With turnouts in a separate block, and not even very long trains, you'd see the occupancy indicator of the turnout go off while both blocks at either side remain on - unless there's added logic.

Wouter

On Wed, 19 Mar 2025 at 12:17, Roger Thomas via <rogert=[email protected]> wrote:
My mainline freights always have a last car with a FRED which is drawing power. A lighted caboose would be the same. So the occupancy light trips as soon as the loco enters, and doesn't release until the last car leaves. No need for resistor wheels on intermediate rolling stock.


 

开云体育

Brsidesa, you are trusting the operator to run at a very precise speerd. Probably impossible. Rspecially with track conditions and other issues.

?

Dana Zimmerli

Z System Designs

?

From: [email protected] <[email protected]> On Behalf Of Dave Sand
Sent: Tuesday, March 18, 2025 8:18 PM
To: [email protected]
Subject: Re: [jmriusers] Block occupancy without resistive wheelsets

?

Operations has a max train length value. ?This is used to limit train sizes between switching locations.

?

Dispatcher has a max train length for automatically controlled trains.

?

I am not aware of any other places where train length might be stored. ?

?

Dave Sand

?

?

----- Original message -----

From: "p.lavers via groups.io" <p.lavers=[email protected]>

Subject: Re: [jmriusers] Block occupancy without resistive wheelsets

Date: Tuesday, March 18, 2025 9:48 PM

?

That JMRI has the facility to store the train length. This would allow the calculation of the position of the end of the train.

?


 

Yes, there is a"software" solution ... rather two solutions now.
Steve_G added a "ghost" block to be connected to a turnout.
When both real detectors on either side of the turnout are active, the "ghost" is active.
?
I haven't used the "ghost" as my layout predates that feature.
I summarize my "software" approach in my blog ?...
--
Ken
NYNH&H, Old Colony Division, Cape Cod Branch (1949-1959)
Loconet * JMRI 5.11.1 * OSX,Win10,Ubuntu
Blog: ?
Youtube:


 

On Thu, Mar 20, 2025 at 04:15 AM, Dana wrote:
Brsidesa, you are trusting the operator to run at a very precise speerd. Probably impossible. Rspecially with track conditions and other issues.
Considering those issues, JMRI Warrants don't use train length but does provide for 'Automatic Speed Profiling'. Essentially calculating the time a train should take to traverse a block.
If you used the Roster Speed Profiling tool most likely you ran an engine running light over a straight level track. With Warrant dynamic speed profiling, measurements are made over straight level track, but also upgrade, down grade, curved gently or severely, running light or pulling 30+ cars. The track speeds are not going to be all the same for a given throttle setting. When merging, new values are averaged with the old, with the intention of a composite speed profile that reflects average use.
www.jmri.org/help/en/package/jmri/jmrit/logix/SpeedChanges.shtml
?
--
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