RM/LD seeing ahead/behind.

[PJ_model_trains]

It seems what we need is a way to declare a block clear or occupied and a way to check whether or not a block is clear or occupied. Red and green signals do not do this.

 

I think you are thinking on the lines of Block Detection hosh. Forget it, LD does not work the same way.

 

LD replies on sensors as we know and when a tag is read it among other things controls a signal adjacent to it. As on miinline railway, signals control the Blocks and give visual instructions to the train driver what to do. With LD the tag is read at the sensor and the signal changes to R,Y,YY,G or Flashing aspects.

 

Red means Stop as we know, it is the sensor that controls what happens in the Blockk, subject to our pre-programming. It is the signal which is the visual display (as with the train driver) of what conditions the train should travel.

 

So a Block is declared Occupied when a tag (loco or End Carriage) passes over it and it instructs the signal to show Red/Stop.

 

A Block is declared Clear if the signal is Y,YY,G or Flashing aspect, but some of the clear commands carry conditions with them.

 

Y = continue into next Block with Extreme Caution. The Block ahead is declared Clear, but the train driver knows the next signal may be Red/Stop or there may be something on the track. The driver has to be ready to Stop.

 

YY = continue into next Block with Caution. The Block ahead is declared Clear, but the train driver knows the next signal may be Yellow so he knows he has to be ready to slow down further.

 

Flashing aspects carry their own additional 'drive with caution commands' 

 

So a Block is in effect declared occupied as soon as a loco or end carriage passes over the sensor. Your sensor is your Block marker, the second you pass over it you are in the next Block and it is occupied. The Red signal is just a visual guide confirming the conditions of the Block, e.g. declared occupied. 

 

So when you say 'Red and green signals do not do this.' you are correct. It is the tag read over the sensor that when activated controls the Block. It is with our pre-programming of the adjacent signal that we turn it Red to give a visual indication the sensor has declared the Block occupied. 

 

[PJ_model_trains]

PJ, in your simple straight line thread, setting the blocks behind, this is not a problem. You do not need to know about blocks being clear other than the one your train is in. It simply sets the block behind it to red and the block behind that to green.

 

All tracks are divided in to Blocks, every Block is either Occupied, or Clear (some Blocks with conditions)

 

I personally do not need to know about Blocks behind the train but subject to signals used the previous Blocks must have have conditions.

 

Take this simple straight track example. The loco is travelling at 50mph in direction of arrows

 

___[s/G]_______[s/G]_______[s/G]_______[S/R]_Loco>>>_[s/G]___

 

S/R = Sensor controlling adjacent signal to Red/Stop - Block occupied

S/G = Sensor controlling adjacent signal to Green/Clear - Block Clear

 

With 2 aspect signals all Blocks behind the Loco will be Green/Clear. 2 aspect signals are alright leaving siding and stations but not on main line where higher speed trains can be travelling.

 

So with 3 aspect signals on this line we would have

 

___[s/G]_______[s/G]_______[S/Y]_______[S/R]_Loco>>>_[s/G]___

 

S/R = Sensor controlling adjacent signal to Red/Stop - Block occupied

S/G = Sensor controlling adjacent signal to Green/Clear - Block Clear

S/Y = Sensor controlling adjacent signal to Yellow - Block Clear BUT driver proceed with Caution

 

In other words Driver Slow Down in this Block, you may have to Stop, there may be situations ahead you have to adjust to.

 

So with 4 aspect signals on this line we would have

 

___[s/G]_______[S/YY]_______[S/Y]_______[S/R]_Loco>>>_[s/G]___

 

S/R = Sensor controlling adjacent signal to Red/Stop - Block occupied

S/G = Sensor controlling adjacent signal to Green/Clear - Block Clear

S/Y = Sensor controlling adjacent signal to Yellow - Block Clear BUT driver proceed with Caution

S/YY = Sensor controlling adjacent signal to Yellow/Yellow - Block Clear BUT driver proceed with Extra Caution

 

In other words Driver must now be ready to Stop at the next signal, or he may have to stop due to something on the line etc. The driver was warned to slow down at the Y signal, now he has his final warning, he must be ready to Stop.

 

4 aspect signals  are used on the fasterlines where a driver needs advance warning, hence the two Blocks prior to a Red allows him to prepare to Stop at the Red signal or prepare to Stop in emergency.

 

