Last Carriage Detections by LD

[Fishmanoz]

PJ, am I right that in loco groups under Other, you can set up as many other groups as you want?  If so, then make one of these other groups the LC Group.  Now set up all of your last carriages as dummy locos and put them in the LC Group.

 

Then you've asked for If/Then/Else commands.  Sensor instructions don't currently have such a format but they do have For commands, including For loco group(s).  So it seems to me all you need is something of the format of For THIS, Do this, For THAT do that.  If THIS and THAT cover everything between them, it's exactly the same as If/Then/Else?  Making these specific to what you want, we get:

 

For Loco Group(s)

Set signal R

For LC Group

Set  signal Y

 

Does that achieve what you want without any new capability or instructions?

 

Is that simple enough for people to buy HB?

[Howbi]

Frankly, Fishy, no........why complicate things further introducing Loco Goups and LC Groups......why can't a last carriage Tag simply activate sensor commands at each sensor as planned...........each LC tag could be assigned to Loco 0000 which RM already knows? then every LC tag would behave the same at that particular sensor to set signals behind as required.  HB.

[PJ_model_trains]

@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.

 

Hi HB

 

If you are thinking it makes things more complicated you are not understanding what I am actually explaining.

 

Once signals are programmed to respond to a last carriage you need do nothing else. So long as RM includes provision for not changing a red signal to another aspect then once set is is 'automatic'.  It really is very simple and will make running locos even easier and more realistic.

 

[PJ_model_trains]

PJ, am I right that in loco groups under other, you can set up as many other groups as you want?  If so, then make one of these other groups the LC Group.  Now set up all of your last carriages as dummy locos and put them in the LC Group.

 

Hi Fishy, it would appear there is/will be facility to add another group in the Loco set up section. Take a look and see what you think.

 

If so then yes we could set up a section for 'Last Carriage Tag' items (our description). 

 

But we don't know at this stage how HRMS may deal with this. There are two options

1 - Let us create a group and allocate a section of ID's for last carriage tags.

2 - HRMS create a group for us and in that group only allow us to program commands for signal aspects

 

Option-1 means that the group would have the same variables as Loco's although some would work and some not.

Option-2 means HRMS are in control of the software, but even better they set up this specific group (In Loco settings) and they set the variables allowing us to set signal aspect back down the line. Signal Port call colour. HRMS then build into the software, in this group, the IF/THEN/ELSE to prevent Red aspects from being changed by this group. 

 

So yes we could create a group, but it would be harder. I think to add the IF/THEN/ELSE in with the loco variables, but very easy if the group was a separate group.

 

So is it complicated, No?  But I feel it best that a group is set up by HRMS in RM. What is involved...

 

Create a new group for last carriage tags (in Loco settings)

 

HRMS program the group so we can only call colour aspects back down the line depending on type of signals installed.

 

HRMS set the small number of variables needed; we program a Tag to alter signals back down the line calling the aspect we require for our signals. That it as far as the tag/signal aspect setup goes.

 

HRMS build in to these commands the IF/THEN/ELSE to stop Red signals from changing.

 

Would it make RM and LD more complicated... Certainly not... It would make it simpler for the Hornby and simpler for the user.....

 

[PJ_model_trains]

(Continued)

Would it make RM and LD more complicated... Certainly not... It would make it simpler for the Hornby and simpler for the user.

 

Why, because the last carriage tags are in 'their own group' with 'their own variables' and the IF/THEN/ELSE is only used for this group. No chance of Loco variable conflicting with Last Carriage Tags, no chance of Last Carriage Tags conflicting with Loco settings, No chance of us setting wrong commands there are so few to set, Y, YY or G, and with the safety net on the end, no change of Red aspects being changed in error. 

 

How much work is involved for RM? Setting up a new group, with specific variables and the IF/THEN/ELSE

 

How much work is there for us? With the group set up we assign last carriage tags to that group. We pre-program sensors for the last carriage tags to change signal back down the line to the aspects we want them to set, the signal port and aspect colour.

 

