Last Carriage Detections by LD

[hosh]

I think you need to re-read my post. :)

[hosh]

Here's a question for you.

 

If a loco normally has a tag on the last carriage of it's train, but is now running on it's own, how does it then know to set signals only with the loco tag? I guess you just never run such locos on their own?

 

So it would seem that with the last tag system that you either run locos always on their own or always pulling carriages with a tag at the end?

[PJ_model_trains]

It is your system hosh

You designed it

You set the routes

You decided what was being pulled (or pushed)

You decided what goes from A to B

You set the programming to suit these needs... your needs

So you choose 

 

You must also always know which carriage/wagon/guards van has the tag fitted.

You could have a rake of coaches with a tag either end! and on the loco!

All tags will be read but only tags you program with carry out tasks

 

If you have a East to West layout you will go one way or the other so you would program tags according to your layout, your routes.

 

e.g. LocoTag1 --- carriage 1 Tag11, others no tags, opposite end carriage Tag21

In your programming you will give commands for the loco direction <<<

In your programming you will give commands for last carriage direction <<<

In your programming you will give commands for the loco direction >>>

In your programming you will give commands for last carriage direction >>>

 

For direction <<< you will have programmed locoTag1 and carriage Tag21

For direction >> you will have programmed locoTag1 and carriage Tag11

 

Option 1 direction <<< the loco Tag is read first and the carriage Tag21 read last

Option 2 direction >>> the carriage Tag 11 is read first and the loco Tag1 read last

 

It doesn't matter about the other tag as there is no instructions programmed for the direction of travel

 