The leading train, say 50mph, does not need to know what Block conditions are behind his train, he is moving forward based on signal/Block conditions. But they do need to change according to signal aspects behind him to warn other locos catching up or branching on to his track behind him.

 

Further back down the line, there is an express train, travelling at say 90mph, this train would soon catch up to the leading train and if not for warned of Block conditions between the two trains they would no doubt crash. This is exactly why additional aspect signal were introduced on mainline railway, the stopping distance for a train at 90mph is a 'long long way'

 

[PJ_model_trains]

But for head on collisions and turnouts, we need to know if the block ahead is clear and you cannot determine that from signals.

 

Head on collisions are more than likely due to Bi-directional traffic and a lot of planning of routes is first needed.

 

As for turn outs, Fishy has mentioned above the suggestion for two new instrucytions...

For point set left

For point set right

 

Take the example again below

 

____________[s8]___________Loco2_[s7] <<< dir of travel (secondary line)

                                                                

____________[s2]___Loco1_________[s1] <<< dir of travel (main line)

 

  = showing branch (best possible using text symbols)

 

Lets say Loco2 is travelling on the inner track but is further back down the line, but he is moving towards Sensor 8 and the branch turn-out

 

Loco1 is also moving towards sensor S2 near the branch shown (but is not quite there yet).

 

Lets say we have programmed the turn out shown above at Sensor S1

For point ### set right

We would also set a command when point ### is set right, to change the signal on the inner line adjacent sensor S8 to Red/Stop

 

____________[S8]_______Loco2_____[s7] <<< dir of travel (secondary line)

                                                                

____________[s2]_Loco1___________[s1] <<< dir of travel (main line)

 

The result is Sensor S1 set the turn-out to Right before the loco/train got anywhere near. At the same time it commanded the signal adjacent S8 to turn Red/Stop. Also at that time it changed the signal adjacent sensor S2 to Yellow or Green. Speed limits will already apply and can be seen by the driver on the section of track he is on. All done in good time when the Loco passed over sensor S1. Block are assigned the condition of the Blocks are shown to the driver/us my the signals we see.

 

Loco2 has stopped in good time, Loco1 is able to branch onto the secondary line. 

 

Subject to our pre-programming a signal turns Red as a loco passes over the sensor protecting the Block it has entered (on the main line) but as the loco passes through the branch and clears the main line then the signals on the main line are then declared Clear. It will all be in our pre-programming. ;o)

 

[PJ_model_trains]

There are 3 ways a signal (block) can be occupied -

 

• There is a train stopped there
• A train has just moved past or resumed, but has yet to be detected by the ahead block setting this block to clear
• A train has been already sent toward the signal (note that this does not necessarily mean the train has been in any way detected in the block yet)

 

So obviously we need none of these conditions to be true for a block to be clear.

 

Without such a way to see and declare blocks, head on collision avoidance and branches will be impossible.

 

Just to clarify on the points made here hosh, not critism, just clarification ;o)

 

Ways Blocks are occupied.

 

1 - there is a loco or carriage/wagon in the Block, between the 2 Block sensors

 

But a Red/Stop signal may also indicate a problem on the line, an accident, debris on the line, flooding etc. The Red/Stop signal is basically confirming it is not safe for the train driver to enter the Block.

 

2 - This I see as slightly different. The second a loco (or end carriage) tag passes over a sensor the block it is heading towards is occupied. Lets stick for this example  to a loco going forward to keep it simple. A loco doing 10mph will have 'passed over' the sensor when it stops, so is in effect it will be in the next Block making it occupied, but it could be half and half so the Block it was leaving, but is still in, remains occupied, so remains protected by a previous Red for that Block.

 

Now when Resume is programmed for the loco to start it does so by changng its signal to Green. But it is a Green signal and the loco is in an occupied Block so, the Green is to get the loco to Resume and MUST follow with a Red signal again a few seconds later. Otherwise the system sees the occupied Block as Clear and problems will occur. A few second delay after a Resume to put the signal back to Red and protect the occupied Block is all that is need.

 

3 - The simplest way I found was, when starting from scratch running our locos/trains I always ensure the following.

 

All occupied Blocks start with a Red signal, all unoccupied Blocks are set to Y,YY,G as per start up Block conditions. . This way once we start our first loco/train running every Block condition is set from the start. A program will no doubt start the loco running so there is not a problem. 

 