That's it! A last carriage passed over sensor, tag is read and tag ID and sensor ID sent to RM. RM looks up tag is in Last carriage group, what were pre-programmed instructions? Change signal one block back to Yellow, change signal two blocks back to Yellow-Yellow, change signal 3 blocks back to Green/Clear. Software automatically carries out these commands but checks if signal Red it doesn't change it. 

 

[PJ_model_trains]

(Continued)

So far we are thinking on the grounds of Blocks back down the line on the current track but, we also have Blocks from the main line to a secondary line or from secondary to main line. We need to change signals back down the line but, we don't want Red aspects changing. Doing these things manually would be a nightmare, mistakes will be made, crashes will occur. But, letting the software do it all for us 'automatically' when we set up a few pre-program commands means the software is in control and running our trains will be so much easier.

 

This is not new we have been talking signals back down the line for at least a year as you know.

 

Let the software do the work, that is what it is all about. Is it a big job for HRMS, I do not believe it is, I also believe having a separate Group for Last Carriage Tags is not only easier for HRMS to program it is also easier for them to control and add the IF/THEN/ELSE to make sure Red signals are not changes and not have conflicts in the system.

 

I have not spoke to Ray since before Christmas it will be interesting to get his comments on this too.

 

[PJ_model_trains]

Sorry for 3 messages above, initially there was one held for profanity?

I split the message and sent in bits so as to chase out the issue. 

Seems it may not have like the two words V-V meaning alternating from main line to secondary line and the opposite. Once I removed those two words it accepted the post!

 

[hosh]

You are saying that you don't want this to change Reds?

 

I thought that was the whole point? A train takes off, I guess it changes to red just after the loco takes off, it's last carriage moves across the sensor and it now changes that signal from red to whatever.

 

Correct?

[PJ_model_trains]

You are saying that you don't want this to change Reds?

 

I thought that was the whole point? A train takes off, I guess it changes to red just after the loco takes off, it's last carriage moves across the sensor and it now changes that signal from red to whatever.

 

Correct?

 

Incorrect understanding of what I am saying hosh, sorry if I am not making the point clear, allow me to try again another way.

 

What I said, am saying is...

 

 

A new group - ONLY for 'Last Carriage Tags' - and ONLY for changing signal aspects 'Back Down the Line' 

 

It is Nothing to do with tags read on locos that control locos and many other items. See these as two separate items doing different tasks. Front end Loco, Back end Last carriage.

 

This is why this group would best as a separate group, it can be set up in Locos as a group and that group would relate to specific commands, simply change signals back down the line to Y, YY or G depending on signal type. Specifically for back down the line signalling but with programmed software so that there are No changes to the Red aspect signal. Note again this group only, Last Carriage Group.

 

Changing back down the line is DIFFERENT to Loco tags. It is nothing to do with Stopping or Starting Locos, it is nothing to do with Loco acceleration or deceleration, it is NOTHING to do with LOCOS. Its only tasks are thos above.

 

It is an last carriage detection, soley for changing signals back down the line to command signal aspects and set Block Conditions --- Nothing else.

 

You will still have all the variables for controlling, stopping and restarting locos, using the tags on Loco's as previously discussed.

 

The sum up, we would have tags that we can put on Locos or last carraiges

 

