Last Carriage Detections by LD

[Fishmanoz]

PJ, I'm prompted to start a new thread on this by your recent post on it in Desirable Features and the fact that currently, nothing in RM addresses it directly.

 

We know the only place tags can be associated with anything at present is in loco setups.  Consequently, if we want to have tags on last carriages,cthe you can currently only be done as dummy locos.

 

But having done that, what can we do, or another way, what do we want to be able to do.  Clearly the end objective is to determine when entire trains have cleared blocks.  I think that's all, or do you see anything else PJ?

 

I'm also not sure how such a setup might work.  Normally, the primary information in a loco setup is an ID which is written to a decoder.  Clearly for a last carriage, you could assign an ID but you certainly can't write it to a non-existent decoder.  Let's just assume for now the setup can sit there with an ID assigned and not written, and also with an LD tag assigned.

 

The next thing we know we can't do is drive it anywhere - no decoder or motor is significantly limiting in this regard.  But we can put conditional instructions in sensor setups that can apply. The relevant instructions are For loco(s) and For loco type(s).

 

Am I right that one of the things you want in Desirable Features is to be able to address instructions to groups of locos?  I wasn't sure I had this right as my understanding is that this has always been possible via the loco types instruction and we've talked about addressing just such groups for ages?

 

Anyway, if we can't drive such locos, what can we do?  The answer is that we can write conditional instructions to apply to them.  You've talked about putting each of locos, tenders and last carriages various in their own groups for this.  My thoughts have been more towards putting a loco, tender and last carriage into their own group, and so define a train, but that's limiting as soon as you you want a loco to pull more than one train. You could put all possible last carriages in the group, but then that would preclude putting them in any other train group, so again very limiting. 

 

So so I think my question is - do we need RM to have a whole new screen for setting up last carriages not being dummy locos?  Or do we need a separate category entirely in Loco Setup for them.

 

Then having decided whether such a new capability is needed or not, how exactly will we use them.

 

For me, this defines the problem and my question is where to now.

[PJ_model_trains]

PJ, I'm prompted to start a new thread on this by your recent post on it in Desirable Features and the fact that currently, nothing in RM addresses it directly.

 

We know the only place tags can be associated with anything at present is in loco setups.  Consequently, if we want to have tags on last carriages, it can currently only be done as dummy locos.

 

But having done that, what can we do, or another way, what do we want to be able to do.  Clearly the end objective is to determine when entire trains have cleared blocks.  I think that's all, or do you see anything else PJ?

 

The main reason for tags on last carriages, last wagons or guards vans, is as you have understood to confirm a Block is cleared. We could include the tender on large locos in this group.

 

So the aim is, as on mainline railway, to set signals 'back down the line', providing clear guidance for any other train driver coming along that line, Block by Block. As this is a new thread on the subject I will add more detail althoguh it has been covered in the past elsewhere.

 

Using the following example = sensor which has a signal adjacent it/just ahead of it

L=Loco

C-C-C = carriages

Track and direction of train below

 

_____[s4]__________[s3]__________[s2]__________[s1]_________[s0]_____

<<<Direction of travel of the train (Could be forward or reverse)

 

(STAGE-1) Below we know [s1] was activated by the Loco passing over sensor and signal for S1 is Red/Stop

_____[s4]__________[s3]__________[s2]__L-C-C-C___[s1]__________[s0}_____

 

(STAGE-2) Below we know [s2] was activated by the Loco passing over sensor and signal for S2 is Red/Stop

We also know [s1] is still Red/Stop as a carriage is still in the first Block

_____[s4]__________[s3]______L-C-C [s2]-C________[s1]___________[s0]_____

 

(STAGE-3) Below we know [s2] signal is still Red/Stop

But as last carriage passes [s2]

- it changes the signal at [s1] to (Y for 3 or 4 aspect signals)

- it changes the signal at [s0] to (YY for aspect signal)

_____[s4]__________[s3]_L-C-C-C__ [s2]__________[s1]__________[s0]_____

 

So at Stage 3 we have

- the train in Block [s3-S2]

- Block [s2-S1] has a Y signal aspect adjacent [s1] - Proceed with Extra Caution signal command

- Block [s1-S0] has a YY signal aspect adjacent [s0] - Proceed with Caution signal command

 

So the main aim of the last carriage detection is first confirming the previous Block is clear, then by changing signals 'Back down the line' giving safe driving commands to the next train/loco coming along. 

 

