Last Carriage Detections by LD

[PJ_model_trains]

@hosh

The last tag would simultaneously set the last block as clear and the block it just entered as now occupied, long before the front tag reaches the sensor at the head of that block.

 

The last tag would only change the signal for the previous Block once the End Carriage, (or the loco if the loco is pushing the carriages), has passed over the sensor safely clearing the previous Block. At that stage the previous Block(s) signals will change depending on the number of aspects of the signals on that line.

 

So for a 2 Aspect the previous Block signal would change to Green/Clear 

For 3 Aspect the previous Block signal would change to Yellow and the one before that to Green/Clear

For 4 Aspect signals the previous Block to Yellow, the one before that to Yellow-Yellow, the one before that to Green/Clear.

 

All subject to track/layout design and whether or not there are branches coming onto the main line in any of the preceeding Blocks.

 

But if any signal, back down the line controlling a previous Block has a Red aspect signal, it must remain Red, as this indicates another train is behind the first and it or its end carriage, depending how it is run, has entered a Block and the Signal is Red protecting that Block. 

 

[PJ_model_trains]

@hosh

You simply only instruct signals behind you, not the one the front of the train is approaching of course. 

 

Again I don't agree hosh,

 

You are correct regarding instructions for changing signals behind the train, (last tag) subject to Block conditions, but as the first tag passes a sensor that must change the signal adjacent the sensor it has just passed over to Red. This is to ensure that it is protecting the Block the loco or end carriage (first tag) has just entered. 

 

It is the last carriage (or loco if on the end) that sets the signals back down the line as it has clears the Block it came from and any before that subject to signal type.

 

This was why I tried to explain earlier the importance of the first and last tag, which may be the loco, or it may be the End Carriage.

 

No doubt the arrows following a sensor detection will be important here for detecting the direction the train/loco is travelling, irrespective of which end the loco is or whether it is going forwards or is going in reverse.

 

[PJ_model_trains]

This raises a new very interesting question for LD in general.

 

So I am sitting at a Red signal before a set of points in block A and depending on point setting I can go into block B or C. It is required that a block be set as occupied as soon as a train leaves a previous block - it cannot wait for that train to trigger a sensor in that next block to do this because another train might be entering at the same time. So how will RM know whether I'm headed for block B or C i.e. how does it know what block to declare as occupied?

 

It would seem RM will need read ahead ability. It looks like we will need to tell RM this info for when a train moves off, or even for one already in motion.

 

Branching lines is a whole new ball game, first it will no doubt depend on where your sensors are on each track, everyones track is different so that would be hard to comment on and ABC word explanation, a diagram would be needed for discussion. 

 

What is pretty sure, I think, is we know our layouts, we know where sensors are, where branches are, we are running the locos and we will have to decide how we get over branch issues. The first thought I have is that the turn-off is activated and your turn off controls the signal for trains/locos coming down the other line  towards the branch to Red. Loco approaches sensor, signal is Red/Stop, loco stops.

 

[hosh]

The point I am making here, is that I think Hornby will have the ahead block set to occupied not by sensors in that block, but by instructions from the previous block as a train passes a sensor or resumes. This is the only way to avoid head on or branch collisions.

[hosh]

You are correct regarding instructions for changing signals behind the train, (last tag) subject to Block conditions, but as the first tag passes a sensor that must change the signal adjacent the sensor it has just passed over to Red. This is to ensure that it is protecting the Block the loco or end carriage (first tag) has just entered.

 

See last post.

 

When the front of a train reaches the signal/sensor, the main thing that will happen is that the train either stops or continues. The block is already set to occupied as soon as this train left the previous block as per my last post. Or even if it was done by the last tag as it exited that block, but as I mentioned this can lead to collisions.

 

The front tag would only set the next block as occupied if the train continued - IMO that will be all it does as far as signalling is concerned. This is also the case for a resuming train, but done out of memory rather than a sensor trigger.

 

I would also suggest that after a train passes a signal, either by continuing or resuming, that the signal will remain green for approx 10 sec (after the cab passes) and then go red. Then the block will be cleared when the train is detected (in whatever fashion) in the next block.

[PJ_model_trains]

@hosh