So in your example hosh, I am seeing your loco in a Block that the loco has not yet set off from. So I assume it was there at the start and by setting Block conditions at the start that Block is already covered by a Red signal/occupied.

 

So it is true to say when we start our trains from scratch after opening RM, either RM must be set to set signals to cover Blocks, or we do it before we start any locos running or loco program running. ;o)

 

[hosh]

____________[S8]_______Loco2_____[s7] <<< dir of travel (secondary line)

 

____________[s2]_Loco1___________[s1] <<< dir of travel (main line)

The result is Sensor S1 set the turn-out to Right before the loco/train got anywhere near. At the same time it commanded the signal adjacent S8 to turn Red/Stop. Also at that time it changed the signal adjacent sensor S2 to Yellow or Green. Speed limits will already apply and can be seen by the driver on the section of track he is on. All done in good time when the Loco passed over sensor S1. Block are assigned the condition of the Blocks are shown to the driver/us my the signals we see.

Loco2 has stopped in good time, Loco1 is able to branch onto the secondary line.

 

This is all understood PJ, but how does loco 1 know that the block ahead of S8 is clear or occupied? If it is red then that could mean either that a train is stopped there, just took off or that the block is clear but the block ahead is occupied.

 

It would seem the only solution presently would be to wait until the signal is something other than red.

 

So you see, a way to know whether a block is occupied or not would be a lot better.

 

Think about a train reversing out of a siding and you'll see what I mean.

[hosh]

So a Block is declared Occupied when a tag (loco or End Carriage) passes over it and it instructs the signal to show Red/Stop.

A Block is declared Clear if the signal is Y,YY,G or Flashing aspect, but some of the clear commands carry conditions with them.

 

There are a few points I'd like to make here -

 

•  When a train triggers a signal's sensor, the next signal back remains red but is not occupied. This is a very important point to understand.
• When a train resumes, what will happen? How long will it remain green for before it turns back red and how might this effect other signalling? If one interprets a non red signal as a block being clear, then this could lead to some bad situations it would seem.

[PJ_model_trains]

This is all understood PJ, but how does loco 1 know that the block ahead of S8 is clear or occupied? If it is red then that could mean either that a train is stopped there, just took off or that the block is clear but the block ahead is occupied.

 

It would seem the only solution presently would be to wait until the signal is something other than red.

 

So you see, a way to know whether a block is occupied or not would be a lot better.

 

Think about a train reversing out of a siding and you'll see what I mean.

 

Not the question I expected hosh but a fair one.  ;o)

 

Sometimes we have to me careful, we answer a specific question to clarify a point but sometimes know that other things could cause other issues.      Again ;o)

 

Firstly, here I think the main point is it you are in charge of your layout, you designed it, you will plan routes, you will run it, so you know what is happening where. So you will know what is happening on the outer track and the inner one, so you know if the Block is clear or not.

 

Having said that, RM working with LD and remembering more than we see at present will probably come, in time.

 

Now the question I was expecting was similar to what you have asked but based on one track being an upline and the other a downline. Therefore the loco/train is branching on to what then becomes a bi-directional line. At this point knowing the condition of Blocks becomes even more important and I think you would be looking two blocks back and controlling signals accordingly before the loco1 can safely cross over. 

 

The rule of thumb, I think, is similar to that driving a car, if you are on a turn-out on to another line, that line has priority until you set it differently. It would be like crossing into the path of an oncoming vehicle. You would only do so if you knew it was safe to do so. ;o)

 

[PJ_model_trains]

So a Block is declared Occupied when a tag (loco or End Carriage) passes over it and it instructs the signal to show Red/Stop.

A Block is declared Clear if the signal is Y,YY,G or Flashing aspect, but some of the clear commands carry conditions with them.

 

There are a few points I'd like to make here -

 

•  When a train triggers a signal's sensor, the next signal back remains red but is not occupied. This is a very important point to understand.

 

This has been discussed in the past and yes it is an important consideration.

 

I think here you are talking loco not train, a small item, 0-6-0, 0-4-0 or even a small DMU or engine.

 

A train would be longer because it has carriages.

 

