American safety systems modeling

[rman]

Cross-posted from Elvas Tower:

Add a whole new layer of depth to your simulation by simulating train safety and cab signaling systems. Find my work on GitHub. You'll need to run the May 15, 2020 or later testing release of Open Rails.

The following scripts have been released:

• Santa Fe Automatic Train Stop (Surfliner, Cajon Pass, etc.)
• Pennsylvania Railroad Cab Signaling System (PRR Eastern Region)

Video demo:

[Vince]

Incorrect cab signal aspects.

On the PRR-EAst-v2: Your cab signal aspects are incorrect!
You are displaying a Rule 292 STOP cab signal where is should be Rule 281 Proceed as displayed on the gantry ahead.

The cab signal is supposed to show the NEXT signal ahead of the train . . . NOT the signal just passed.
TIME.

regards,

[dcarleton]

Vince is correct. Displaying the aspect of the signal just passed doesn't convey much meaningful information. Real PRR cab signals give the indication of the next signal ahead. Also, not every restrictive aspect causes a penalty application, and not every penalty application results in the train actually stopping.

Think of it this way - The cab signals are the engineer's eyes during a snowstorm. Cab signals are not, and were never intended to be, the engineer's memory.

David P. Carleton
D. Carleton Rail Books

[rman]

Appreciate the criticism, folks. I don't want to question your expertise, most especially not Vince's, but... every source I've seen suggests the cab signals do indeed enforce the current aspect, not the "next" one as per MSTS style. For example, this TO thread, and this AU thread. Even in the Pennsy's own "Progress on the Rails" video, you can see that the engineer's cab signal does not drop to Approach until he actually passes the signal head.

Also, the first aspect you see in the video is supposed to be "Restricting," not "Stop" (which the PRR didn't have a pulse code for). The idea is that you upgrade to "Clear" when you pass the first Clear signal.

[dcarleton]

(which the PRR didn't have a pulse code for)

Sure about that? The pulse code for stop was zero pulse per second - the ultimate fail safe device!

[rman]

Yep. The system could only show four possible aspects:

• Clear
• Approach Medium
• Approach
• Restricting

And "Restricting" was the no-code state, sent about 1500 ft before any Stop signals - as modeled by my script. There was no lower "Stop" aspect.

[dcarleton]

Oh, okay. Please understand that I have worked on signal systems for a living, on the engineering side of the business, but that was almost 40 years ago. I now work in civil engineering exclusively, and yes, we do have some railroad work.

That having been said, the information found on Wikipedia will not be consistent with what we learned in school because the methodology now is different than it was then. ("Methodology" meaning we were trying to enforce movement authority but usually not speed limits.)

[rman]

I see. Again, I do appreciate your expertise, and I'm not trying to "defend" my interpretation of the PRR's system - like you, I'd like it modeled as accurately as possible, and if someone could point me toward some definitive sources, I would be happy to revise my code.

What I'm confused about is your blanket statement, "Cab signals are not, and were never intended to be, the engineer's memory." It's my understanding that this is more or less how Amtrak's cab signals on the Northeast Corridor work, which themselves are descended from those of the PRR: Your cab signal reflects the state of the block you're currently in. You can see this behavior if you drive the Northeast Corridor in either of Dovetail's train simulators.

[Vince]

Yep. The system could only show four possible aspects:

Nice quote but the cab signals in the PRR MP54 displayed FIVE aspects, the bottom was the 'no-code' display of stop.

Ever ridden in the cab of a GG1, an MP54? I have . . .in both.
My Grandfather was PRR managment and he hooked me up with several cab rides and in a later generation I had rides in the original MU Metroliners and somewhat more recently ( 1980) my daughter and I rodein the cab an AEM7 Washington to NY Penn. 1980 (275).jpg

In all cases my in cab signal observations were as I stated; "the cab signal displays the oncoming signal NOT the one just passed".

Think about this for a minute, or maybe you'll need a bit longer longer: Why would you ever want a display of what you just passed.

regards,

ps dont rely on wickipedia too much . . . anyone can edit those entries . . . even you!

[dcarleton]

I meant that when I was working on the NECIP (reviewing shop drawings) we were repeatedly reminded that the cab signals were there so that the signal indications would always be visible to the engineer even if a blizzard or a blinding rain obscured the signal heads.

Also remember that the signals protecting the block that your train is currently in should always indicate "stop".

[rman]

Nice quote but the cab signals in the PRR MP54 displayed FIVE aspects, the bottom was the 'no-code' display of stop.

Indeed, there are five lights, but per this blogger and this historian, they were only capable of displaying four aspects. Three pulse codes, plus "Restricting," the lack of a code.

Ever ridden in the cab of a GG1, an MP54? I have . . .in both.

No, I have not. And I concede I have no data or experience regarding the PRR's equipment. After all, that's why I asked...

However, I have ridden the new SEPTA trains with railfan windows. Here is one such video. Notice the engineer doesn't get the downgrade (turn up the volume and you can hear the warning tone) or commence braking until he actually passes the signal.

In all cases my in cab signal observations were as I stated; "the cab signal displays the oncoming signal NOT the one just passed".

...And I am very interested to hear that, and I am not discounting your experience. But, I have two rival train simulators and people who are very familiar with contemporary Amtrak operations telling me that the MSTS way is wrong, and that the cab signals should reflect the state of the block you just entered. So who's right? Perhaps both of you are. If we gather more information, I am sure we could reconcile these conflicting interpretations.

Think about this for a minute, or maybe you'll need a bit longer longer: Why would you ever want a display of what you just passed.

I can think of a few reasons. So that if the engineer misses the signal head due to fog or snow, or forgets the current one in force, he can be informed. So that if traffic conditions improve, he can receive the upgraded aspect immediately (which does happen with my script).

P.S. Kindly refrain from making jabs at my reading comprehension.

Best,

[rman]

Also remember that the signals protecting the block that your train is currently in should always indicate "stop".

Of course. Cab signals don't constitute a license to ignore the lineside ones. Actually, that would be quite impossible, with only 4 pulse codes to represent all 12 possible aspects...

[dcarleton]

We know that. It's just that the cab signal system cannot continue to read the signal that the train just passed, since that signal went to stop as soon as the train passes it!

[rman]

The script records the state of the signal at the exact moment the train passed it. So, even after the signal drops to Stop, the train can still remember the aspect in force.

In reality, I believe, the pulse code signaling system would transmit the code for the incoming block, and as soon as the train enters that region, its electronics would pick up the code. As in that SEPTA video.

[ebnertra000]

I'm no expert, but my understanding of cab signals is that they tell you the state of the next signal, and is primarily a supplement to (sometimes a replacement of) wayside signals. The cab signal telling you the state of the block you're in would mean it would always show either Stop or Restricting, since the block your train is in will by definition always be occupied. If something happens ahead of you and the signal ahead drops to stop, the cab signal will probably do so, as well (not guaranteed - not all systems continuously updated). A rail break might drop the cab signal, as well, depending on how the pulse code is sent (probably through the rails). But wouldn't the primary warning about the state of the block the train is currently in have come while the train was still in the preceding block, and was still facing the signal protecting said block?