By setting these colour aspects, 'back down the line' we are setting safe driving conditions in Blocks 'Back down the line'. Then using LD we pre-program that any loco entering a block drives at a speed set for the Block conditions according to the signal seen by the train driver. So in effect a train can cruise to its hearts content if all signals are Green (Blocks Clear), but if Y or YY they must slow down as they are warned to do so as there may be issues ahead that cause the train to slow down further or even stop.

 

I have seen setting speeds to signal conditions in Blocks very important, hence the reason I purchased so many overr a year ago. OK we can have signals in RM and not on the layout but we will need signals to get our layouts to run effectively and realistically with LD. Controlling when a loco enters a block gives one control per sensor, but controlling the last carriage as well doubles the use we can have for each sensor, increasing the options for speed control, signal changes, playing sounds, etc.

 

[PJ_model_trains]

I'm also not sure how such a setup might work.  Normally, the primary information in a loco setup is an ID which is written to a decoder.  Clearly for a last carriage, you could assign an ID but you certainly can't write it to a non-existent decoder.  Let's just assume for now the setup can sit there with an ID assigned and not written, and also with an LD tag assigned.

 

The next thing we know we can't do is drive it anywhere - no decoder or motor is significantly limiting in this regard.  But we can put conditional instructions in sensor setups that can apply. The relevant instructions are For loco(s) and For loco type(s).

 

Yes the loco setup section is primarily for locos, but if facility is not provided in LD to read tags on last carriages and carry out the tasks mentioned above, mainly changing signals back down the line, then this is where we would have to create a group.

 

Once signals are changed back down the line as example given then LD comes into play, 

If signal Green, Block Clear do this... probably continue at cruise speed but not necessarily

If signal YY, Block ahead enter with Caution... we slow the train down according to signal conditions 

If signal Y, Block ahead enter with Extreme Caution... you need to run at a speed ready to stop before next signal.

 

The small task of last carriage, setting signals conditions, makes it so easy to control and achieve realistic speeds and stopping.

 

[PJ_model_trains]

I'm also not sure how such a setup might work.  Normally, the primary information in a loco setup is an ID which is written to a decoder.  Clearly for a last carriage, you could assign an ID but you certainly can't write it to a non-existent decoder.  Let's just assume for now the setup can sit there with an ID assigned and not written, and also with an LD tag assigned.

 

It doesn't need a decoder it is just set signals back down the line which sets Block conditions for any further loco/trains coming down the line.

 

Example - Sensor 2 was activated by (Last carriage tag 049) change signal 121 to Yellow

 

That is all that is needed, it is not until the next train passes the senor for the signal on Yellow that a speed command is issued. All last carriage tag is really needed for is to set signal aspects back down the line, so that any other train coming down the same line is warned of what is ahead by means of aspect colour = Block conditions = set this locos speed

 

[PJ_model_trains]

Am I right that one of the things you want in Desirable Features is to be able to address instructions to groups of locos?  I wasn't sure I had this right as my understanding is that this has always been possible via the loco types instruction and we've talked about addressing just such groups for ages?

 

The only reason we would need a group in loco setting is...

 

- if it is not possible to for tags to be read and signals set elsewhere in the system. We are suggesting setting uop in Loco Settings now because we cannot see where else it is accommodated for.

 

- the reason to set up a group is because it is only for basic commands, changing the signals back down the line, not for driving locos or similar.

 

The thoughts for this were also based on having groups in RM so that LD can issue instructions to groups (Not ALL Locos). At present if we gave an instruction to ALL Locos this would include ALL items with tags as they are in and setup in the loco section of RM. So with groups we could issue a command not just to Loco3, but maybe all locos in groups 1,2,3 which are loco types but not say, groups 4 and 5 which may be last carriage group or even another group where TT300 TrainTronics Actuators have been set up for example.

 

Basically if HRMS arrange two groups, in the same section maybe, one for locos as now and one for none loco items as detailed above, it would easily solve this problem, I think, and the two groups are separate as far as LD and RM are concerned. All locos commands being sent to all locos in the loco group set up.

 

[PJ_model_trains]

So I think my question is - do we need RM to have a whole new screen for setting up last carriages not being dummy locos?  Or do we need a separate category entirely in Loco Setup for them.

 

See my post above.

 

All we need, I think, is to be able to program tags to 'none-loco' items in a different group that is not affected when a command is given ALL Locos... do this or that.

 