So the loco passes over and activates the sensor sending the information discussed back to RM to process. We can be pretty sure for a moving loco it is to request the adjacent signal to turn Red to protect the block. But, no sooner as it requested it to send a Stop signal the small loco is fully in the new Block. This again is back to what I discussed yesterday; we must always consider what happens at the front of a train as well as the back. Two different commands.

 

Now with a train we have a tag on the loco and another on the End Carriage, covering both ends! Commands at the front are different to the commands at the back. Enter Block/Clear previous Block do............

 

With a large steam loco we discussed we could add a sensor on the front of the loco and on the tender which when run on its own has two tags, one controlling as it goes forward, the other controlling as it clears a Block at the rear. Effectively doing the same as a loco and End Carriage 

 

But with very small locos, we cannot do this there isn't room for two tags, so we have to pre-program the tag on the loco to do both, one after the other. So long as we think... Front and Rear and set commands accordingly it will do the same job and if that is the case then we will possibly only ever put one tag on any loco but always have one on a loco that has a rake of carriages or wagons due to the extra length spanning the Blocks.

 

 

[PJ_model_trains]

 

• When a train resumes, what will happen? How long will it remain green for before it turns back red and how might this effect other signalling? If one interprets a non red signal as a block being clear, then this could lead to some bad situations it would seem.

 

As mentioned earlier, the second a tag goes over a sensor the item (loco or end carriage) has entered a new Block.

 

This means as a loco approached a Red signal at say 10mph, even though this is slow, by the time it has read the tag and stopped it is effectively in the next block.

 

We know we can make this loco start again from a command from another sensor but, where it has been thought it may need a green aspect signal (or Y,YY) to resume it, it may not, to be honest we don't know yet. 

 

Changing an aspect to Green, even for an odd second to Resume the loco does concern me as it is going against safe working of signals and Blocks generally. So if the loco can resume from this command alone, a signal changing green to restart it doesn't happen this removes this problem. A diesel engine has a driver at the front but a steam engine driver is at the back or near the back so he would no doubt be able to see a Red aspect signal. 

 

We could argue then that a Resume means a loco is starting again at a Red signal, as it is in the occupied Block, but this would no doubt depend on where our signal is in relation to the sensor.

 

[Howbi]

@ PJ...........As a matter of interest, how would you calculate the track length of each Block?...........I suppose the length of a train should be in proportion to the size of the layout.......so in a garage size layout it would be reasonable to run a steamer with 6 coaches, total length 1.8m..........This would require a Block length of 2 metres if the train was stationary and therefore the all other Blocks would also be 2 metres in length and from this sensors and signals would be placed?   Thinking about real railways the distance between commuter services is probably about 20/25 miles running every 30 mins but you can't scale this down to 00 realistically....HB

[PJ_model_trains]

@HB

With model railways it is first down to the amount of space we have for or layout, then the run of track available to replicate it and divide it up into sections/Blocks.

 

As said before every layout is different but Rule of thumb is, taking the space you have, see what length of track have you got that will accommodate your longest train plus a little bit more, and see if you can replicate the space for that Block evenly around or from end to end with your layout. If you can't run a steam loco and five carriages comfortably in every block then you have to reduce the rake you pull to suit the Block spaces you do have.

 

On mainline railway for 4 aspect signals I believe it is based on about 750 to 850 yards (686 to 777 metres) apart in an intensively used area and up to 1400 yards (1280 metres) apart in a high speed area. It is no use having Blocks to sclose together for fast trains, stopping distance before a Red signal is considered and helps determine what speed a train can run at. The larger the Blocks, from Red, thhrough Y and YY to Green the longer the distance to the Red signal which then allows higher speeds to be run.

 

But we only have models so we only have limited space to play with. When I was working mine out I had to cut back too steam plus 3 carriages, but if I run steam plus 5 carriages I considered that an abnormal length, you can still run a train greater than your Block lengths the only issue it will be forever spanning 2 Blocks so shouldn't be the norm. If you run trains longer than your Block length, you are limiting what you can run so it is always best to work on Blocks that suit your longest realist train plus a bit more.

 

That is how I worked out blocks for my layout. Others may have different thoughts but in general it is train length plus a bit based on the space you have and whether you can replicate it is usually the approach taken.

 

[hosh]

So a Block is declared Occupied when a tag (loco or End Carriage) passes over it and it instructs the signal to show Red/Stop.

