Topics

Proposed Signal Mast Logic Change


wombat_rrnut
 

To borrow a phrase from the Medical community: First, do no harm.

 

I want to modify the behavior of Signal Mast Logic as regards the Restricting aspect.

Important note: There is NOTHING wrong with its current implementation.

I will talk about design, etc., before I give you the real world reason why I want this

(at the end).

 

Design criteria:

#1.) Only the CTC system would need and use this new feature.  It will not be available to the

outside world (i.e. existing JMRI GUI editors) , except thru Python (since it’s a public

interface).  And that is fine.

 

#2.) The default for this feature is “do not modify the existing behavior of SML”.

So this change would not affect the field (i.e. existing users), nor any existing

SML test procedures.  I would code additional tests in the SML test procedures

to verify it works properly.

 

#3.) This feature would only be a runtime setting, it would NOT be retained

within the xml files (state saved/restored) in any way.

 

How does it work:

It would be similar to how “held” works presently, WITHOUT the checkbox in

the SML Editor (Tools/Tables/etc.…)

 

When “set”, it would force the signal to Red, to prevent the “restricting”

aspect from being displayed to a following train.  Ergo why it is similar to “held”.

(I have to do complex “gymnastics” in CTC code order to make this work,

trying to combine it with the existing CTC “held” logic would needlessly

complicate code in places when the new feature is not needed – which is most

of the time).

 

 

Alternatives:

(Sensor in SML table).

 

Instead of this mod, I could have put a sensor in the SML sensors table

that did the same thing so that no existing SML code would need to be modified.

However, that would require the user to define another sensor, give it’s

definition to my software, and remember to put it in the SML table.

CTC being “user” complex already just didn’t need the added complexity.

 

Any other ideas for implementation would be appreciated.

 

 

 

Why do I want this? (If you want to read the whole thing):

 

The problem is the “real world”: The joke is: “All thinking stops as you descend

the staircase into the train room”.  How that applies will follow.

 

The scenario:

(same ABS, APB (whatever) (i.e. non CTC) or CTC):

 

I put on a restricting aspect onto a mainline SignalMast, do not mark it “disabled”,

and the next block is marked “permissive”.

 

Why? so that I can display a “restricting” aspect for a call-on, i.e. a back to train

movement which happens a lot on model railroads.

 

Presently, this works fine.  The problem occurs as follows:

(ABS, or if fleeting is enabled in CTC):

If there are two trains following each other, the trailing train will see a restricting

aspect (proper!) at this O.S. section when the leading train is in the block ahead.

This is actually prototype practice.

The REAL engineer of the following train would KNOW that the restricting aspect is

not for them, as they are not going to “work the train ahead of them” or some

such.

 

On our model RR’s, we have a variety of skill levels of operators.  And we do not

operate every day, maybe once a month.  I cannot rely on the fact that the operators

will first remember and then realize that that “Restricting” is NOT for them, and just

head into the next block, and possibly smash into the backend of a train hidden

around a curve (for instance).  Most don’t even realize what “Restricting is” or

also what the rules for “Restricting” is (as I found out the first time I implemented it).

 

I even have a lot of real engineers, they would know, but what they don’t know is whether

that “restricting” applies to them (it obviously would be on a train by train basis, for example:

Pushers OK to pass restricting, passenger train ignore and stay stopped).

 

And then there is the case of a lot of out of town operators who know nothing

of my layout.  They don’t have the time for all of the instructions as it is…

They’ve driven a long distance, and they want to run trains……

 

 

Sincerely

Greg Bedlek

(CTC guy)

 

 


Bob Jacobsen
 

I very much don’t understand this part. Perhaps there’s a typo or missing word?

Presently, this works fine. The problem occurs as follows:
(ABS, or if fleeting is enabled in CTC):
If there are two trains following each other, the trailing train will see a restricting
aspect (proper!) at this O.S. section when the leading train is in the block ahead.
This is actually prototype practice.
The REAL engineer of the following train would KNOW that the restricting aspect is
not for them, as they are not going to “work the train ahead of them” or some
such.
1) Is there a railroad where the _default_ on entry to an occupied CTC OS section is Restricting? If so, can somebody please explain how that works? Neither the logic nor the dispatcher would know which train was in the OS section.

2) Perhaps my confusion is from not understanding what “would KNOW that that the restricting aspect is not for them”. What does that mean in terms of the trains' behaviors? Restricting rules on the western railroads I’m familiar with (e.g. SP rule 9.1.12) is “Proceed at restricted speed”. That’s a _mandatory_ indication. It’s not “Proceed at restricted speed if you think this applies to you”; the train must move if it can. Are there railroads where Restricting is optional?


I think improving SignalMast and SML support for Restricting is fine. I must be misunderstanding this, though, as the way it treats Stop and Restricting seems inverted to me.

Bob

Bob Jacobsen
@BobJacobsen


wombat_rrnut
 

Bob:

I've had off-line conversations, which I'm sorry I didn't include
in my "big" email. And I'm sorry. I also didn't explain my self well enough.

It is not the (short) O.S. section that is occupied by the first train (I may have misled you), but the (long) block beyond.
But from SML's viewpoint, the SML logic includes both the O.S. section and the block beyond, and treats them the same,
from the vantage point of the signal controlling entry into the O.S. section.

Let me say also, that I'm NOT an expert in this, so I'm "leaning" on others to help me. Hopefully they can explain
it better than I did by chiming in here.......
But keep in mind in my opinion is that JMRI is correct as to its present implementation of restricting.
(I'm just modifying it to be "incorrect" to help "inexperienced" (I'm being kind!) crews) :-) :-)