Tags on Locos control Locos and everything in the LD Sensor now in Layout Design. With Loco Tags (not last carriage tags you can as we all been discusseing restart a loco from another Loco sensor' (but not a last carriage sensor)

 

Tags on last carriages would be a separate group, with its own varaibles, its ONLY task is to set signals back down the line (without changing aspects which are Red).   Because the Front end! The Loco changes signals Red (not the back end) as it passes over a sensor, passes an adjacent signal and enters a new Block. 

 

[PJ_model_trains]

Dear hosh, just to confirm, I wasn't shouting, just hilighting parts to try explain better.  ;o)

[PJ_model_trains]

Duplicated message!

[hosh]

need to change signals back down the line but, we don't want Red aspects changing. Doing these things manually would be a nightmare, mistakes will be made, crashes will occur. But, letting the software do it all for us 'automatically' when we set up a few pre-program commands means the software is in control and running our trains will be so much easier.

 

If you don't change reds, then how do you get to Y, YY and G?

[Fishmanoz]

Hosh, this is a discussion of last carriages.  They don't change the signals to red, the locos do when they enter a block.  Last carriages indicate the block is clear so they clear the signals.

[hosh]

Yes, but it seems what PJ is saying is that he dosn't want to change a Red to something else. Thus, how do you get to anything else in the first place?

 

My understanding is that the tag will trigger the sensor, thus setting that block as now clear, thus setting the signal another block back to something other than Red.

[hosh]

Btw, how is a lot of this different to pages 82-84 of the pdf?

 

Don't you simply need the tag on the last to tell the next signal back to change to YY? And then the rest happens automatically?

 

Unless I'm mssing something, all that you want to do is already in RM.

[Fishmanoz]

If I can take the liberty of interpreting PJ for you, I think you and he are saying the same.  When he says he doesn't want to change Reds, he means any reds other than on the signal linked to the sensor where the last detection has just occurred.  Does that make it clearer.

 

And is it available with current capability?  I think it is, PJ not so sure.  My interpretation relies on setting up dummy locos for last carriages (they each have to have their own "loco" ID and a tag number allocated to them - which answers an earlier query from HB), then putting them in an LC Group, then being able to have an instruction For LC Group, so you can clear signals for that group only (doesn't have to only clear signals as PJ suggests, even if we have no ther application for the Group yet).

[PJ_model_trains]

hosh

Before I move to the next comment...  start to look at what happens when tags are detected in the following way...

 

TAGS

1 - Tags on Locos - control what happens when a Loco passes over a sensor and the Loco enters a new Block

 

2 - Tags on Last Carriages - control what happens when the last carriage enters the Block the Loco is in and the previous occupied Block becomes Clear.

 

The one on the front controls what happens as a Loco enters a new Block [it protects that Block]

The one on the last carriage controls what happens as previous block is cleared. It sets new Block conditions back down the line by setting signal aspects.

 

CAUTION

The problem we have to be careful with, no matter how big or how small a layout is, setting signals back down the line (Y,YY orG) could turn a Red signal Stop (which a loco just passed to protect a Block) to another aspect therefore removing the Stop command.

 

NOTE: This is not an issue for signal commands generaly, Only when changing back down the line. By Hornby programming in the IF/THEN/ELSE loop for these changes would prevent a Red aspect changing to any other aspect and when programmed into the software will be automatical for any back down the line aspect change commands.

 

Think 2 tags --- Think what happens at the front --- Think what happens at the back.

 

It is as easy as that but, I do have a reply to do for Fishy which will follow shortly.

 

[PJ_model_trains]

@HRMS  @Fishmanoz

And is it available with current capability?  I think it is, PJ not so sure.  My interpretation relies on setting up dummy locos for last carriages (they each have to have their own "loco" ID and a tag number allocated to them - which answers an earlier query from HB), then putting them in an LC Group, then being able to have an instruction For LC Group, so you can clear signals for that group only (doesn't have to only clear signals as PJ suggests, even if we have no ther application for the Group yet).

 

In the small hours when I couldn't sleep due to pain which is usually every night, I start to think as it takes my mind of the pain but then I lay awake for several hours. Last night, though a bad night, was a good one in another sense, I thought of another situation which changes yesterdays comments slightly although the main issues for back down the line signals remains the same.

 

Yesterday I suggested that 'Last Carriage Tags' be in a separate group with their own variables for signal aspect changes back down the line only. This cannot happen as I will explain, they will need to include ALL the main Loco variables and a few extras. I will try explain a different way including a different scenario that shows they must have all Loco tag variables but also need a few extra ones.

 

EXAMPLE

We have been considering Loco, carriage, carriage, last carriage, with a tag on the Loco and a Tag on the Last Carriage

 

We have been considering the Loco at the front end going forwards but, this will not always be the case.

 

L=Loco

C=Carriage

LC=Last Carriage but I think it may be better called the 'End Carriage'

 

Take this example first...

______L-C-C-LC_____ <<< direction of travel

 

On a Left/Right, East/West type layout going from East to West would be as above but going West to East could be... (same train going back)

______L-C-C-LC_____ >>> direction of travel

 

The Last Carriage is no longer the last carriage it is the first Tag read!!! Hence the term maybe best not as Last Carriage as we have called it for twelve months but 'End Carriage'. As it is at the oppositeend to the Loco.

 

This changes only one item, Tags for 'End Carriages' so it cannot be as discussed yesterday with a separate group of variables for changing signal aspects only back down the line to set Block conditions. It can be another as discussed below, but it must have all the variables the Loco had as it is the 'Leading Tag'.

(cont...)

 

[PJ_model_trains]

@HRMS  @Fishmanoz

 

Now we could say what about the commands for signals already in the LD section will they work for back down the line. No! But, with the addition of a few commands in this group it can easily work.

 

We have in the LD commands for signals now...

On signal yellow

On signal double yellow

On signal flashing yellow

On signal flashing double

On signal flashing green

On signal green

On signal red

 

All the above are related to how the Loco reacts to signals already set. (whether or not the loco is at the front or the rear of the train doesn't matter). There are different signals going East to West than those going West to East (signals are always on the left as the driver views them) and each is programmed separately by us. So when pulling forward the loco leads and gets the commands, when pushing the carriages the other way the 'End Carriage' tag is detected first and gives commands to the loco at the other end as if it was at the front. So this confirms Loco Tags are required for 'End Carriage' tags. But in themselves they are not sufficient for back down the light signal changes for setting Block conditions.

 

We definitely appear to be moving forward, I think, it would also appear that HRMS may have considered 'End Carriage' tags and if the loco is on the rear pushing the carriages the tag on the end carriage is detected first and can give commands as if the loco was on the front. So from that perspective the commands are already there, 'End Carriage' tags may be catered for in part.

 

I have just been into Loco settings set up and in there created a New Group called 'End Carriages', first I have to add a loco, any loco, then edit it changing the name to 'End Carriages' and give it a new image. You have to set cruise and shunt speeds but these will not be used so you could add any speed here. It does however add this to our loco list on the right of the screen in RM, so I set the Locomotive DCC ID to 99 so it was at the bottom of the list, but HRMS could include a Hide button so this item doesn't show on screen.

 

What additional commands could be needed them?

 

Changing aspects back down the line is different to, On Signal, do this or that, which are included in the list in LD, those included are for when a Loco passes over a sensor when the signal aspect is R, Y, YY, G.

 

When we change signals back down the line we don't do something based on the aspect we SET the aspect, or best said reset the aspect. So in effect we are saying... Signal ### Set Yellow (Y, YY or G).  By re-setting a signal we are over-riding its current aspect which is where the changing Red issue is still an issue.

 

So as I am seeing it the list in LD sensor is fine but needs a few additions...

End Set signal yellow

End Set signal double yellow

End Set signal flashing yellow

End Set signal flashing double

End Set signal flashing green

End Set signal green

 

Finally these new 'End' commands, specifically for End Carriages, which ReSET signals back down the line, need the IF/THEN/ELSE loop to make sure no Red signal is changed.

 

Looking back, we can create groups for end carriage tags now in loco settings. ;o)

 

We already have signal aspects in LD set up for 'On Signal aspect' do as programmed. ;o)

 

We can already create a new group in Loco settings for 'End Carriages'   ;o)

 

All we need are commands to SET signal aspects, back down the line, with the safety net, IF/THEN/ELSE loop (for these only), pre-programmed by HRMS, so that RM doesn't change the RED aspect signal to any other aspect and allow locos to move that shouldn't move.

 

Note: this loop check of not changing a Red aspect signal is Only when 'Re-Setting' signals 'back down the line' to create Block conditions, which in turn through RM means we will be able to set the speed of any or all locos according to the aspect for the specific Block using the initial commands already in LD sensor settings... On signal colour do this. ;o)

 