A Block is declared Clear if the signal is Y,YY,G or Flashing aspect, but some of the clear commands carry conditions with them.

 

There are a few points I'd like to make here -

 

•  When a train triggers a signal's sensor, the next signal back remains red but is not occupied. This is a very important point to understand.

 

This has been discussed in the past and yes it is an important consideration.

 

I think here you are talking loco not train, a small item, 0-6-0, 0-4-0 or even a small DMU or engine.

 

A train would be longer because it has carriages.

 

 

PJ, this is nothing to do with my point. Nothing to do with the ahead block. Just the one the front tag just triggered at the head of a block and how the signalling there and 1 block back are both R. The point being that though both signals are R, one can be occupied and the other not.

 

So you cannot necessarily know a block is occupied or clear by it's signal.

[hosh]

 Changing an aspect to Green, even for an odd second to Resume the loco does concern me as it is going against safe working of signals and Blocks generally. So if the loco can resume from this command alone, a signal changing green to restart it doesn't happen this removes this problem. A diesel engine has a driver at the front but a steam engine driver is at the back or near the back so he would no doubt be able to see a Red aspect signal. 

 

We could argue then that a Resume means a loco is starting again at a Red signal, as it is in the occupied Block, but this would no doubt depend on where our signal is in relation to the sensor.

 

 

The whole point of signals, imo, is for absolute realism. If they don't look right then what's the point? We can run everything without them anyway. :)

 

So a signal must be seen to remain green for a sensible period of time when a train resumes.

[PJ_model_trains]

@hosh

PJ, this is nothing to do with my point. Nothing to do with the ahead block. Just the one the front tag just triggered at the head of a block and how the signalling there and 1 block back are both R. The point being that though both signals are R, one can be occupied and the other not.

 

So you cannot necessarily know a block is occupied or clear by it's signal.

 

Looking at the small loco 0-6-0, 0-4-0, proceeding in the direction of a sensor 'we' know several things

 

• the loco will pass over the sensor activating it to send ID and Loco Tag date to RM to process subject to our pre-programmed commands
• the loco has a tag underneath to activate a sensor when passing over it
• we must always consider every train or loco must have 2 commands, one for the front end (entered new Block) one for the rear (Cleared last Block). 
• as a 0-6-0, 0-4-0, doesn't have room for 2 tags, we must treat the first tag with two commands (front entered Block - Back Cleared last Block) in order or program for two commands another way.

 

By doing the above there is not an issue. The loco enters a new Block changing the signal adjacent the sensor Red (protecting the Block the loco entered), the last signal (or signals back down the line are changed to set the Clear Blocks to G/Clear or Y/YY OK to continue but with considerations.

 

The key, I think is, Always Think, every train or loco no matter how big or how small, has to have 2 commands,

1. front end commands and (protection the occupied Block just entered)
2. back end commands. (set driving conditions in Blocks behind the loco/train for other loco/trains coming on same track)

 

[PJ_model_trains]

 Changing an aspect to Green, even for an odd second to Resume the loco does concern me as it is going against safe working of signals and Blocks generally. So if the loco can resume from this command alone, a signal changing green to restart it doesn't happen this removes this problem. A diesel engine has a driver at the front but a steam engine driver is at the back or near the back so he would no doubt be able to see a Red aspect signal. 

 

We could argue then that a Resume means a loco is starting again at a Red signal, as it is in the occupied Block, but this would no doubt depend on where our signal is in relation to the sensor.

 

 

The whole point of signals, imo, is for absolute realism. If they don't look right then what's the point? We can run everything without them anyway. :)

 

So a signal must be seen to remain green for a sensible period of time when a train resumes.

 

I fully agree hosh, but we are simulating mainline railway. We are using in this case LD not GPS as main railways use.

 

It is inevitable at some stage there will have to be a compromise. As I am seeing it at present there are two options...

 

First a recap where we are - A train has stopped at a Red/Stop signal as commanded. As discussed previously it is slightly over the sensor, so the pass over of the sensor has been used. The engine driver waits for a signal to continue Y,YY,G or flashing continue signal. 

 

Another sensor is activated by another train, a pre-programmed instruction calls for the discussed train to 'Resume'.

 

Possible options considered.

• the software allows this train to Resume (with no signal change) - this would be unrealistic!
• the software allows Resume, signal sets say Green/Clear - problem here train is in an occupied Block!

 