Let me give one quote from some of the responses, leaving names off for now (they can pipe in if they feel so inclined)....

Quote:
Just Sunday, I saw a 12"-to-the-foot prototype signal displaying a "Permissive" indication, given at an automatic control point at location where the railroad the transitions from current-of-traffic to Rule 261 territory. The signal allowing entrance to the 261 territory protects a chunk of track with a station. A train was stopped at the station. A second train was approaching from behind. The absolute signal displayed a "Restricting" indication, by design, for the case where the second train must come up behind the first train and switch that train or give it a shove. Or the case where the first train was stopped for water or coal, with the end of the train still occupying the station's block.

This operation and indication was _ENTIRELY_ automatic. And, as was usual for this operation, the "Restricting" signal was not "taken" by the following train, as there was no need for the second train to do any switching or shoving. If the 2nd train had come upon that signal, it likely would have stopped short, and waited for a less-restrictive indication. By the time the 2nd train "took" the signal, the first train had moved ahead a few blocks, and the indication had improved to "Clear".
End quote.....

I don't know if this helps the understanding. I may have overstated my contrived example.....

Regarding you statement ", as the way it treats Stop and Restricting seems inverted to me."?
Can you elaborate further, unless I've cleared it up with the above?


Sincerely
Greg

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Saturday, August 22, 2020 7:55 PM
To: jmri@jmri-developers.groups.io Notification <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

I very much don’t understand this part. Perhaps there’s a typo or missing word?

Presently, this works fine. The problem occurs as follows:
(ABS, or if fleeting is enabled in CTC):
If there are two trains following each other, the trailing train will
see a restricting aspect (proper!) at this O.S. section when the leading train is in the block ahead.
This is actually prototype practice.
The REAL engineer of the following train would KNOW that the
restricting aspect is not for them, as they are not going to “work the
train ahead of them” or some such.
1) Is there a railroad where the _default_ on entry to an occupied CTC OS section is Restricting? If so, can somebody please explain how that works? Neither the logic nor the dispatcher would know which train was in the OS section.

2) Perhaps my confusion is from not understanding what “would KNOW that that the restricting aspect is not for them”. What does that mean in terms of the trains' behaviors? Restricting rules on the western railroads I’m familiar with (e.g. SP rule 9.1.12) is “Proceed at restricted speed”. That’s a _mandatory_ indication. It’s not “Proceed at restricted speed if you think this applies to you”; the train must move if it can. Are there railroads where Restricting is optional?


I think improving SignalMast and SML support for Restricting is fine. I must be misunderstanding this, though, as the way it treats Stop and Restricting seems inverted to me.

Bob

Bob Jacobsen
@BobJacobsen


Bob M.
 

Bob J.,

I understand that it is fairly common to find passenger stations, especially in "commuter territory" where passenger train density is high, signaled in such a way where one train makes a station stop at the platform, and a following train gets a "Restricting" indication to allow it to proceed into the occupied block. This type of signaling helps optimize operations at the station, where optimizing track usage can significantly help optimize train capacity of the line.

I would argue that Greg's comment of "The REAL engineer of the following train would KNOW that the restricting aspect is not for them" is not accurate and/or needs to be re-worded; any signal indication that a crew receives _must_ be treated as if it applies to them, unless they are aware of some condition that should require a _more_ restrictive indication. In typical US operating rules, in such cases of known-incorrect indication, the crew must treat the indication as "the most-restrictive indication which the signal may give".

I don't think that's what Greg was trying to imply. I'll leave it to Greg to clarify.

Note that for the "allow a second train into the block where the station is" case, it isn't necessarily important for the dispatcher to know that two trains exist in that block. But it may be important to maintain train spacing once beyond the station. In such case, the next block would likley be protected by a signal which cannot display "Restricting" or any other "Permissive" indication. This would allow "normal" signaling practice to enforce train spacing in the block(s) beyond the station block.

I have a vague recollection of hearing of an Employee Timetable which specified that other-than-passenger trains must treat a "Restricting" indication on Signal X as a "Stop" signal. I cannot put my hands on the specifics, though. Such a case would make "Restricting" indication optional - the train crew would need to determine how to interpret that indication depending on train type.

Regards,
Bob M.


Ken Cameron
 

I've been collecting details from dispatchers about the call-on and
return-to-train feature. Both were used by the CTC to cause a restricting to
show where it otherwise would have been a stop due to occupied track.

It required the CTC direction to be selected, the OS to be unoccupied (ie
clear route inside the interlocking), but the other block (movement into) is
occupied. It would only display as long as the OS was unoccupied, the OS
going occupied released the restricting and it returned to stop.

I was researching so I could correctly program the ladder logic (sort of) in
LCC nodes for the signals. Knowing which would override which was important.
It seems to me that it is a transitory state that is cleared as soon as
anything else in OS changed, just like the hold being reset. Part of it has
the hold being released (traffic direction selected on the CTC) and the
track conditions fit.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Bob Jacobsen
 

The following paragraph is not generally true, although there are certainly cases where it is:

Note that for the "allow a second train into the block where the station is" case, it isn't necessarily important for the dispatcher to know that two trains exist in that block. But it may be important to maintain train spacing once beyond the station. In such case, the next block would likley be protected by a signal which cannot display "Restricting" or any other "Permissive" indication. This would allow "normal" signaling practice to enforce train spacing in the block(s) beyond the station block.