HRMS may choose to keep things together in the LD tag set up for locos, just create another group, but in the software All Locos commands are for Loco items and not for none loco items. To me it would make sense to keep all tag related items in the same section for set up, just set up groups for each and prgram the software to look to the relevant groups when carrying out commands. All Locos being All but only Locos.

 

Discuss. 

[hosh]

Something that I think is relevent to this conversation and others, is the order of instructions at a given sensor.

 

It would seem that if you had an instruction like "For all locos do (something other than stop)" on the first line, then all other instructions below that never get read.

 

So a rule would seem to be that a sensor's task with a loco ends as soon as one of it's instructions gives a loco a speed other than zero. Any instructions after that in the list never get read.

 

So in other words we'll no doubt need to put some thought into this when writing our instructions into the sensors. All the loco specific stuff at the top, then groups, then For all locos.

[hosh]

Don't think anyone mentioned this yet.

 

So this technique involves needing double the sensors? You now not only need a sensor before each signal but another beyond each?

[PJ_model_trains]

Don't think anyone mentioned this yet.

 

So this technique involves needing double the sensors? You now not only need a sensor before each signal but another beyond each?

 

In a word... No!

 

Same amount of sensors as normal and this subject has been discussed many times.

 

1 - Set positions of Block sensors

2 - Set position of additional sensors

 

Same amount of sensors!

 

Tag detection is the only difference. Was it a loco was it a none loco tag that was read that is the only difference.

 

Locos tags - have multiple instructions as we have all discussed

None Loco tags - read from same sensors are for changing signals 'back down the line' confirming previous block conditions for any other training coming into these preceding Blocks.

 

Block clear as last carriage passes sensor/signal - set signal for Block just cleared, 1 signal back, confirming conditions for previous signal. If 4 aspect signals, set signal aspect for signal controlling block before previous one, e.g. two Blocks back.

 

[PJ_model_trains]

Don't think anyone mentioned this yet.

 

So this technique involves needing double the sensors? You now not only need a sensor before each signal but another beyond each?

 

Sensors as we know should be placed within stopping distance before a signal

 

_____[sig]___[sen]____ <<<< direction of loco

 

But if you have bi-directional traffic you will have 

 

_____[sen]___[sig]___ >>>> direction of loco

 