Tags will always be read but the only ones carried out are the ones with program instruction (here programmed considering direction of travel, it doesn't matter if the loco is forward or reverse, the direction of travel is East to West or West to East.

 

A loco may go east to west, drop off its carraiges, go on the turn table, pick up the carriages the other end than return.

 

It doesn't matter RM with LD is processing tags read and carrying out instructions we pre-programmed. We pre-programmed because we know the stock and the routes and programmed accordingly.

 

That is how I am seeing it at present, if others see things differently please say so.

 

It is reading tags and processing commands, in the order received, whichever way we run our loco and carriages or wagons.

 

[Slornie]

Following this discussion, and I think earlier incarnations in related threads, I find myself thinking that maybe HRMS ought to add a section to the loco control panel where a user can select the appropriate "end" of the "train" (vs loco) from the list of available programmed tags.  The tag assigned to the loco itself will normally represent one end, and then the other end would selected or changed on a case by case basis as and when the loco is coupled or uncoupled from rolling stock.  If no end tag selected the loco tag would naturally represent both ends.

 

So in the example case of loco [tag1] carriage [tag7] carriage carriage carriage carriage [tag4], in the loco panel you just select carriage [tag4] as the "end" of your train.  Were the loco later switched to the other end of the same carriage rake the selected "end" in the control panel would be changed to carriage [tag7].  Any other tags that happen to be within the train would not trigger signal changes on detection at sensors because, at that moment in time, they don't represent an "end" (but could still allow any other programmed non-signal instructions).

 

Of course, functionality such as that would probably then necessitate additional programmable instructions for changing the selected "end" to enable full automation of things like your concluding example of "loco leaves carriages, runs onto turntable, turns around, connects onto the other end of carriages for return trip".

 

I'm also not sure whether direction would need to be defined in context of the loco's forward/reverse for something like this to work, such that sensors could identify whether, on detection, the tag should be treated as "front" or "back" for programmed instructions (i.e. whether it triggers setting the signal protecting the new block to Red or changing the signal protecting the previous block to Amber1).

[Fishmanoz]

Hosh, you don't actually need to know if a loco has a carriage in the LC group behind it.  If it does, it will clear the signal just passed by the loco.  If it doesn't, the loco itself will clear the signal when it reaches the next sensor and sets its signal to red.

 

If you want to take account of tags on first and last carriages, you can do so by setting them up as dummy locos in 2 separate groups.  Last carriages go in LC group while first go in FC group.  Now, to account for them on detection, you will have to run a program where you set initial conditions before you run the train.  That is if your brain doesn't freeze over first.

[hosh]

Hosh, you don't actually need to know if a loco has a carriage in the LC group behind it.  If it does, it will clear the signal just passed by the loco.  If it doesn't, the loco itself will clear the signal when it reaches the next sensor and sets its signal to red.

 

 

So you are saying that when you do signalling, that you will repeat the same instructions for the loco tag as was done for the last tag? Not a bad idea I suppose.

 

 

If you want to take account of tags on first and last carriages, you can do so by setting them up as dummy locos in 2 separate groups.  Last carriages go in LC group while first go in FC group.  Now, to account for them on detection, you will have to run a program where you set initial conditions before you run the train.  That is if your brain doesn't freeze over first.

 

Doesn't what I wrote above already solve this?

 

By FC do you mean the loco itself or are we talking about either end of a set of carriages?

[PJ_model_trains]

Following this discussion, and I think earlier incarnations in related threads, I find myself thinking that maybe HRMS ought to add a section to the loco control panel where a user can select the appropriate "end" of the "train" (vs loco) from the list of available programmed tags.  The tag assigned to the loco itself will normally represent one end, and then the other end would selected or changed on a case by case basis as and when the loco is coupled or uncoupled from rolling stock.  If no end tag selected the loco tag would naturally represent both ends.

 

So in the example case of loco [tag1] carriage [tag7] carriage carriage carriage carriage [tag4], in the loco panel you just select carriage [tag4] as the "end" of your train.  Were the loco later switched to the other end of the same carriage rake the selected "end" in the control panel would be changed to carriage [tag7].  Any other tags that happen to be within the train would not trigger signal changes on detection at sensors because, at that moment in time, they don't represent an "end" (but could still allow any other programmed non-signal instructions).

 

Of course, functionality such as that would probably then necessitate additional programmable instructions for changing the selected "end" to enable full automation of things like your concluding example of "loco leaves carriages, runs onto turntable, turns around, connects onto the other end of carriages for return trip".

 

I'm also not sure whether direction would need to be defined in context of the loco's forward/reverse for something like this to work, such that sensors could identify whether, on detection, the tag should be treated as "front" or "back" for programmed instructions (i.e. whether it triggers setting the signal protecting the new block to Red or changing the signal protecting the previous block to Amber1).

 

Hi Slornie

 

We expect to set up End Carriages in the loco section. So that would be correct for whichever end thay may be, we  could set one group up for all End Carriages, or as Fishy stated we could set up Two groups one for one end and one for the other. I guess this may depend on how many End Carriages we have or whether we may find it confusing remembering which end is which, we may have many, we may have reverse loops, etc. Which ever doesn't really matter I don't think, the main thing is having a group for end carriages that suits our needs.

 

I agree if we have Loco [tag1], Carriage [tag7], carriage(s), carriage [tag4]

When travelling <<< tags would be programmed for Loco [tag1], end carriage [tag4]

 

If travelling >>> tags would be programmed for, end carriage [tag4], loco [tag1]

 

If the carraiges remained the same and the loco was on the other end

If travelling >>> tags would be programmed for, loco [tag1], carriage [tag7]

 

In each case the sensor will detect loco [tag1], carriage [tags 4 & 7] in what ever order but only pre-programmed commands by us will be carried out.

 

We would set up 'End Carriages' in loco groups but, program commands in sensors in Track Layout Design.

 

RM will know the direction from the sensor and the arrow on our layout design. First the sensor will be activated by a tag passing over then RM will co-ordinate this with the arrow on our layout, how we are not sure yet but x,y co-ordinates will no doubt play a part in this. 

 

---> this would indicate direction of travel on track, loco/train may be going forwards or reverse.

 

<--- this would indicate direction of travel on track, again loco/train may be going forwards or reverse.

 

[PJ_model_trains]

...you don't actually need to know if a loco has a carriage in the LC group behind it.  If it does, it will clear the signal just passed by the loco.  If it doesn't, the loco itself will clear the signal when it reaches the next sensor and sets its signal to red.

 

Hi Fishy, although it is probably possible for a loco to chase a signal Red and change the others back down the line at that point, I don't think it is practical for realistic running, or safe running of trains.

 

The reason for End Carriage tags as we have discussed is to change signals back down the line, 'as soon as' the last carriage clears the previous Block. 'At that time' signals down the line should be changed to set Block conditions to the previous Blocks, these Block conditions are set by signal aspects Y,YY, G or flashing. The reason to change them as soon as possible is because the signal aspect allows us to slow trains down to suit Block conditions. On Signal Yellow continue with Extreme Caution. Any delay in setting back down the line signals/Block conditions means a loco could be running far to fast to stop if the next signal is Red. 

 

I agree some trains will be just short of Block length and they will not make a lot of difference, but a lot may be short or just loco and the time taken to go from one end of a Block to another before signals back down the line are changed would be unacceptable, unrealistic, and unsafe.

 

[hosh]

Set clear signal - Sets the next signal back to red/clear which in turn adjusts signalling back from there.

 

Set danger signal - for the signal at the sensor just triggered - red/occupied

 

Correct?

[PJ_model_trains]

Set clear signal - Sets the next signal back to red/clear which in turn adjusts signalling back from there.

 

For setting the Red signal to protect the Block just entered which we have been saying all along.

 

Set danger signal - for the signal at the sensor just triggered - red/occupied

Correct?

 

By its name this appears to only set a Green/Clear signal.

 

There are two things that strike me with this command:

1 - Green is Clear. Unless of course this command allows Set Clear signal - Yellow, or Yellow/Yellow or Fashing signal?

2 - But, this still doesn't Stop a Red signal back down the line from being changed.

 

This brings us back to what was discussed in the past - SET commands back down the line.

But, SET Commands can change a Red signal back down the line that a loco has changed as it entered another Block.

 

This does however point us to the fact that HRMS are directing us to use SET commands all we need building in to the software is the safety net to not change a Red signal (wiith Back Down the Line Commands) e.g.

 

Set clear signal - port #, Yellow

IF signal port # is Red  /  THEN Stop (don't check any further down the line)  /  ELSE Yellow

 

HRMS are reading our comments, they may have already considered this and may have even built it in the software. ;o)

 