The problem is that allowing a train into a block using RESTRICTING leaves that train _not_ protected against an oncoming train unless the oncoming train has also accepted a RESTRICTING signal. That’s the “able to stop in _half_ the visible distance” part of the Restricting rule. METRA had an accident in the 60’s due to this.


But all this is about how/when to use RESTRICTING, not so much about how to build a better restricting capability into JMRI's SignalMasts and SML. So perhaps we should get back to that.

The relay-driven CTC systems I’ve been working on have relays that, when pulled in, transform a STOP to RESTRICTING. See for example pages 142/144 and 158/159 of https://www.jonroma.net/media/signaling/standards/na/AAR.%20Typical%20circuits%20representing%20current%20practice%20for%20railway%20signaling.%201971.pdf

So a similar thing for SignalHead would be to add a `setPreferRestrictingToStopWhenHeld(..)`, which would show RESTRICTING instead of STOP when it’s set and Held is set. (A shorter method name would be good, of course)

Although that requires setting both Held and this new setting, which might be considered redundant, I think it’s much cleaner for the existing JMRI code. That already handles Held properly, and this is just a small perturbation to that in the logic. Logic that wants to set RESTRICTING independently could still do so.

If instead of that call there was a setToRestrictingEvenIfHeldIsSet(..) call instead, there’d be a larger number of places that would need to check for it.

But as written, I think this paragraph is a bad idea:

When “set”, it would force the signal to Red, to prevent the “restricting”
aspect from being displayed to a following train. Ergo why it is similar to “held”.
(I have to do complex “gymnastics” in CTC code order to make this work,
trying to combine it with the existing CTC “held” logic would needlessly
complicate code in places when the new feature is not needed – which is most
of the time).
Please note that the existing Held already does _exactly_ what that first sentence says. If you set a SignalMast to any aspect, and then set Held, it goes to STOP. In order to make the paragraph make sense as written, it seems that STOP is no longer the slowest in normal operations, replaced always by RESTRICTING. That seems backwards.

Bob


Bob Jacobsen
@BobJacobsen


Bob Jacobsen
 

One last prototype bit:

On Aug 22, 2020, at 7:14 PM, Bob M. <jawhugrps@...> wrote:

I understand that it is fairly common to find passenger stations, especially in "commuter territory" where passenger train density is high, signaled in such a way where one train makes a station stop at the platform, and a following train gets a "Restricting" indication to allow it to proceed into the occupied block. This type of signaling helps optimize operations at the station, where optimizing track usage can significantly help optimize train capacity of the line.
Assume no signal exiting the station platform (common in North America, less common elsewhere).

Train A1 has passed a CLEAR and stopped at the station. Train B2 has passed a RESTRICTING and pulling in behind.

A1 leaves. What rule(s) control to the next signal?