So for realism we have the signal change Green for a couple of seconds then back to Red.

Possible issues

• Another train may be close enough to enter the occupied Block during the change to green for restarting the first train.

 

Not easy to resolve I think. It leaves 2 choices

1. do we want realism
2. do we want safety

 

I would go for realism but I appreciate some may not.

 

[hosh]

I would go for a system that knows where trains are! :)

 

It's pretty simple too.

 

If the sensor instructions had an instruction for the "Next Sensor", then RM could know -

 

• last sensor
• present sensor
• next sensor

 

In general a train would occupy 2 blocks - the one it's leaving and the one it's headed toward. It would occupy only 1 block in the case it is stopped at a Red. (It could also momentarily occupy just 1 block if it used tags on it's last carriage).

 

This would solve a lot of problems.

[PJ_model_trains]

@hosh

 

The only way I could see RM knowing the Sensor ahead is if it had a map and knew where every sensor is on any track, sub-track, siding etc.

 

I could be wrong, but if RM with LD remembers some items, I think it is more likely to remember those it has travelled over. So if this was the case, we do not know, it would not know the sensor ahead, but a loco is setting every signal Red as it enters a Block. But, by knowing the sensors it has gone over, this makes it easier to process and automate back down the line signalling, providing the safety net check IF/THEN/ELSE was include for every signal set back down the line.

 

I am not going to duplicate things here, this is discussed in detal in the thread, Last Carriage Detections By LD page 8

 

[hosh]

As I already stated, sensors could have an instruction -

 

Next sensor = (sensor name here)

Probably could have it on the same line as the point settings or something like that.

 

Easy enough?

[PJ_model_trains]

@hosh

 

Regarding - Next Sensor - controlling a sensor in front of a train/loco

 

Next sensor being called by its ID, therefore Sensor ID (could be any sensor ID) called to carry out a task.

 

Ahead/behind/or any sensor, we would programme to give a command providing there is facility for this, I would need to look back at the program command list available to us.

 

As you say, should be easy enough, for us to do, we would be programming the Command to a chosen sensor. But, if we decide to program sensors ahead for our locos, it would be our choice,  then we would have to do this for all sensors!

 

Where I am at present, the loco moving forward and setting signals adjacent the sensor to Red to protect the Block it enters is sufficient for the front end. But the back end, controlling back down the line, is a totally different issue that needs addressing sufficiently to control Block conditions without changing the Red/Stop signal created by another train in those Blocks.

 

Remind me again please, why you think we need for the loco driver to know what happens at the next sensor.

 

[hosh]

Firstly, this is not the "tag on last" thread - got nothing to do with it.

 

Secondly, the "Next Sensor = (Sensor name)" is not a way to make commands at the next sensor. It is a way for RM to know what blocks are occupied. End of story.

 

Are you reading the first sentence of my posts, the last, or just a random one in the middle? :) It also seems you are forgetting what thread you're in mate! :)

[PJ_model_trains]

But it is a thread on 'RM seeing ahead/behind'

Next sensor?

[Fishmanoz]

hosh, just did a radical thing and went back and read page 1.  Now I'm wondering why I need to know the next sensor to tell if a block is occupied.  Surely, if a detection at a sensor sets its linked signal Red, then the area in front is "occupied" until a detection at a subsequent sensor sets it clear again (whether Y, YY or G).  Also, you mention a subsequent sensor "taking over control" of a previous signal and I can't see the logic for this.  Sensors control whatever is programmed into their setup instructions which, depending on how you set up your layout, might be anything you like anywhere on the layout, including the previous signal.

[hosh]

Now I'm wondering why I need to know the next sensor to tell if a block is occupied.  Surely, if a detection at a sensor sets its linked signal Red, then the area in front is "occupied" until a detection at a subsequent sensor sets it clear again (whether Y, YY or G).

 

When a sensor is triggered it sets it's signal to red since it's occupying it's own block - this is for the next train behind it. How does it tell us anything about what's ahead? If the signal was green when the train got their then that would mean the next block was clear. Also, when a train triggers a sensor it sets it's signal to red and also the one behind stays red - note how both are reds but one is occupied and the other maybe not. We are also now simply talking about straight lines, not turnouts. If I am turning out, how do I have any information about the next block? The signalling is not set for that, only the mainline.

 

 Also, you mention a subsequent sensor "taking over control" of a previous signal and I can't see the logic for this.  Sensors control whatever is programmed into their setup instructions which, depending on how you set up your layout, might be anything you like anywhere on the layout, including the previous signal.

 