I am not sure Hornby will set any ahead block, what they are doing is giving us the tools to use as we think best, it will be down to us to program and plan for ourselves within the limits of the program.

 

If there is an instruction from a previous block it will be because we programmed it.

 

Head on collisions and branch collisions are two totally different issues I think.

 

Take branches first - these can be avoided by careful planning. It means getting points and signals to work together, I spent days playing with this last month, allowing for bi-directional traffic running programs to simulate it, for every branch that changes every track leading to that branch has to be closed by a Red/stop signal.

 

Avoiding head on collisions need careful planning and are probably the result of running bi-directional traffic. It is no use us just changing signals back down the line, as one is working in one direction and the other in the other direction. I cannot speak for how we will do it because we are all different, with different layouts and different ideas, but for me I expect to first run my trains and get used to routes, crossing main line to secondary lines, so individually they can be bi-direction to the planned up line and down line. Start simple, master that and then become more adventurous but as I say that will be how I will attempt it, and we are all different. To me making sure signal change back down the line without changing a Red is of extreme importance. If this doesn't work then crashes other than thos e you mention will occur. ;o(

 

[hosh]

So you are preceding on the assumption that Hornby's system will be such that a block can only be declared occupied by a train triggering a sensor in that block?

 

Here's what I hope they do -

 

•  A train in motion triggers a sensor who's signal is green and the train simply continues. At this moment it also sets the block the trained is headed toward to occupied.
• A train stopped at a red that has just changed to green resumes. Again, at this moment the block the train is headed toward is declared occupied.

 

IMO, it will be impossible to deal with branching or head on collisions otherwise.

[PJ_model_trains]

So you are preceding on the assumption that Hornby's system will be such that a block can only be declared occupied by a train triggering a sensor in that block?

 

A Block can be declared occupied, by a Red/Stop signal at the entry to the Block,. This can either be by...

 

• by a Loco/End Carriage passing over the sensor and the signal changing Red - using LD
• by another sensor Setting a signal Red/Stop
• by a Program setting a signal Red/Stop
• by a Point setting a signal Red/Stop
• by the user setting a signal Red manually

 

Here's what I hope they do -

•  A train in motion triggers a sensor who's signal is green and the train simply continues. At this moment it also sets the block the trained is headed toward to occupied.
• A train stopped at a red that has just changed to green resumes. Again, at this moment the block the train is headed toward is declared occupied.

IMO, it will be impossible to deal with branching or head on collisions otherwise.

 

Taking your options one by one...

 

Option-1 --- yes a train (or end carriage), triggers a sensor at the start of a Block. It could be Green/Clear, Y or YY or Flashing aspects any aspect other than Red.  'The moment' the tag passes over the sensor (which is your Block Marker) it tells the signal to change to Red/Stop. - Note once it has passed over that sensor it is in the next Block not heading towards it. 

 

Option-2 --- it has been discussed that a train will be able to 'Resume' from a stopped position when the signal changes to Green (hopefully to Y or YY as well). Now if that train came to that signal and stopped it probably stopped by passing over the sensor which told it to Stop on a Red signal. So it is actually in the next Block although if speed was reduced in the run up to the signal/sensor it should only just be in the Block. But the system knows the loco is at that sensor and the signal is Red/Stop. So when the loco is told to Resume, it knows where to resume from. Another sensor has activated this signal to go Green for the loco to resume so we must asume that we have also programmed it to change back to Red after a few seconds. e.g. as soon as the loco has passed the signal as it is in effect already in the Block. The Green was only to Resume activity with the Loco therefire as it is moving in that Block, that Block must be protected with the Red/Stop signal.

 

[Fishmanoz]

PJ, easy to avoid resetting signals which are red by only implementing conditional instructions to change:

 

For signal Y, set signal YY

For signal YY, set signal G

 

Having not put any instruction for a Red signal, nothing will happen on one.

[Fishmanoz]

Hosh, I answered your point allowing train to proceed to either B or C where you last asked it: I've already asked for new instructions For point set left, For point set right.

[Fishmanoz]

The conundrum of avoiding head-ons:

 

hosh, if a loco sets to red not only the signal linked to the sensor it has been detected at but also the one in front, then that loco will never get anywhere as it will then stop at the signal in front. As it's stopped itself, there will be no detection, ever, to get it going again.

 