Discuss

[Fishmanoz]

PJ, I don't seem to have explained why we don't need instructions of the form If/Then/Else because in fact we already have them, so let me try again.

 

Breaking the sequence down, let's just look at If/Then and it say If THIS, Then do this.  But "For THIS, Do this" achieves exactly the same logic, just different words.

 

Now ELSE means Else, do that.  Again, it is exactly the same logic as For THAT, do that.  You n fact, it does everything ELSE can do, then some. We could also have For SOMETHING ELSE, do something else, and so on.

 

So can you see they are the same?

[Fishmanoz]

I also believe your last carriage arriving first can be catered for by adding instructions For forward direction when the loco arrives first, and For reverse direction, when the last carriage arrives first.  Would take some thinking through the actual logic, just a suggestion for consideration now.

 

So I still believe what you want can be achieved without any additional capability or instructions in RM.

[PJ_model_trains]

Hi Fishy

 

I will ponder the If/Then/Else example you gave above with a clear head and less tired one I think.

 

The one worry I have is that RM must not changing a Red aspect when changing signals back down the line. This one procedure if not adequately covered could literally mess up all the other good work. Automation of back down the line without the risk of Red aspect changing is so important.

 

Can you at this time give an example how it could be covered?

 

_[s4]_L-C-C-EC_[s3]_______[s2]_______[s1]________[s0]_

