RM/LD seeing ahead/behind.

[hosh]

Lets say we have 2 loops with a line crossover. And lets say train T is stopped at Sensor/signal A on the outside loop and wants go through the crossover.

 

It needs to make sure neither block on either side of the points on the inside loop are occupied (or that the block before the points has a stopped train at least) before it can get the green.

 

But how will RM know it even needs to see these blocks as clear for this route? We have been thinking in the simple terms of a sensor ahead telling a signal back down the line (the one and only line) to set signals to green, but with points turned out this creates a new problem.

 

It would seem that depending on route, the signalling will be handled differently. I guess when train T first stops, the route information is considered by RM. The sensor up ahead on the inside line (Sensor B) will need to be notified that train T at signal A wants to approach it and so sensor B will now be telling signal A to go green whereas it would normally tell that to sensor C further back on it's own loop if the points were straight. Similarly, signal A would normally be getting it's instructions from a sensor further ahead on the outside loop if the points were straight.

 

But RM will need to know more than point settings to know what sensor will be ahead. There is no connection for that presently.

 

It would seem RM might use a points table. You can then tell a train to go from sensor A to B and this is in the points table and the points are automatically set. You also know what sensor you're headed toward.

 

I guess another way would be to have an explicit instruction at sensor A that tells sensor B to take over controll of Signal A in some fashion.

[Fishmanoz]

Great thinking hosh, brilliant use of your imagination (I'm not known for exaggeration!) to first recognise that RM isn't currently coded to do this and then that automation under LD will require something like this.

 

May I suggest that you think this through a little further, decide which is the best way to implement it and involves the least enhancement to current RM capability, then post that suggestion in the Desirable Features thread, just as I have just done for the conditional on position suggestion.

 

Now we are really getting somewhere.  We aren't just speculating, we are coming up with specifics we think are needed for automation under LD.  HRMS may already be ahead of us and thought of the things we are coming up with, but then maybe not, or maybe they were thinking of doing it one way, and our different way is better.  Whatever the actual situation, our ideas can only help.

[hosh]

Yes, it will be interesting to see how many boxes get ticked upon release of LD.

 

• tender first running
• reverse loops
• non straight routing/signalling
• signalling for simultaneous running of trains in opposite directions on same track

 

I think the first 3 are plenty doable.

[hosh]

Something else that is curious. Someone mentioned the other day about setting all points to straight after a train passes - a good idea for an automated system since if straight is the default then we'd only need to notify the system in the event of a point being turned out. But then I notice that in RM presently there isn't any straight/turned - just right or left.

 

The implications of this is that even though all of conversations have implied "straight" thinking, if Hornby leave the point logic as simply left/right instead of straight/turned, then what I've spoken about here applies to any signal/sensor with a choice of direction ahead of it since there is no "straight" atm it would seem.

[hosh]

I knew there was something else! LOL

 

Here's another problem. We have a train approaching sensor A as in the example in the first post. By default, the points are probably set for the outside loop and if the blocks ahead are clear then there would be a green signal. This is clearly no good if the train is turning off and those blocks are occupied.

 

So it seems that at the sensor before A we will need to pre notify the signal at A to look in Train T's route direction and set it's signal accordingly. If it was clear it could set itself to green, probably then also set the points and adjust signalling on the inside loop.

 

We have a lot to learn! :)

[Fishmanoz]

3 up hosh, I agree your first 3 are simple and, without thinking it right through, I think the last can also be done with existing commands.

 

In your 2 up, yes, only set left and right.  And one consequence is that, if a left point fits more neatly than a right point, even though your actual  track piece is a right point, there is no reason not to design it in your schematic using the neater left point.  And often, complex track pieces are represented in schematics by a number of simpler pieces.

 

In yours immediately above, I agree and I think you've just identified the need for conditional instructions For point set left, and For point set right, which should allow the problem to be managed in a simple way.

[PJ_model_trains]

Good explanation and good image Phil

 

It will happen, I have mentioned this in the past, especially on branch lines, where a train on one line wants to branch to another and both the trains on the main line and branch line could  both be held up. I discussed priorities in the past, but only us know which train has priority. It may not be the one on the main line, the one branching onto the main line may be an express of passenger train, where as the one already on the mainline may be a slow moving goods train with a lesser priority. 

 

How we program these priorities will no doubt depend on how we run our trains, using programs or using railway conditions sensors, signals, etc. A rigid program will cope for these situations as we will have programmed the priorities in, but running to railway conditions requires planning, especially for priorities. I think.

 

[hosh]

This makes me wonder about real life train signalling.

 

Anyone know what they do in the real world when a signal has more than 1 possible route beyond it? I guess the operators always know where all the trains are and where they're going and signals are set accordingly? Or is all that done automatically too? Do they have sensors, Train IDs, etc?

[PJ_model_trains]

Hi hosh

 