Signals always on left as loco approaches (cannot draw this using text symbols

 

You could have signals either side of the track but always left from the train drivers perspective. It is probable they will be offset but could be opposite each other. This raises another situation as we believe sensors will be read from left to right or right to left travel so a sensor would be read twice!!!

 

_______[>>>Sig]_[Sig<<<]___[S]____

 

The items in bold being on the left of the track <<< direction driver sees signal.

 

The question here is how far a person wants to go, how much do they want to spend to get it 'right' 

In reality most would probably do the following

 

____[>>>Sig]__[sig<<<]____

 

One sensor for both signals as close as possible together (or don't have bi-directional traffic)

 

This would still work... providing speed is reduced prior to passing over the signal e.g 10mph on run up, pass over sensor, commmand loco stop. I think this is what most may do.

 

How a loco responds going over a sensor depends on what we have programmed into the sensor.

 

>>> would have different commands to this sensor  <<<

 

Directions shown based in sensor programmed with signal close to it or as you worded paired with it. The difference I think being the same.

[PJ_model_trains]

Something that I think is relevent to this conversation and others, is the order of instructions at a given sensor.

 

It would seem that if you had an instruction like "For all locos do (something other than stop)" on the first line, then all other instructions below that never get read.

 

So a rule would seem to be that a sensor's task with a loco ends as soon as one of it's instructions gives a loco a speed other than zero. Any instructions after that in the list never get read.

 

So in other words we'll no doubt need to put some thought into this when writing our instructions into the sensors. All the loco specific stuff at the top, then groups, then For all locos.

 

Programming a sensor will be down to the user, we would prioritise the commands subject to what we want to happen based on the type of command.

 

e.g. On signal Red, On signal Yellow, etc, are specific 'On Signal do this or that' so priority wouldn't matter for these types of commands. 

 

[hosh]

Hate to be pedantic and consider the improbable, but......

 

Let's say I have a train that is slowing but the rear tag has just passed the sensor of the previous block and the train stops with the last carriage only a little beyond that sensor (in fact part of the carriage might well be physically over it). It has now declared that block as clear and so a train behind can come into it. So there is the potential for a rear ending, correct?

[hosh]

Of course, my above post refers to mono directional track which I think would be typical of most sections of most layouts.

[PJ_model_trains]

This is another reason why I believe we will put sensors as near as possible to signals, we will probably try make one sensor do where two would be better, especially with bi-directional, there will be compromises in what we do.

 

Each person will know where is the best place to put their sensors, before turn outs, after turn-outs, we can list lots of negative considerations for almost every situation, every layout is different, we will all have different aims. LD is to 'help simulate' real life railway, LD is a marvellous idea I think but it is not GPS.

 

GPS knows where every train is and when the Block has been cleared by the last carriage passing the signal. I do not see what you suggest as a problem, if it was to be categorised ass a problem I think ths would be minute. Keep signal and sensors close but, control speed in the run up to them, last carriage tags increase our chance to do this.

 

Last carriage tags not only tell us a Block has cleared they also give us chance to alter signals back down the line in a realistic manner, not wait whilst the train enters another block (which could be as you say running slow) to do so. They give us better control, faster control and as a result help us to alter speeds of other locos approach blocks faster.

 

[Howbi]

As a matter of interest, have you noticed that in the graphics on screen currently available in track planner there is no provision for entering the Tag #, only the port #........I think the missing component will appear on screen when a new Loco Detection Module is connected to the PC whereby the Tag# will be associated with it's Port# and possibly the loco address it is fitted to.........If the tag is fitted to last carriage the loco address would probably be 0000 to indicate 'no decoder' but there would have to be a visual record somewhere for us to know which loco was attached to which tag# and Port# bearing in mind that you can only enter the port # when entering the LD sensor settings box and then the loco ID further down in the commands table.   HB.

/media/tinymce_upload/62e91e4f16cb797cb38307eadf7cf61c.png

[PJ_model_trains]

Hate to be pedantic and consider the improbable, but......

 

Let's say I have a train that is slowing but the rear tag has just passed the sensor of the previous block and the train stops with the last carriage only a little beyond that sensor (in fact part of the carriage might well be physically over it). It has now declared that block as clear and so a train behind can come into it. So there is the potential for a rear ending, correct?

 

Why so negative all the time hosh? I can reverse what you say and say, look how long it takes for a very slow running loco to clear the block, therefore all that time is wasted waiting unable to change signals back down the line until the front end goes into another block. Meanwhile a faster loco could be moving towards the slow running one and has no idea of Y or YY conditions as the signals didn't change when the last carriage cleared the block. So he is cruising at 65-70mph or more and the next signal is STOP!!!

 

Tags on last carriages allow us to confirm Block changes faster and warn oncoming trains of driving conditions in a block much faster and sooner and in a more realistic way.

 

[PJ_model_trains]

Of course, my above post refers to mono directional track which I think would be typical of most sections of most layouts.

 

Could be hosh, but not all, I for one will be running bi-directional, you for another have said you were considering it, there could be more than we maybe think.

 

I agree it is a bigger challenge but I consider it just another challenge  ;o)

 

[PJ_model_trains]

As a matter of interest, have you noticed that in the graphics on screen currently available in track planner there is no provision for entering the Tag #, only the port #........I think the missing component will appear on screen when a new Loco Detection Module is connected to the PC whereby the Tag# will be associated with it's Port# and possibly the loco address it is fitted to.........If the tag is fitted to last carriage the loco address would probably be 0000 to indicate 'no decoder' but there would have to be a visual record somewhere for us to know which loco was attached to which tag# and Port# bearing in mind that you can only enter the port # when entering the LD sensor settings box and then the loco ID further down in the commands table.   HB.

 

Interesting HB, I hadn't seen it.

 

I think there are a few items we cannot see and won't be able to until LD is installed and connected to talk with RM.

 

In the image in your post there are For Loco(s): and For Train type(s): there could easily be for none Loco/Train typed e.g. for last carriage tags. (Train types is interesting)

 

As mentioned earlier, last carriage tags would only really be for changing signals back down the line so loco address and similar will not apply, only signals calling/setting colour aspects so as to control driving speeds in blocks according to signal aspect colour (or flashing colour)

 

A new group could easily be created for none loco items, the variables in that group can easily be specified, being different to those for locos, calling signal colour aspects can be done now in programs so that is also easy for HRMS to do. 

 

Now if we look further with this there is one other consideration... not changing aspects bak down the line that have just been changed by another loco to RED. (Common on loops) But as stated in previous discussions this can easily be got round with the IF/THEN/ELSE commands.  

 

Say we request Signal 105 Yellow. Using a loop command RM could then consider...

 

IF Red - THEN do nothing - ELSE Yellow it will work no problem.

 

[hosh]

Of course, my above post refers to mono directional track which I think would be typical of most sections of most layouts.

 

Could be hosh, but not all, I for one will be running bi-directional, you for another have said you were considering it, there could be more than we maybe think.

 

I agree it is a bigger challenge but I consider it just another challenge  ;o)

 

 