This can only work by having up-line and down-line signals separately and using conditional instructions for direction.

 

Then, if it ever happens that you have 2 trains stopped and facing each other from either end of a block, you will have to run a program to reverse one of them back and into a passing loop, and have a sensor in that loop that turns the signal green for the stationary train and restarts it.

[hosh]

Hosh, I answered your point allowing train to proceed to either B or C where you last asked it: I've already asked for new instructions For point set left, For point set right.

 

What we need is a way to see if blocks are clear or not, not just what colour a signal is. The signal at the head of a block might be red but how do we know whether it's clear or not. What's the difference between a block with a train stopped in it and a block without a train but still a red signal?

 

There is "Set clear signal" but does that set the block to clear or merely the signal to green? I suppose that command is actually used when a train triggers a sensor in a block, sets the previous block to clear but with a red signal and then the block back from there to G?

 

There seems to be no command for "For block clear".

[hosh]

The conundrum of avoiding head-ons:

 

hosh, if a loco sets to red not only the signal linked to the sensor it has been detected at but also the one in front, then that loco will never get anywhere as it will then stop at the signal in front. As it's stopped itself, there will be no detection, ever, to get it going again.

 

 

Not even close to what I said - have another read. :)

 

As mentioned in my last post, there is a difference between setting a block to occupied and setting it's signal to red. I sincerely hope so at least!

[hosh]

PJ, I believe you mentioned not wanting to effect signals behind if another train was a few blocks back from the front one. In this case, RM needs to only allow the front train to effect signals that the 2nd train hasn't gotten to yet. Another case of RM needing memory.

[PJ_model_trains]

PJ, easy to avoid resetting signals which are red by only implementing conditional instructions to change:

 

For signal Y, set signal YY

For signal YY, set signal G

 

Having not put any instruction for a Red signal, nothing will happen on one.

 

Taking original thinking we would give a command to a previous signal to change one aspect, the one before that one aspect, the one before that one aspect. Suject to signal type, for the fuller example lets stick to 4 aspect.

 

Here we have a loco travelling < direction and is in Block S4-S5 this Block is protected by a Red signal at S4

 

We have preset signal conditions back down the line to suit Block conditions for this signal type.

 

____S5-G_Loco_S4-R_____S3-Y____S2-YY____S1-G_ <

 

So far so good... now the loco moves forwards < direction

 

Loco_S5-R_____S4-Y_____S3-YY____S2-G____S1-G_ <

 

As the loco passes sensor 5 the signal adjacent changes to Red - again OK so far

 

Now we want S4 to be Yellow, S3 to be YY and S2 to be G

 

You suggest...

For signal Y, set signal YY

For signal YY, set signal G

 

But I want the previous Block, which was Red to change to a Y aspect... how do you do that?

 

S3 was Y so your suggestion could change to YY

S2 was YY so again with your suggestion could change to G

 

But with your suggestion above I want to change a Red to Yellow this is where I think it falls apart, I could be wrong,, but at present it doesn't appear to work.

 

The way I was trying to achieve the result was by  'Setting' aspects 

 

Set S4 to Y

Set S3 to YY

Set S2 to G

 

But as mentioned this could change a Red signal which was changed by another train passing a sensor and changing a signal to protect a Block. A loop command stopping this happpening would solve the situation using Set commands.

 

Discuss

[PJ_model_trains]

PJ, I believe you mentioned not wanting to effect signals behind if another train was a few blocks back from the front one. In this case, RM needs to only allow the front train to effect signals that the 2nd train hasn't gotten to yet. Another case of RM needing memory.

 

No need for RM to remember hosh

 

A loco can only go forward if a signal is not Red, Red always Stops as it is protecting the next Block

 

Here we have 2 trains on same track, travelling same direction, Train2 is going faster than train1

 

___[s-G]__Train1[s-R]________[s-Y]________[s-YY]_Train2_[s-R]______

 

Here we can see Train1 has moved forward at slow speed, Train2 is narrowing the gap

 

As the Train2 passes the signal it changed signal to Red protecting the block now in

 

Train2 can still continue as he passed the YY signal procedd with caution - he has started to slow down.

 