What a weight it will be off our shoulders to know we can program back down the line and not have the risk of a Red signal being changed. The software automatically taking care of it for us, allowing us to plan our routes more confidently. 

 

[96RAF]

This is an interesting but complex read due to so many sideways links - however it will tell you how to do all you want with automatic/semi-automatic/manual modes, using any of the widely available detection methods known to man, all about blocks, reserved second blocks, thinking ahead and behind and all the signals info you could want, etc and more.

http://wiki.rocrail.net/doku.php?id=english

Scroll to the Objects section and read about signals and blocks and automatic operations.

You can even plumb in weather/daylight/night scenario options...

...and there is also a very handy return Home routing mode option, so when you are done for the day you can send your locos back to their shed(s).

I trust when RM gets LD on the streets it will publish a manual as comprehensive as this one so us laymen can understand it.

 

[PJ_model_trains]

@RAF96

Thank you... the system even caters for Ghost Trains!!!  ;o)

 

[PJ_model_trains]

The important thing to remember here, I think, is that it is a Rocrail system with Rocrails way of doing things.

 

Every companies system will work differently although there is some good information and is worth the read. RM with LD will be no exception.

[hosh]

So are you saying that RM with LD will be the same as RocRail?

 

Is this just optimism on your part or do you have it on good authority that RM will include most of what's in Rocrail?

 

It seems to me that Rocrail is a simple alternative to RM like JMRI.

 

I hope you're right but good luck selling this to PJ! :)

[96RAF]

@hosh

nowhere have I even suggested that RM LD will be the same as Rocrail nor even that of the features or methodology with be the same. I could well have mentioned JMRI in the same vein.

I merely pointed out that all that RM LD is trying to do appears to have already been invented in the open source code and that maybe it could give clues as to if some other application has done it then maybe there is a read across of principle to RM.

i don't even know if RM and Rocrail are even written in the same code, but I do see the use of logical blocks and sensors to affect and operate available routes, points, signals, etc by way of detection and that to me is what these various associated threads on here are talking to as well.

[PJ_model_trains]

I understood you provided the message with the intention of an example RAF96, you certainly didn't say, RM with LD will be the same as RocRail.

 

I know much of what we discuss can be hard to get over due to the complexity of it (and the algebra thrown in) but I have never some across a person to misread so many points.

What is it they say on Dragon's Den?  Oh yes... 'I'm out!'

 

[96RAF]

...It seems to me that Rocrail is a simple alternative to RM like JMRI...

Not in my opinion - I consider Rocrail (with JMRI a close second) to be far superior to the current RM in most ways - on screen presentation, overall capability, user friendliness, in particular dialogue boxes for setting up each and everything, and for catering to a mega range of kit. My one criticism of Rocrail is some of the group apparently sees Hornby kit as toys, which should be immediately refunded to buy proper kit from the likes of Lenz and NCE - their opinion - not mine.

 

I have no axe to grind over RM as it works fine on my layout and with my kit, so I use it all the time in preference to the over complexity of Rocrail or JMRI when applied to my layout - i.e. no detection, but I do like their routing methodology and layout checking for faults.

[hosh]

@hosh

nowhere have I even suggested that RM LD will be the same as Rocrail nor even that of the features or methodology with be the same. I could well have mentioned JMRI in the same vein.

 

Fair enough.

 