I guess it would be possible to have an entire layout without the need to even reverse at all and with no reverse loops either.

 

But end to end layouts certainly aren't like that, and anywhere there a bump stops you'll have reversing also.

 

Again, the point I was making is that on most layouts, most of the time, travel will be mono directional, so the luxury of using a sensor on the other side of a set of points for example, won't always be in play.

[PJ_model_trains]

Hi HB, I thought I had replied to this but think it must had logged out, maybe held for image if clicked Quote, not sure!!!

 

I hadn't noticed this as my layout is down at present, but I do agree somethings will not be fully notied until we have LD installed and it is connected to RM.

 

By HRMS creating a new group for not loco items this would not be the case, only variables for set signal to x aspect will be included for tags in that group.

 

In the image from RM it shows 'For loco(s):' and 'For train type(s): 

I assume these are for Locos generally and for train types listed in the groups we can already set.

 

All they need is a new group, None Loco items, and the variables for setting signal aspects.

I am not sure what would be needed for allowing items like TrainTronics Actuators or similar but I am sure this could accommodated for. Some members have alreaady set these up in loco settings and I am considering it myself.

 

Having said that there are many ways they could do it they could nul or nulify some commands in a group but adding a new none loco group makes sense to me. Keep it simple. ;o)

 

[Fishmanoz]

HB, when you say tag #, I'm assuming you don't mean loco tag?  No loco tag info will be in here.  Loco tag info goes in the loco setup screen, not the sensor setup box.

 

If you actually mean sensor #, then that is the port number.  Haven't checked but presumably for Device No 1 (LDM 1) you'll get port options of 1-48, and for LDM 2, you'll get 49-96.

[Fishmanoz]

Having just installed rev 4, I checked my assumption above and not true.  Port number is 1-48 for both LDM 1 and 2.

 

One thing I found though that I had either forgotten or is relatively new - on switching a point or a signal, you can run a program.  I can remember something vague about this, I think, that there may be an issue with whether to program initiates only on manual switching, not by switching from a program.  Begs the question, what about from a sensor instruction too?

 

Ray, maybe you know more about the above?

[RDS]

... whether to program initiates only on manual switching, not by switching from a program ...

 

Is that because only one program can be run at once?

[PJ_model_trains]

@HRMS

 

When I posted the comments on here following Fishy starting this thread, which I think was a good idea as it keeps these items all in one place, I didn't at that time have access to the PC that I run RM from. Although I don't have my layout down now I do have access to RM so sum up or bring together what I was aiming to say earlier.

 

LD will as we know send data back to RM for every tag passed over, initially assuming tags are only placed on locos, as all varaibles will have been programmed for these types, whether they are, Express, Branch, Goods, Maintenance or Shunter, commands will be sent back to RM confirming Sensor ID and Loco Tag ID fo RM to process according to the way it has been programmed by us and by HRMS.

 

All this is very good as discussed elsewhere in the RM forum but, a loco can pass a sensor and change the signal Red, in effect protecting the Block the loco has entered, but if this is a slow running train or just a slow running loco it can take time for the loco to reach the next sensor. Once the loco has passed the first sensor and protected the Block the loco has entered nothing else can happens until the loco reaches the next sensor.

 

But the Block immediately preceeding the Red signal may be clear and another train/loco may have entered that Block at top speed not knowing the next signal is Red, not being warned by a Yellow, Yellow-Yellow, or Flashing signal. The next thing to happen would be the train/loco reaches the next sensor, the signal still Red and has to Stop!  At top speed!!!

 

We know that mainline railway uses GPS which knows where the train is, but also knows when the last carriage has passed the Red signal and can as a result change signals back down the line to Clear or Warning Aspects subject to Block conditions (how close a Block is to the Red signal they are approaching)

 