___[s-G]Train1__[s-R]________[s-Y]_Train2__[s-R]_______[s-YY]______

 

But he continues to close the gap between him and Train1

 

_Tr[s-R]ain1____[s-R]__Train2_[s-R]______[s-YY]______[s-Y]__Train3_

 

Train1 has started to pass over the sensor and the signal protecting the Block he is entering turns Red to protect his next Block. Meanwhile Train2 has passed another sensor, entering another Block, changing the signal for Block entered to Red and previous ones have changed down the line to Y,YY and G.

 

Train2 has been allowed to catch up to Train1, allowing just one Block between them, but it is done by protecting every Block the loco enters (front end) and altering Signals so suit Block conditions behind it. (In case a 3rd train catches up, it can happen). Each signal in turn has allowed the train driver to slow down, first reducing according to a YY command then the Y, proceed with Extra caution. 

 

This is how we should simulate Block conditions, it is exactly the same on mainline railway. Our sensors will detect the loco and set signals which in turn allow the loco on passing a signal to reduce speed, first slowing, then slowing further in readiness to stop if needs be. Memory is not needed the sensors and our pre-program instructions will do it all. ;o)

 

[PJ_model_trains]

Duplicate message!

 

[Howbi]

The headway is actually defined as the time between following trains such that the second train runs under clear signals (Green). This is illustrated in Figure 1. The lowest section of the figure indicates the lamps that will be illuminated on a signal, as seen by a driver approaching it (from the left). The distances involved start with an approach distance to the first signal to allow for the driver to observe a clear signal (D1). The next distance is between the first signal and the first warning signal (signal 2) (D2 + D3), followed by distance to the signal protecting the first train (signal 3) (D4 + D5). The next distance is the length of the train so that the rear of the train is past the signal (D7). Also in the UK is the overlap distance past the second signal (D6). This is a distance for a short overrun in the case of a misjudgement of braking. Speed will be taken as v and time as t.

 

 

/media/tinymce_upload/3ff2e855b39d4d3d4e3696128e474268.png

Might this info help?   HB.

 

[Howbi]

Credit for my previous post regarding Headway goes to Anthony Hoath......HB

[PJ_model_trains]

@HB

The image and notes are basically what we have been discussing but in the above it is for 3 aspect signals

 

_Train2___[s1]_________[s2]________[s3]__Train1    direction of travel >>>

 

Train1 is in the position shown - signal [s3] is Red protecting the Block it is in/as entered.

 

Signal [s2] is Yellow - when Train2 enters this Block he is to proceed with Caution knowing he may have to Stop at the next signal [s3]

 

Signal [s1] is currently Green/Clear as Train2 starts to approach it .

 

[hosh]

The way I see it is like this -

 

Let's say we have 5 signals in a row, S1-S5.

 

Train 2 can never get within a block of train 1, so if train 2 pulls up at S3 (with train 1 now leaving S2 and heading for S1) then as T1 clears S2 it will attempt to set the signals for S2 ®, S3 (Y), S4 (YY) and S5 (G).

 

So even if you don't allow it to adjust Rs, T2 had S3 set R (ok), S4 set R (ok) but S5 was set to Y and now T1 will set that to G. We obviously don't want this.

[PJ_model_trains]

@hosh

 

See discussion notes below.

 

Note: it would help to confirm direction of signals 1-5 <<< or >>>

and direction train is travelling <<< or >>> (not forward or reverse)

 

So taking what you say in stages from your example... (I have included your comments in italics)

 

1 - signal orientation

___[s1]______[s2]______[s3]______[s4]______[s5]___ 

 

2 - so if train 2 pulls up at S3 - using Arrow on train or <<< direction of travel helps

___[s1]______[s2]______[s3]_<Train2_[s4]______[s5]___ 

 

3 -  (with train 1 now leaving S2 and heading for S1)

___[s1]______[s2]_<Train1_[s3]_<Train2_[s4]______[s5]___ 

 

Signals 'at this stage' must be

___[s1-G]______[s2-G]_<Train1_[s3-R]_<Train2_[s4-R]______[s5-Y]___ 

 

4 - as T1 clears S2 it will attempt to set the signals for S2 ®, S3 (Y), S4 (YY) & S5 (G).

 