What I have most recently suggested is that if RM had an instruction "Next Sensor" we could add along with point settings for example, then RM could have full information about the occupancy of every block o the layout.

 

This is not a normal instruction - you simply are telling RM what the next sensor/signal is in that particular trains route. Since RM knows when train 003 triggers sensor A, if sensor B was next in it's route and the train is moving, then A and B are occupied. If the train stopped at A then it only occupies A, but as soon as it resumes it would then be occupying A and B until A is cleared by the train triggering sensors in B, etc, etc.

 

The benefits of this are obvious. Now when we turn out RM knows if the block we wish to enter is occupied or not, regardless of signalling, and the problem is solved.

[PJ_model_trains]

@hosh

When a sensor is triggered it sets it's signal to red since it's occupying it's own block - this is for the next train behind it. How does it tell us anything about what's ahead? If the signal was green when the train got their then that would mean the next block was clear. Also, when a train triggers a sensor it sets it's signal to red and also the one behind stays red - note how both are reds but one is occupied and the other maybe not. We are also now simply talking about straight lines, not turnouts. If I am turning out, how do I have any information about the next block? The signalling is not set for that, only the mainline.

 

For RM with LD to do what you are suggesting it would have to know, and remember, where every sensor is, on every track, every loop, every branch line etc. Or we would have to sit down and set a route for every train telling it the Port address of every signal with the ID of every sensor on its journey. 

 

I do not feel this is how RM with LD is designed, it is to rigid, the name tells us about the system, it is Loco Detection. A train or loco comes to a sensor, the system detects it, it knows the sensor and tag ID's and looks to see what we have pre-programmed it to do so that it can continue on its journey.

 

Your train goes along the track and passes a sensor, the signal adjacent the sensor changes to Red. You say... 'When a sensor is triggered it sets it's signal to red since it's occupying it's own block - this is for the next train behind it.' this is not actually correct, yes the Red signal is to stop another train entering the Block your first train is in but, the Red is also protecting the full Block your first train is in, from entering the Block right up to the next signal, which includes in front of the train to the signal as Fishy stated. The Red signal protects the full the Block, this may be for any train in the Block but may also be  to close the Block due to an accident, debris on the line, etc. It protects the Block 'whatever' the reason.

 

When the train driver is driving his train, he does so Block by Block. He may hope to go on his journey as he has before but other trains may be running slow, an unexpected incident may occur, etc, etc. So he runs from Block to Block as commanded. Loco Detection works the same way.

 

Regarding turn outs, we touched on this yesterday, a train can only cross onto another line when it is safe to do so. Our first train, one sensor/signal back from the signal at the branch can call for the signal on the secondary line, just before the branch to change to Red, which in effect is protecting the Block ahead on the secondary line, the Block our train with branch onto, the new Block our train with enter. It can also request for the points to change. There would no doubt be another sensor/signal just before the turn-out on the main line. This would only change to green when the Red signal on the other line has safely stopped any other train from passing, when the points have safely changed, when it is safe to continue, as on our roads, no train can cut into the line of other traffic, cross onto another track, without first making sure it is safe to do so. 

 

Each train knows what it can do in the Block it is in, but needs additional commands to continue into the next Block, then the one after that, etc. First setting the conditions of the Block it enters by the first tag, front end command set signal Red, (loco or end carriage depending whether pushing or pulling), then setting the signals of the Blocks behind, setting driving conditions for any other train coming down the same line, end tag (again loco or end carriage). 

 

[hosh]

For RM with LD to do what you are suggesting it would have to know, and remember, where every sensor is, on every track, every loop, every branch line etc. Or we would have to sit down and set a route for every train telling it the Port address of every signal with the ID of every sensor on its journey. 

 

Remember where every sensor is?

 

It would know Train T was occupying blocks defined by sensors.

 

It would remember stuff like Train T is occupying blocks A and B. In fact, for what I am suggesting it doesn't even nedd to know what train - just that a block is occupied or not.

 

Bog simple!

 

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.