Now if LD doesn't allow provision of tags on last carriage as discussed we can as discussed probably do this through the Loco Groups by listing, All last carriages, here and hopefully in a separate group, e.g. last carriage, brake carriages, last wagons and guards vans in the Loco section all of which have a (last carriage) tag on them. The advantage of using last carriage tags is that as soon as the last carriage passes over the sensor the loco passed over and turned the signal aspect Red, the last carriage then commands the aspect of prevous signals to change according to Block conditions. Previous signal ### change to Yellow, telling train driver to enter that Block with Extreme Caution, in other words the next signal is probably Red... be ready to Stop. Or the previous signal back one more to Yellow/Yellow, telling the train driver to proceed into that Block with Caution, meaning start to slow down the next signal may be Yellow. 

 

The last carriage tag allows us to control Block conditions, back down the line, 'as soon as the last carriage clears the Block' the Loco entered. Simulating what happens on mainline railway. The importance being that as soon as a Block is cleared previous Blocks are brought up to date immediately. This means as another train or loco approaches a Block, it know immediately, there are clear or warning instructions for him. We will have pre-programmed every signal to know what to do, if the sensor they pass, which communicated with the signal adjacent to it, or paired with it, is Clear (probably continue at cruise or what ever speed running at), or Yellow/Yellow Aspect (we would reduce speed knowing the next signal could be Yellow say 40mph), or Yellow Aspect (we would reduce speed knowiing the next signal could be Red/Stop)

 

By controlling Blocks back down the line (as soon as a last carriage passes) we are able to drive according to Block conditions, reduce speeds realistically, stop at a red signal, etc, all done as quickly as possible because we know when the Blocks were cleared the commands are carried out immediately and without delay.

 

The next consideration is how it is done, this is down to HRMS. They may choose to control this separately in a separate section in RM, they may choose to have a, none loco group, in the loco settings for these last tag commands. Last carriage Tags will only command signals to change back down the line, they will not have or need the same variables as the Locos. 

 

Currently Loco Groups are set up as Express, Branch, Goods, Maintenance or Shunter but in this section we already have 'Add New Group' this could be for Last Carriage tags. We set the Groups in Loco settings but control groups from the layout design tag settings. HRMS may already have this in hand ;o)

 

Having considered driving locos to Block conditions using signal aspects after last carriage tag detection, and having discussed Groups, including the option of adding a 'new group' for 'Last Carriage' tagged stock, there is just the one other consideration, changing signals, back down the line, to any aspect other than Red. We cannot allow a signal to change to G, Y or YY that a loco has just passed and turned to Red. This can easily be got round by adding an IF/THEN/ELSE loop as mention further back in this thread.

 

The result would be...

All tags for locos will be controlled using commands as listed in the sensor detection command section in layout design now. We should be able to send commands for specific locos, or loco groups, which in effect sending to groups and naming them we avoid the 'lasat carriage' group.

 

But last carriage tags variables will be different from those for locos. They will only control signals back down the line.

 

So it makes sense that HRMS would create a new group, however they do it, just for Last Carriage tags. This group would allow us to 'set' signal aspects back down the line for previous Blocks. As a separate Group with separate commands, there will be no conflict with loco groups, providing we cannot change a signal that is Red. By adding a simple loop in 'this Group only' that says after an aspect is called...

IF signal we are requesting to change to (Y,YY or G) aspect is Red - THEN leave Red - ELSE change aspect to what we requested Yellow, Yellow/Yellow or Green.  This option would not be needed in Loco commands only in last carriage, call aspect commands only for Back Down the Line signal asppect changes.

 

The only other time this IF/THEN/ELSE may be useful is in Programming Routes, again when we 'call aspects' but this is another issue, it could easily be considered later. We are more likely to use these change signal aspects back down the line commands with Loco Detection sensors than in programs.

 

These are my thoughts pulling everything together. If I have missed something please comment. LD looks like being a great system, with last carriage tag control it takes it a step further than Block Detection. It not only enhances the way we control our trains but helps bring LD forward which in trun sould help it to become a market leader. Me thinks ;o)

 

[Howbi]

@PJ...............You are making LD sound so complicated that you are in danger of discouraging anyone from investing in it..........If you want to run a train schedule on your model with 2 or more trains on the same track then just do it and fit tags to last carriage or truck and program as appropriate to change signals etc but I doubt many will do the same as most layouts are not large enough...........what's better than having the up line and down line running with a bit of shunting in the stock yard while a suburban service ambles from end to end..............I fear you will spend more time trying to make LD work your prescribed way rather than actually operating your model railway...:o)  HB.