I don't know myself but think they must have a schedule of trains running in the day, they will know which are express and running to stricter timetables. Which are goods that run slower etc. Most is probably computer controlled from their point of view until the unexpected happens. This could be something on a line, a crash, or even a train driver not responding to an AWS. Hence the importance of train drivers driving within the speed limits and the signal aspects, knowing from experience stopping distance of their train, which has been discussed in the past, can be a long way for faster trains.

 

[Howbi]

Every loco is monitored via GPS, the ultimate train control system...........the controllers know precisely the location of every turnout, signal, crossing etc.............just what we need at home on the model :o)   HB.

[PJ_model_trains]

Brilliant reply. HB

It also makes a lot of sense ;o)

 

[Howbi]

@Fishmanoz.................I've just been reading about RailCom by Lenz Gmbh in both the old Elite manual and also the latest manual..........the old manual (2010) comments........the locomotive can return information to the controller such as speed and details on the load being pulled..........this and much more will be available in time, the operating protocol for RailCom is still being developed...............In the latest manual the comment is...RailCom is a technology supporting bi-directional communication between a decoder and the controller..........We already know the Sapphire decoder supports RailCom and uses advanced features.......some other decoders already support as well..........my point is........a co-operation between RailCom and Hornby would answer many LD questions.. HB

 

Acknowledgement.....RailCom is registered to Lenz Elektronik GmbH

[Fishmanoz]

HB, I think your answer may come from the fact you are looking at Elite manuals on this.  I think it is a little different once you look at RM.  I'm not sure how Railcom feeding back decoder data is going to add much to current and future RM capability.

 

How do you see it?

[Fishmanoz]

On how real railways work, we know current standards don't rely on signals at all and that they are being removed.  The best forum source on this is LC to my memory, so a signalling question in the General forum may help, as may a forum search on signalling because I know LC has posted in some detail previously.

[Howbi]

@fishmanoz.............In Railcom for example, the decoder reports it's loco speed back to the PC......so this negates the idea that a LD loco tag provides speed info..........then the ID tag, therefore, is probably just a number easily read by the sensor in order to link it to the sensor commands and no other purpose.........The loco decoder is a sophisticated piece of kit and will play a big part in the operation of LD although I fear we will need a new design decoder for this purpose..........The Hornby Sapphire decoder shows the programming potential and is RailCom compatible.  HB.

[hosh]

In some other threads people are suggesting that expectations are too high. I wonder if this problem will be dealt with by the Pro Pack or at all.

 

When was LD first promised to be released - 2013? So I'd assume it was also at least a year or 2 in production before that. So what can we expect from 4-5 years of development?

[Fishmanoz]

HB, do you really think anyone is going to install LD if it means they have to replace all their non-Railcom decoders?  And if it had to be an 8245, half the time it may not fit anyway.  Wouldn't it be simpler to just read the time taken for a tag to pass over a sensor and calculate speed from that?

[hosh]

So there are a lot of decoders that don't send back speed? In any case, it wouldn't be necessary to have Railcom decoders, just better. And having the decoders do this means the sensors need to be less sophisticated/expensive.

 

What's the big deal with speed other than just wanting it displayed for the novelty? To slow ----> stop trains with accuracy either by a program and/or the decoder's built in deceleration?

[Fishmanoz]

Will depend on how you want to run your layout I think hosh.

 

My suggestion though is that RM is unlikely to rely on a feature that is not always available, even when it is.

[hosh]

Bringing this post over from the "Last Carriage Detections by LD" thread.

 

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.

[PJ_model_trains]

@hosh

We are duplicating here. This was in the other thread and was discussed in the other thread.

 

Surely the discussions are long enough without repeating the same question twice in two threads.

 

RM will know which direction you are travelling by the sensor and arrow in your layout design that you set up.

 

Your Blocks are as we have all discussed on your mainline and if you branch, the point can change the signal on the secondary line to stop locos continuing through the branch. On Signal Red - Stop

 

Example

 

_____________Loco2___________ <<< dir of travel (secondary line)

                                                                

_____________Loco1___________ <<< dir of travel (main line)

 

  = showing branch (best possible using text symbols)

 

Loco1 on main line is going to branch into secondary line. Loco2 was coming along but because the branch is set, the signal at the sensor before the branch on the secondary line is Red - thus sensor commands Stop Loco2.

 

Loco1 has priority, points have changed, sensor on main line has Set signal for the branch either Y, YY, G of flashing.

 

I think as we get closer to LD and discuss these items in more detail we need to create images to detail for discussion but also need them to be released quicker. Text is just working for now (I think) but discussions are becoming more complex and we need to be singing from the same hymn sheet. 

 

[Fishmanoz]

For me hosh, the short answer is we need 2 new instructions:

 

For point set left

For point set right

 

I have already included these in Desirable Features.

[hosh]

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.

[hosh]

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.

 

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

[hosh]

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.