<<< direction of travel (signals would have been on left not possible as text)

 

End carriage [EC] has just passed [s3]

 

We want to change signal adj [s1] to Yellow 

 

At present Set commands only include 

Set clear signal

Set danger signal

 

But let us say we have the additional commands and have pre-programmed - Set Yellow, Yellow-Yellow or Green/Clear - back down the line

 

So we request - Signal adj [s2] - Set Yellow

We also request Signal adj [s1] - Set Yellow-Yellow

and Signal adj [s0] - Set Green/Clear

 

But another train is coming along/or branching on to this line and has changed [s0] to Red 

This could have been the signal adj [s1] or [s0] protecting the Blocks ahead of them

 

How do we stop the signal from being changed from Red/Stop with the 'back down the line' Signal Commands?

 

The command back down the line wants to change the signal to Green/Clear, we must have it stay Red.

 

[hosh]

TAGS

1 - Tags on Locos - control what happens when a Loco passes over a sensor and the Loco enters a new Block

2 - Tags on Last Carriages - control what happens when the last carriage enters the Block the Loco is in and the previous occupied Block becomes Clear.

 

The one on the front controls what happens as a Loco enters a new Block [it protects that Block]

The one on the last carriage controls what happens as previous block is cleared. It sets new Block conditions back down the line by setting signal aspects.

 

 

The front tag will no longer play any role in signal setting at all will it? (apart from trains in reverse in which case the loco and last tag swap roles) 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. Although, it is actually required that the block ahead should be set as occupied as soon as a loco is sent away from the previous block for obvious reasons, so I guess the last tag only clears the previous block.

 

You simply only instruct signals behind you, not the one the front of the train is approaching of course. It would be my thinking to set the just left block to red and let RM do the rest as per pages 82-84.

 

The only thing I can see that you need is a group to simply save you needing to specify every single last tag at every sensor.

[PJ_model_trains]

@hosh

The front tag will no longer play any role in signal setting at all will it? (apart from trains in reverse in which case the loco and last tag swap roles)

 

The front tag will always play a role, whether it be the loco or the End Carriage.

 

It is not as it approaches a sensor, but as it passes over a sensor, at that stage its roll it to change the signal adjacent to the sensor it has passed over to protect the Block it has just entered.

 

[hosh]

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.