(Hint: The Feb 1996 MARC/Amtrak accident was due to the engineer getting this wrong https://www.ntsb.gov/investigations/AccidentReports/Reports/RAR9702.pdf )

I don’t know of a railroad where CLEAR is the answer; I’d love to know about one. Many say “proceed prepared to stop at the next signal” via their “delayed in block rule” because by the time the delayed train is at the next signal, that signal may have dropped. But some, typically West Coast, including the 1950’s SP, used RESTRICTING here; that motivated them to put a signal quite soon after the station to avoid traveling long distances at slow speeds.

Next B2 pulls up, does the station stop, and leaves. What rule(s) control to the next signal?

The only safe answer is RESTRICTING. The engineer must take responsibility to visually keep the train safe, as the signal system cannot help here. Note that A1 might be stopped short of the next signal; "proceed prepared to stop at the next signal” is thus _not_ safe for B2. The need to be governed by RESTRICTING has multiple problems: It’s slow; it makes the delayed-in-block rule complicated on railroads that allow APPROACH (“if you’re delayed in block, what you do depends on………”); it has led to accidents due to engineer error.


This could be quite a cool thing to model, particularly if your engineers are really into the details of the rules. And if it goes wrong, it’s unlikely people will get killed….

Bob

Bob Jacobsen
@BobJacobsen


Bob M.
 

Bob J.,

The prototype I refer to which implements "Restricting" behind a train in a block at a passenger station is on a local "tourist" railroad. The train typically makes its station stop with the loco about 300 feet short of the next signal in advance, which is clearly visible when stopped at the station. That next signal is, I believe, Aboslute. The next signal in advance of that is an Absolute signal that may only display "Restricting" for movements to Yard trackage, and is also clearly visible when the train is stopped at the station.

The signal which displayed "Restricting" to allow the second train to "close-up" at the station _does_ display "Stop" when the direction of traffic of the first train is _against_ the direction of travel of the second train. Such movements are fairly common on this railroad as this particular station is adjacent to a "yard" and an engine servicing facility.

While the railroad operates primarily in one direction and is mostly signaled for "current of traffic" operation, the area near this station is in a territory which is "signaled for traffic in both directions". There is no CTC and the Dispatcher does not have control of any of the signals. The entire system is configured for "automatic" operation, and requires only a couple of crew-accessible "direction of traffic override" buttons. This system provides full signaling for all mainline movements except "against-current-of-traffic" moves in "current-of-traffic" territory.

I _do not_ have a specific answer to the prototype question you pose. It is beyond my "student of signaling" and "informal apprentice signalman's" knowledge. Not knowing the territory in the example, whether single or double track, or the applicable rules, I would think that a generic rule relating to "delayed within a block" would apply, regardless of last signal indication received before the station stop. Depending on applicable operating rules, that may require operating at a Restricted speed until receiving a signal with a less restrictive indication.

I know that some railroads implemented "Station Protection Signals" just ahead of the typical loco station-stopping point, to provide some additional protections for those trains departing a station for preceeding and opposing trains. If I understand correctly, these were often effectively a "repeater" of the next signal in advance.

Some railroads had rules which prescribed the safe operating requirements when leaving a station which did _not_ have a signal protection signal. I would imagine that traffic density might affect the operating rules and signaling implementations used by different railroads in these cases.

Above all, remember that "each rule in the rule book was written in blood", and "when in doubt, the safe course of action must be followed".

Regards,
Bob M.

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Sunday, August 23, 2020 1:48 AM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

One last prototype bit:

On Aug 22, 2020, at 7:14 PM, Bob M. <jawhugrps@...> wrote:

I understand that it is fairly common to find passenger stations, especially in "commuter territory" where passenger train density is high, signaled in such a way where one train makes a station stop at the platform, and a following train gets a "Restricting" indication to allow it to proceed into the occupied block. This type of signaling helps optimize operations at the station, where optimizing track usage can significantly help optimize train capacity of the line.
Assume no signal exiting the station platform (common in North America, less common elsewhere).

Train A1 has passed a CLEAR and stopped at the station. Train B2 has passed a RESTRICTING and pulling in behind.

A1 leaves. What rule(s) control to the next signal?

(Hint: The Feb 1996 MARC/Amtrak accident was due to the engineer getting this wrong https://www.ntsb.gov/investigations/AccidentReports/Reports/RAR9702.pdf )

I don’t know of a railroad where CLEAR is the answer; I’d love to know about one. Many say “proceed prepared to stop at the next signal” via their “delayed in block rule” because by the time the delayed train is at the next signal, that signal may have dropped. But some, typically West Coast, including the 1950’s SP, used RESTRICTING here; that motivated them to put a signal quite soon after the station to avoid traveling long distances at slow speeds.

Next B2 pulls up, does the station stop, and leaves. What rule(s) control to the next signal?

The only safe answer is RESTRICTING. The engineer must take responsibility to visually keep the train safe, as the signal system cannot help here. Note that A1 might be stopped short of the next signal; "proceed prepared to stop at the next signal” is thus _not_ safe for B2. The need to be governed by RESTRICTING has multiple problems: It’s slow; it makes the delayed-in-block rule complicated on railroads that allow APPROACH (“if you’re delayed in block, what you do depends on………”); it has led to accidents due to engineer error.


This could be quite a cool thing to model, particularly if your engineers are really into the details of the rules. And if it goes wrong, it’s unlikely people will get killed….

Bob

Bob Jacobsen
@BobJacobsen


Bob M.
 

Bob J.,

The application of "restricting" (or other permissive aspect) that I have described can only be used for _following_ trains. Such "direction of travel" requirements must be proven in VITAL (field) logic. The application was described to me by a Class-I railroad signaling engineer as part of a discussion of the three basic applications of "call-on".

I agree that the AAR "typical circuits" information is a good source of ideas, and I had passed that same link to Greg a few days ago.

But be aware that the "Typical" circuits were just that - "typical" They generally showed _one_ way which could achieve certain features. As operating requirements varied from the assumptions made in the AAR typical circuits, individual railroads chose their own set of features and exactly how they were implemented in relay logic. I understand that "the chief engineer's preferences" had a strong effect on the actual practices used on a given railroad!

Regards,
Bob M.


Bob Jacobsen
 

No argument with that.

When trying to figure out how to add a new basic capability to JMRI, there’s a balance between flexibility (to handle all the wonderful variation in the world) and simplicity (to get the typical case right easily).

The AAR info is a good place to see the details of what “typical” really means by stepping through how it works. Then it’s a judgement call how to also make it flexible.

Starting with a very specific case, on the other hand, can end up in a corner where it’s hard to make the typical cases work as they should, even though they’re much more common.

Hence my long note about this new capability should make RESTRICTING from held/STOP. That makes the typical case straightforward. Going the other way, making STOP from RESTRICTING, would make every STOP calculation, and most RESTRICTING calculations, more complicated.

Bob

On Aug 23, 2020, at 5:27 AM, Bob M. <jawhugrps@...> wrote:

I agree that the AAR "typical circuits" information is a good source of ideas, and I had passed that same link to Greg a few days ago.

But be aware that the "Typical" circuits were just that - "typical" They generally showed _one_ way which could achieve certain features. As operating requirements varied from the assumptions made in the AAR typical circuits, individual railroads chose their own set of features and exactly how they were implemented in relay logic. I understand that "the chief engineer's preferences" had a strong effect on the actual practices used on a given railroad!

Bob Jacobsen
@BobJacobsen


Ken Cameron
 

Everything I've been hearing from prototype people and sources support what
Bob says:
" Hence my long note about this new capability should make RESTRICTING from
held/STOP. That makes the typical case straightforward. Going the other
way, making STOP from RESTRICTING, would make every STOP calculation, and
most RESTRICTING calculations, more complicated."

With one exception, it only makes RESTRICTING from a STOP, but not a held. A
held is from the traffic direction not being set in the direction for that
signal. All prototype applications I'm finding says the signal has to be
STOP (not held) and it was stop because the route was selected but the
destination was occupied. The traffic direction must have been set for this
movement, there by releasing the held. Some information was key about this
being something that would lock the route as part of setting the RESTRICTING
instead of the STOP that it would have been showing.

Removing the 'from held' from Bob's statement then matches everything I've
been finding.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Bob Jacobsen
 

I don’t understand the following, sorry. It seems to me you’re adding an unfortunate limitation based on some examples that don’t happen to require something. But perhaps I misunderstand.

There are prototypical examples where a RESTRICTING is commanded by a control system even when a higher speed aspect was valid, but not desired, and therefore held off.

Imagine a section of working track with OS sections at each end. It’s currently empty, with a train at one end’s OS, ready to enter. Another train is due shortly at the other end. You want to let them both onto this track to work together. How does the signal system do it?

….

Direction of traffic may or may not be involved in the solution, depending on the system, but it doesn’t change the problem: _Both_ need to be shown RESTRICTING.

If the signals were allowed to operate on just their vital logic (i.e. weren’t Held), you’d get one showing APPROACH and the other STOP. It would _not_ be safe to convert that STOP to RESTRICTING. You’re stuck.

You need to set both levers to Held the signals, then allow them to be RESTRICTING. Therefore the JMRI code should have that capability. And allowing RESTRICTING from STOP with or without Held gives you that for free without harming cases that don’t need it.

Bob


On Aug 23, 2020, at 11:03 AM, Ken Cameron <@KenC57> wrote:

Everything I've been hearing from prototype people and sources support what
Bob says:
" Hence my long note about this new capability should make RESTRICTING from
held/STOP. That makes the typical case straightforward. Going the other
way, making STOP from RESTRICTING, would make every STOP calculation, and
most RESTRICTING calculations, more complicated."

With one exception, it only makes RESTRICTING from a STOP, but not a held. A
held is from the traffic direction not being set in the direction for that
signal. All prototype applications I'm finding says the signal has to be
STOP (not held) and it was stop because the route was selected but the
destination was occupied. The traffic direction must have been set for this
movement, there by releasing the held. Some information was key about this
being something that would lock the route as part of setting the RESTRICTING
instead of the STOP that it would have been showing.

Removing the 'from held' from Bob's statement then matches everything I've
been finding.

Bob Jacobsen
@BobJacobsen


wombat_rrnut
 

Since we've opened up the discussion to doing things right, I'd like to possibly change my mind on my proposed "call-on" fix.....
I propose the following in case it fits in better than my "kludge":

All of the following proposals would NOT be saved/restored to/from
any .xml file (ergo no changes there), but only be during "runtime":

#1
The original proposal to "or" with "held" was a quick and dirty solution.
It was a much easier implementation as regards changes to SML
than the following, which is what I really needed.....

What I really need is a enable/disable (of some form) of the
"restricting" indication. I would "enable" restricting at the signal
mast when call-on was requested, and when it wasn't needed anymore
I would "disable" it.

Of course, since "restricting" is just one of the possible aspects that
the user defines and is "free form", I would have to have the user
in my configuration screen define the exact text they used in the
"aspect" .xml files, with the default being "restricting", since most
railroads used that term.

This means technically that all aspects could be enabled/disabled
from outside of SML, since "restricting" is just one more - assuming
I'm correct.

So: Signal.setAspectEnabled("aspect name", true/false) or some such.

OR:

#2
In <specificappearances>, there is something called
<permissive>...</permissive>, which is another possibility
to enable/disable.

I wouldn't know how that impacts the design. Does its inclusion
in <specificappearances> make it ALWAYS a required definition?
Therefore I could enable/disable with a call something like:
Signal.enablePermissive(true/false).....


If someone could comment on these possibilities, I'd appreciate it.
However, I can always fall back on my original suggestion.

Sincerely
Greg

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Sunday, August 23, 2020 12:20 PM
To: jmri@jmri-developers.groups.io Notification <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

No argument with that.

When trying to figure out how to add a new basic capability to JMRI, there’s a balance between flexibility (to handle all the wonderful variation in the world) and simplicity (to get the typical case right easily).

The AAR info is a good place to see the details of what “typical” really means by stepping through how it works. Then it’s a judgement call how to also make it flexible.

Starting with a very specific case, on the other hand, can end up in a corner where it’s hard to make the typical cases work as they should, even though they’re much more common.

Hence my long note about this new capability should make RESTRICTING from held/STOP. That makes the typical case straightforward. Going the other way, making STOP from RESTRICTING, would make every STOP calculation, and most RESTRICTING calculations, more complicated.

Bob

On Aug 23, 2020, at 5:27 AM, Bob M. <jawhugrps@...> wrote:

I agree that the AAR "typical circuits" information is a good source of ideas, and I had passed that same link to Greg a few days ago.

But be aware that the "Typical" circuits were just that - "typical" They generally showed _one_ way which could achieve certain features. As operating requirements varied from the assumptions made in the AAR typical circuits, individual railroads chose their own set of features and exactly how they were implemented in relay logic. I understand that "the chief engineer's preferences" had a strong effect on the actual practices used on a given railroad!

Bob Jacobsen
@BobJacobsen


Ken Cameron
 

Bob,

I'd love to know what prototype ever did that. I'm not finding anything like
that within the signal systems I've been studying. Your case, if I read it
right, says you had two opposing trains that you were trying to allow to
meet face to face within a block. Anything I've been finding would say the
vital logic or the CTC logic would not allow that. Instead the dispatcher
would have to verbal the two trains into the block past the two STOP
signals. The CTC wouldn't allow the traffic direction opposing each other.
Or did I misconstrue what you said?

My gatherings from others seem to point to a number of special cases that
the signal system logic (field and panel) would not allow, so the
dispatchers used other means to clear trains past a STOP or similar
operation. The idea I guess was to not take the chance that the logic could
be used wrong by mistake. Only by going totally out of the normal method
could those special cases be allowed. Some of that is seen by the clearance
forms that had options for passing a signal or the number of lines in a TW
it takes for a rescue loco to go out and hook up to a stuck train. That last
one came to mind as I was engineer on a train (7.25 gauge) and had to go out
and drag a dead steam engine back to the terminal. I had never used a couple
of those lines (NORAC Form D) before. These are very rare cases so there
isn't an easy way to do it by simply flipping a switch.

The extra hardware and design work for features like that are things the
prototype only did when there were large compelling reasons that worked on
the cost-risk-benefits of the change. Only if a case was going to be
happening many, many times and they figured the cost savings of time lost vs
the risks would benefit the company.

I think we all know that many model railroaders seem to get hung up on some
pretty rare cases that were by far the exception to the norm.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Bob Jacobsen
 

On Aug 23, 2020, at 6:27 PM, Ken Cameron <kcameron@...> wrote:

I'd love to know what prototype ever did that. I'm not finding anything like
that within the signal systems I've been studying. Your case, if I read it
right, says you had two opposing trains that you were trying to allow to
meet face to face within a block.

This is actually common on the 1950’s SP.  One particular example is Black Butte, which had signals at each entrance that could show a RESTRICTING (in one case, two different kinds) via lunar signals.  Here’s one entrance:

SP Railroad passenger train 327 at Black Butte, CA

The main is on the right.  The mast to the left has two side lunars under the top head. Note the A on the masts. The signal in the distance (behind and left of the car) had a similar arrangement as did the signals straight ahead in the distance.  

This was pre-radio:  There was a lot of walking involved in talking a train past a signal, particularly since the SP required that the conductor in the caboose also be informed.  

Black Butte was effectively a small yard, wye and engine facility at this time. The lunars allowed trains to work this area under visual half-the-distance rules.

SP Railroad passenger train 327 at Black Butte, CA

(Hopefully you can just see that the left lunar is lit in the photo; note the bottom lamp is dark)


 Anything I've been finding would say the
vital logic or the CTC logic would not allow that. Instead the dispatcher
would have to verbal the two trains into the block past the two STOP
signals. The CTC wouldn't allow the traffic direction opposing each other.


And there’s my point: “anything (you) are readiing”.  You want to add a limitation that (a) you don’t need for the cases you’ve been reading and (b) would make it harder to do some other things.

Not every CTC system (real USS CTC or the similar other forms) treats these things the same way. Railroads had different requirements.

Bob


Bob Jacobsen
rgj1927@...





Bob Jacobsen
 

There’s a concrete proposal for the attribute I’m suggesting here:

https://github.com/JMRI/JMRI/pull/8964/files

That shows the get/set methods in the Signal interface, and some tests to demonstrate the state machine.

It doesn’t include an implementation. That’s the next step if this turns out to work for Gregory’s needs.

Bob

On Aug 23, 2020, at 3:19 PM, wombat_rrnut <gbedlek001@...> wrote:

Since we've opened up the discussion to doing things right, I'd like to possibly change my mind on my proposed "call-on" fix.....
I propose the following in case it fits in better than my "kludge":

All of the following proposals would NOT be saved/restored to/from
any .xml file (ergo no changes there), but only be during "runtime":

#1
The original proposal to "or" with "held" was a quick and dirty solution.
It was a much easier implementation as regards changes to SML
than the following, which is what I really needed.....

What I really need is a enable/disable (of some form) of the
"restricting" indication. I would "enable" restricting at the signal
mast when call-on was requested, and when it wasn't needed anymore
I would "disable" it.

Of course, since "restricting" is just one of the possible aspects that
the user defines and is "free form", I would have to have the user
in my configuration screen define the exact text they used in the
"aspect" .xml files, with the default being "restricting", since most
railroads used that term.

This means technically that all aspects could be enabled/disabled
from outside of SML, since "restricting" is just one more - assuming
I'm correct.

So: Signal.setAspectEnabled("aspect name", true/false) or some such.

OR:

#2
In <specificappearances>, there is something called
<permissive>...</permissive>, which is another possibility
to enable/disable.

I wouldn't know how that impacts the design. Does its inclusion
in <specificappearances> make it ALWAYS a required definition?
Therefore I could enable/disable with a call something like:
Signal.enablePermissive(true/false).....


If someone could comment on these possibilities, I'd appreciate it.
However, I can always fall back on my original suggestion.

Sincerely
Greg



-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Sunday, August 23, 2020 12:20 PM
To: jmri@jmri-developers.groups.io Notification <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

No argument with that.

When trying to figure out how to add a new basic capability to JMRI, there’s a balance between flexibility (to handle all the wonderful variation in the world) and simplicity (to get the typical case right easily).

The AAR info is a good place to see the details of what “typical” really means by stepping through how it works. Then it’s a judgement call how to also make it flexible.

Starting with a very specific case, on the other hand, can end up in a corner where it’s hard to make the typical cases work as they should, even though they’re much more common.

Hence my long note about this new capability should make RESTRICTING from held/STOP. That makes the typical case straightforward. Going the other way, making STOP from RESTRICTING, would make every STOP calculation, and most RESTRICTING calculations, more complicated.

Bob

On Aug 23, 2020, at 5:27 AM, Bob M. <jawhugrps@...> wrote:

I agree that the AAR "typical circuits" information is a good source of ideas, and I had passed that same link to Greg a few days ago.

But be aware that the "Typical" circuits were just that - "typical" They generally showed _one_ way which could achieve certain features. As operating requirements varied from the assumptions made in the AAR typical circuits, individual railroads chose their own set of features and exactly how they were implemented in relay logic. I understand that "the chief engineer's preferences" had a strong effect on the actual practices used on a given railroad!

Bob Jacobsen
@BobJacobsen










Bob Jacobsen
@BobJacobsen


Ken Cameron
 

Ok, the old 'there's a prototype for everything' rule does apply. But I do
question it not requiring the traffic direction to be set for the move,
which would have released the held. I could see in the panel logic that it
would negate the check for opposing traffic directions when the call-on is
used. For the first train, it wouldn't need that, the other end hasn't been
set yet. For the second train, it would not check the opposing traffic
direction when using the call-on.

I'm just wanting to make sure existing panels have the option for the
restricting on held or not exists. As I understand it, current signals show
STOP on held that that's are far as it goes. If the changes allow for both
configurations: one where to get RESTRICTING the held must be released and
the other configuration where the RESTRICTING can be displayed while still
being in HELD, great, it would allow for both types of use. I can see where
some of this might be options in the mast xml that combines with the other
logic being added in the signal code. Just some way to get the one behavior
or the other to fit all the different types of railroads.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


wombat_rrnut
 

Bob:

(I accidentally sent this the wrong way the first time, you may get a 2nd copy of this)

I looked at "https://github.com/JMRI/JMRI/pull/8964/files".
You mention "Get whether the signal is in the permissive subset of the held state.
(This can only be true if {@link #getHeld()} is true)"

I'm a little confused by that "subset" meaning, but an explanation doesn't matter now,
unless you want to explain it further to me.
I'll state the obvious (as all formal specs. should):

Assume the signal mast has a restricting aspect configured and available to it.
Assume the "next" block (not O.S. section) has Permissive "checked".
The next block is occupied. The O.S. section isn't.
If I call "setHeld(false); setHeldPermissive(true);" I don't want restricting being displayed. Any other aspect is fine (of course in this case, it's red due to occupancy).
If I call "setHeld(false); setHeldPermissive(false);" I DO want restricting displayed.
If I call "setHeld(true);", then the signal is "obviously" red, and setHeldPermissive doesn't matter until setHeld(false) is called.

And of course, "setHeldPermissive(false)" is how it is initialized at JMRI startup I would assume,
so that nothing existing is affected.

And (of course) changing "setHeldPermissive's" value causes a re-evaluation of the present signal aspect.


One more detail:
Your test procedures don't test this out.
Probably because you don't have a "layout" available to test with at test time.
My CTC "testing stuff" does have a layout availble to it which could test this feature.

Should that be in my test procedure, or should I move that test to your file eventually?

Sincerely
Greg

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Monday, August 24, 2020 1:06 AM
To: jmri@jmri-developers.groups.io Notification <jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

There’s a concrete proposal for the attribute I’m suggesting here:

https://github.com/JMRI/JMRI/pull/8964/files

That shows the get/set methods in the Signal interface, and some tests to demonstrate the state machine.

It doesn’t include an implementation. That’s the next step if this turns out to work for Gregory’s needs.

Bob

On Aug 23, 2020, at 3:19 PM, wombat_rrnut <gbedlek001@...> wrote:

Since we've opened up the discussion to doing things right, I'd like to possibly change my mind on my proposed "call-on" fix.....
I propose the following in case it fits in better than my "kludge":

All of the following proposals would NOT be saved/restored to/from any
.xml file (ergo no changes there), but only be during "runtime":

#1
The original proposal to "or" with "held" was a quick and dirty solution.
It was a much easier implementation as regards changes to SML than the
following, which is what I really needed.....

What I really need is a enable/disable (of some form) of the
"restricting" indication. I would "enable" restricting at the signal
mast when call-on was requested, and when it wasn't needed anymore I
would "disable" it.

Of course, since "restricting" is just one of the possible aspects
that the user defines and is "free form", I would have to have the
user in my configuration screen define the exact text they used in the
"aspect" .xml files, with the default being "restricting", since most
railroads used that term.

This means technically that all aspects could be enabled/disabled from
outside of SML, since "restricting" is just one more - assuming I'm
correct.

So: Signal.setAspectEnabled("aspect name", true/false) or some such.

OR:

#2
In <specificappearances>, there is something called
<permissive>...</permissive>, which is another possibility to
enable/disable.

I wouldn't know how that impacts the design. Does its inclusion in
<specificappearances> make it ALWAYS a required definition?
Therefore I could enable/disable with a call something like:
Signal.enablePermissive(true/false).....


If someone could comment on these possibilities, I'd appreciate it.
However, I can always fall back on my original suggestion.

Sincerely
Greg



-----Original Message-----
From: jmri@jmri-developers.groups.io
[mailto:jmri@jmri-developers.groups.io] On Behalf Of Bob Jacobsen
Sent: Sunday, August 23, 2020 12:20 PM
To: jmri@jmri-developers.groups.io Notification
<jmri@jmri-developers.groups.io>
Subject: Re: [jmri-developers] Proposed Signal Mast Logic Change

No argument with that.

When trying to figure out how to add a new basic capability to JMRI, there’s a balance between flexibility (to handle all the wonderful variation in the world) and simplicity (to get the typical case right easily).

The AAR info is a good place to see the details of what “typical” really means by stepping through how it works. Then it’s a judgement call how to also make it flexible.

Starting with a very specific case, on the other hand, can end up in a corner where it’s hard to make the typical cases work as they should, even though they’re much more common.

Hence my long note about this new capability should make RESTRICTING from held/STOP. That makes the typical case straightforward. Going the other way, making STOP from RESTRICTING, would make every STOP calculation, and most RESTRICTING calculations, more complicated.

Bob

On Aug 23, 2020, at 5:27 AM, Bob M. <jawhugrps@...> wrote:

I agree that the AAR "typical circuits" information is a good source of ideas, and I had passed that same link to Greg a few days ago.

But be aware that the "Typical" circuits were just that - "typical" They generally showed _one_ way which could achieve certain features. As operating requirements varied from the assumptions made in the AAR typical circuits, individual railroads chose their own set of features and exactly how they were implemented in relay logic. I understand that "the chief engineer's preferences" had a strong effect on the actual practices used on a given railroad!

Bob Jacobsen
@BobJacobsen










Bob Jacobsen
@BobJacobsen


Bob Jacobsen
 

Here’s the basic idea: Held means the system’s Stop, usually absolute. Held+permissive allows to proceed with limitation, i.e. 290 restricting or another similar rule (291 stop and proceed etc).

The name comes from the AAR rules: "Permissive signal: A signal whose "stop" indication means "stop and proceed at restricted speed." Usually identified by a number plate, some permissive signals also have a plate with the letter "P," indicating that a train may pass the signal indicating stop without stopping but at restricted speed.” Permissive is the general form of Rule 290 and 291.

Perhaps the “permissive” name is a poor choice for JMRI and we need to find another?

The proposal is actually the other way around from the cases you list:

If you call setHeld(false), setHeldPermissive(true), it will have exactly the same effect as calling setHeld(true), setHeldPermissive(true): You can’t be in permissive without being held, you asked to be in permissive, so we’ve set held for you.

(An alternative, which would be fine with me, would be to have setHeld(false), setHeldPermissive(true) throw an error and stop everything. Some people don’t like their train control systems to do that, in the false belief that allowing a messed up control system to run on is better than stopping it. I’m fine with the exception, although people tend to bypass them and I’m not fine with that)

Moving to the next example: setHeld(false); setHeldPermissive(false) is normal operation. That’s not restricting, that’s a normal upheld signal responding to the vital logic.

Finally, if you’ve setHeld(true), that’s _exactly_ the time that permissive controls whether stop or restricting is shown.

These are the cases coded in the test file in the PR.

The way you describe is going to require _extensive_ recoding of lots of Logix, script and jmri.jmrit.ussctc -driven existing layouts. Permissive starts up false, and thousands of existing layout controls wouldn’t know to change it. Therefore
If I call "setHeld(false); setHeldPermissive(false);" I DO want restricting displayed.
Is effectively saying that every signal starts up in Restricting and never goes faster that than unless the code controlling it is changed.

That seems like too much of a migration.

Bob

On Aug 24, 2020, at 5:12 PM, wombat_rrnut <gbedlek001@...> wrote:

Bob:

(I accidentally sent this the wrong way the first time, you may get a 2nd copy of this)

I looked at "https://github.com/JMRI/JMRI/pull/8964/files".
You mention "Get whether the signal is in the permissive subset of the held state.
(This can only be true if {@link #getHeld()} is true)"

I'm a little confused by that "subset" meaning, but an explanation doesn't matter now,
unless you want to explain it further to me.
I'll state the obvious (as all formal specs. should):

Assume the signal mast has a restricting aspect configured and available to it.
Assume the "next" block (not O.S. section) has Permissive "checked".
The next block is occupied. The O.S. section isn't.
If I call "setHeld(false); setHeldPermissive(true);" I don't want restricting being displayed. Any other aspect is fine (of course in this case, it's red due to occupancy).
If I call "setHeld(false); setHeldPermissive(false);" I DO want restricting displayed.
If I call "setHeld(true);", then the signal is "obviously" red, and setHeldPermissive doesn't matter until setHeld(false) is called.

And of course, "setHeldPermissive(false)" is how it is initialized at JMRI startup I would assume,
so that nothing existing is affected.

And (of course) changing "setHeldPermissive's" value causes a re-evaluation of the present signal aspect.


One more detail:
Your test procedures don't test this out.
Probably because you don't have a "layout" available to test with at test time.
My CTC "testing stuff" does have a layout availble to it which could test this feature.

Should that be in my test procedure, or should I move that test to your file eventually?

Sincerely
Greg

Bob Jacobsen
@BobJacobsen


Ken Cameron
 

The biggest problem with this discussion is it shows that on some railroads
the special case of restricting AKA permissive stop was an option only if
held was released while other railroads seem to do the opposite and allow
the special case only when held is still asserted.

We have two opposing cases that currently require special handling outside
the normal logic (SSL or MSL). Trying to add this in a way that doesn't
break or require changes to existing functional solutions will not be a
quick thing. It will require some real careful thought of how to add the
extra parts where the central logic (SSL or MSL) could use it instead of the
special handling, usually Logix or script based, without interfering with
that pre-existing solutions.

It would seem as a generalization that many east coast installations
required the held be released to get anything other than stop as part of the
call-on or return-to-train option. While some west coast installations
allowed the call-on or return-to-train only if the held is still set. Quite
a conflicting set of issues.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org