Your example would be....

___[s1-G]_<Train1_[s2-R]______[s3-Y]_<Train2_[s4-YY]______[s5-G]___ 

 

Correct assumption for Train1 if there was no Train2, but because Train2 is in S3-S4 Block the signal aspects would be

___[s1-G]_<Train1_[s2-R]______[s3-Y]_<Train2_[s4-R]______[s5-Y]___ 

 

Signals back down the line

- should only change 'back to a Red'

- and 'never change a Red'

 

Do you agree with this hosh?

 

[hosh]

Signals back down the line

- should only change 'back to a Red'

- and 'never change a Red'

 

Do you agree with this hosh?

 

 

Yes.

 

But if I worked for Hornby and they asked me to put that in the manual then I'd leave! :)

 

BTW, you have seen pages 82-84 of the pdf I take it. It would seem to me that manually writing all this stuff in the sensor instructions won't be needed.

 

Here's a much more simple solution -

 

• Train 1 simply sets the signals behind it as usual
• As Train 2 triggers sensors behind T1 it overrides T1's previous signalling
• RM simply needs to remember the last train at each sensor and doesn't allow any other train to effect the signals at those sensors.

 

This is what I hope pages 82-84 become with LD.

[PJ_model_trains]

@ hosh

 

Before I reply to the first question I would prefer to re-read the PDF guide as changes are made.

 

I don't agree with the first statement

• Train 1 simply sets the signals behind it as usual

 

You don't know how long Train1 is! How can the front end of a long rake of carriages or wagons know what the back end is doing. Prior to technology there was an engine driver and a guards van. 

 

There has to be control at both ends of a train, as discussed the front protects the Block entered, the back sets driving conditions of previous Blocks back down the line, subject to signal types, with the various signal aspects available. 

 

[PJ_model_trains]

@hosh

• RM simply needs to remember the last train at each sensor and doesn't allow any other train to effect the signals at those sensors.

 

There is more to it than that hosh. Signals need to control Blocks back down the line.

 

Those aspects are triggered by the actions of the last carriage

 

They must be according to signal type 3 aspect Y, G,  4 aspect Y,YY,G but, they should only be back down the line to a Red and not changing a Red.

 

If anything should be automated, this I think is one of them. Setting signals back down the line, triggered by the tag on a last carriage should be in the sequence the matches the signal type, but only back to a Red and never changing a Red. RM will need to remember a few things here (Sensor ID # - Signal Port #) in direction of arrows. Plus a suitable IF/THEN/ELSE that safety nets any aspects changing that should not change.

 

So if a train is going forwards and the last carriage passes over the sensor, it has travelled over and remembered 

 

Sensor 1 - Signal Port 23

Sensor 2 - Signal Port 28

Sensor 3 - Signal Port 33

Sensor 4 - Signal Port 38

 

The Loco has passed Sensor 4 changing Signal on Port 38 to Red

The Last carriage passes over Sensor 4 changing Signal Port 33 to Yellow

Also changing Signal Port 28 to Yellow/Yellow

And Signal Port 23 to Green

(No problem... providing no other Train or Loco has entered those, Back down the line, Blocks)

 

But a Train has Passed Sensor 2, same direction of travel, Signal Port 28 is changed to Red, Port 23 remains Red as the second trains carriages are in the first Block.

 

The last carriage on the Train 1, then passing over sensor 4, set signals back down the line correctly to Y,YY and G as all previous Blocks were Clear.

 

But, if Train 2 passed over Sensor 2 before the last carraige of Train 1 passed over sensor 4 then the situation is very different.

 

As the last carriage of Train 1 passes Sensor 4 it should look to

change Signal at Sensor 3 Port 33 to Y (it should check is this signal Red? No - so change as commanded)

 

it should look to

change Signal at Sensor 2 Port 28 to YY (it should check is this signal Red? Yes - do nothing - Stop checking)

 

This is what should be automated I think, we want to be engine drivers, we want to concentrate on our trains going forward and let software automate behind, that is what GPS does. It knows which train, it knows where the front of the train is, it knows where the end of the train is, 'then software processes the back down the line commands to signals setting driving conditions in Blocks for other trains to continue on that same line'. Right up to the Block behind the occupied Block.