RM/LD seeing ahead/behind.

[PJ_model_trains]

As for the turnouts, seems you have a bad case of amnesia! :)  Again, a red signal does not mean a block is clear. When a train turns out there is no way to know the block ahead is clear or not.

 

Seems you are not following this hosh, Red Block Clear where did that come from???  I appreciate sometimes explanations are hard to follow, the person writing always know what they mean, getting the message over without images isn't always easy, especially when talking, S this and P that T the other etc.  I will try explain another way.

 

_Clear?_[s4-Red]________<Train2______[s3-Red]__ (inner track)

                                                  symbol shows branch 

_Clear?_[s2-Green]________<Train1____[s1-Red]__ (outer track)

 

The Block Train2 is in (between S3-S4) is occupied but the signal ahead S4 is Red stopping the train continuing.

 

The Block Train1 is in (between S1-S2) is occupied but the signal ahead is Green/Clear allowing Train1 to continue into next Clear Block.

 

The Next Block Clear? could be straight ahead or Branch, that is defined by the points. As the points are to turn-off we know which Block is clear. Point define direction, signal confirms whether Block moving into is Clear or not.

 

When Train1 passed S1 it changed signal at S3 Red, it then changed points for the turn-out to allow Train1 to branch onto inner track. The Block on the inner track is Clear, the signal at S2 confirms this, the signal at S4 protects it.

 

Actions therefore were, Stop oncoming traffic on line crossing to, set conditions (change points), once safe to move into Clear Block change S2 Green.

 

[Slornie]

 

The Next Block Clear? could be straight ahead or Branch, that is defined by the points. As the points are to turn-off we know which Block is clear. Point define direction, signal confirms whether Block moving into is Clear or not.

When Train1 passed S1 it changed signal at S3 Red, it then changed points for the turn-out to allow Train1 to branch onto inner track. The Block on the inner track is Clear, the signal at S2 confirms this, the signal at S4 protects it.

Actions therefore were, Stop oncoming traffic on line crossing to, set conditions (change points), once safe to move into Clear Block change S2 Green.

 

So presumably then there also needs to be some way to check the intended destination block is clear before the points are allowed to be set that way?

 

For instance if in your example Train2 had already passed S4 and was in that leftmost block when Train1 reached S1, you wouldn't want the detection at S1 to change the points to let Train1 transit from outer to inner track because the destination block is potentially already occupied - Train2 could in fact still be running across the points at that very moment!

[PJ_model_trains]

@HRMS @Slornie

 

Train1 triggered signal at S4 to Red when it was at S1, at which time Block S4 West was Clear.

 

Train2 was in the Block S3-S4 so would approach the Red signal S4 and stop before it. 

 

If Train2 had passed S4 it would declare the Block S4 West occupied by the Red signal protecting it so wouldn't allow Train 1 to continue therefore wouldn't change the points.

 

You have raised a good point, it is clear that RM with LD will have to remember some things but, also clear of the need that RM cannot change a Red signal a train/loco has passed making a next Block occupied, in this case RM trying to Set S4 Red and it is Red... so do nothing with this signal. IF Red - THEN Red - ELSE change as commanded.

 

I think there is another issue here, not just the protected Blocks but not allowing points to change into a protected Block.

 

[hosh]

If Train2 had passed S4 it would declare the Block S4 West occupied by the Red signal protecting it so wouldn't allow Train 1 to continue therefore wouldn't change the points.

 

This makes no sense. How does any of this give Train 1 any clue about anything?

 

There are 2 proper solutions for this problem -

 

• Block occupancy knowledge
• Signalling that can see backwards along any route, not just the mainline.

 

There is another bodgey method - only allow train1 to proceed if the signal in the block ahead is non red. But it looks like RM cannot be used to command a loco at a sensor other than the one it's at so even this doesn't work.

[hosh]

I want to hear from someone with RM Pro, signals and what's on pages 82-84 of the pdf.

 

It would seem that there would be sensor commands used to effect other sensors back down the line. If so, then all that's needed is to be able to do this for various point settings and then the signalling can be controlled back down any line, not just the mainline.

 

So a sensor is triggered and the signalling is R(the signal at this sensor), R, Y, YY, G back down the line. This means that all blocks back from the front one are clear.

 

This actually then becomes the same as block detection.

 

But there is still a problem - what about when there is a train on the inner line that is between the blocks on either side of the points? It is not in the ahead block yet and so there is no signalling information available for that block yet.

 

Looks like block detection will be required.

[Gregd99]

@hosh

It is anything but "bog  simple". 😢

 

The software needs to understand the topology of the network.... ie which bits of track are connected to which other bits. Note that this changes in time as turnouts/points are operated. Block A was connected to Block B.... but now is is Block C. Given the knowledge of the dynamic topology of the network routing and occupancy schemes can be developed. Signals can indicate the occupancy; Red=do not enter, Amber=slow down, next block is occupied. Then you need to think about block size... what if a block length is less than the length of a train?

 

This is really interesting stuff but it does get a bit complex. The problems are not new and there is interesting reading available about railway signalling systems and the underlying issues that need to be managed.

 

Do we know what RM is considereing? it might be as simple as "play an announcement" when detector X is active.

[hosh]

@hosh

The software needs to understand the topology of the network.... ie which bits of track are connected to which other bits.

 

That's 100% correct but the problem is, from what we "know" about now, RM wont know this at all, thus all the confusing conversations that ultimately lead nowhere! :)

 

I'm betting that when RM is released that a lot, if not all, of the stuff that we "know" about now will be gone. I think they realised how much it wasn't going to be able to do and have gone back to the drawing board.

 

Programming instructions into every sensor for every train is an absurd approach imo. It creates no relative positions between sections and will be a nightmare to change individual trains to different scripts.