But I have a feeling that RM/LD will not even get close to JMRI or Rocrail. Hope I'm wrong but I get the impression it will be more of a "for the masses" type of thing with both less complexity and thus capability.

 

Agree with the rest of what you wrote in both your posts.

[Gregd99]

@Hosh

I have been out of the model railroad loop for a while as other demands call....

 

I set up a fully auomtated layout using JMRI and an elite a few years back. All sorts of complexities come up as you try and do this in a limited space (my layout 1.2 x 2.4m). A block allocation system is required. Train speed in block n-1 must be such taht you can stop in block n. You certainly need sto know where train starts and stops so that you don't - for example - throw points under a train!

 

It is all a lot of fun. I certainly learned a lot.

 

But...it takes a fair amount of time and understanding - RAF96 is a former RAF tech I think; I am a sw engineer. I don't think RM is trying to adress this market. There are uber-geeks at the JMRI forum that love this stuff.... many people don't want to get into that sort of detail.

[hosh]

@Hosh

But...it takes a fair amount of time and understanding - RAF96 is a former RAF tech I think; I am a sw engineer. I don't think RM is trying to adress this market. There are uber-geeks at the JMRI forum that love this stuff.... many people don't want to get into that sort of detail.

 

Yes, I agree.

 

But the problem is, if you don't "get into that sort of detail" then what do you end up with? I think it becomes a case of do it properly or don't bother at all.

 

As the situation stands, RM with LD would cost a small fortune so without it being very capable it would be a hard purchase to justify.

[PJ_model_trains]

@Gregd99

I don't think RM is trying to adress this market.

There are uber-geeks at the JMRI forum that love this stuff.... many people don't want to get into that sort of detail.

 

I totally agree, Hornby are aiming, I believe, to make things easier to attract more customers and bring more people in to the hobby. There are a lot of people don't know what a DCC Bus is let alone a soldering iron, they are not ready for JMRI, but a percentage of those coming into the hobby could very likely progress into that field. 

 

As will most hobby's the beginner will no doubt spend the most money, making things easier, attract more customers, bring more into the hobby, the beginner wants things as easy as possible, as near plug and play as possible, I think Hornby are aiming at that level. Good luck to them I say. 

[PJ_model_trains]

@hosh

But the problem is, if you don't "get into that sort of detail" then what do you end up with? I think it becomes a case of do it properly or don't bother at all.

 

I agree hosh

 

If this last carriage situation doesn't work, if a Red aspect signal back down the line is changed that a loco has just changed to Red the software will not do what it should and could cause more problems and it saves, this forum will end up with more posts on it than it has had to date!

 

HRMS have to get this right.

[hosh]

The only way to have a "for the masses" detection system is to have extremely simple and cheap hardware and software.

 

I have seen it as a bad sign from the get go that Hornby have proposed sensors that do more than merely detect - that send loco IDs back to the system. This makes the hardware a lot more expensive.

 

It's also puzzling. There are a ton of systems out there that don't require loco IDs being sent back from the sensors - just a basic detection. The train is fed into the system initially and then tracked forever after with the system knowing what trains are where all over the layout.

[Howbi]

@ Hosh...............Well, Hosh, here we go again, nothing but negative comments from you.........you don't like Hornby, you don't think their Loco Detection system will be any good, it will be un-affordable and won't work like you think it should............do you actually think that anybody here finds your posts interesting or constructive? I very much doubt it..........have you expressed your feelings about LD to Hornby's managing director, I'm sure he would be most interested!..............when a new product comes to market we can evaluate it for performance and value for money then decide whether to invest in it or not...........until then, why not wait patiently with anticipation. HB.       

[hosh]

@ Hosh...............Well, Hosh, here we go again, nothing but negative comments from you.........you don't like Hornby, you don't think their Loco Detection system will be any good, it will be un-affordable and won't work like you think it should............do you actually think that anybody here finds your posts interesting or constructive?

 

Funny how some seem to read and respond to my posts though. :)

 

I'm betting that most of the stuff on the table now will be off it by launch - if we ever do get liftoff that is!

 

Like I've been saying for years, I'm here spectating due to intrigue caused by

 

• how long it's taken Hornby to get with the computer era
• Some of Hornby's claims about proposed system that doesn't add up
• Many of the same claims by loyal supporters

 

I had Hornby stuff as a kid and I'd like to be a loyal supporter but I don't back losers. Frankly, in terms of computer related things, I think Hornby's a disgrace.

 

All these conversations should have been taking place at least 10 years ago - more like 15.

 

Pardon my non bubbly, non puppy dog wagging tale attitude.

 

Where is it?