LD (Loco Detection) v BD (Block Detection)

[Fishmanoz]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

[hosh]

Hosh, now we come to the nub of it.   Your software system may well have a "recording of where everything is in relation to everything else" but I can assure you RM definitely does not.

 

But you've just shot yourself in the foot. That record is saved and accessed by RM and I assure you that in any conventional computer venacular that this is refered to as the system "knowing". The system is fed location information by the sensors - dead simple.

 

The sensors are the location - dead simple.

[hosh]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

 

Surely you're not implying that there is no specific identifier for every detector - is that what you're saying?

[MetmanUK]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

Completely agree.  Sometimes you have to get round the formal design concepts using something that the language has available but not for its intended use.  In programming terms it is frowned upon - I won't go into details why - but the pragmatic amongst us, like me, are ok with it.  Using a Red/Green signal as an on/off switch isn't pretty but gets the job done.  As I have alluded to previously, it may be that widening the scope of their bespoke scripting language to provide functionality necessary to make LD usable is causing Hornby a headache - and us !!!!

[Howbi]

Don't let these simple facts get in the way of attempting to impress everyone with your supreme insightfullness and ability to see what the rest of us cannot though! :)

Hosh................hope you're not including me in "the rest of us".........I will speak for myself thankyou...:-)  HB

[MetmanUK]

Sorry for preaching - I'll happily take questions now ;-)

 

Interesting - I'm in the middle of a computer diploma right now.

 

But sorry, i disagree with the entire jist of your post.

 

Any automated model rail program will be procedural. Even the "events" created by sensors and signals are not random. The only example of a random event occuring in this process is the user cancelling a trains program midstream and either running another or taking manual control. Now that would be a good example of an "event driven" modern computer programming language with objects, etc.

 

The other point you made was BD not sending back the locos ID. And I think this mighy be where a lot of people are failing to understand a lot about automation.

 

At any given time on the layout there will only ever be one train headed for one sensor - otherwise there'd be collisions. I point this out for a few reasons -

 

•  It shows how easy it is for software to track trains
• Since you can only have 1 train headed toward 1 sensor at a time, the program is indeed procedural.
• When train A wants to go to Sensor A but train B is already headed there, train A gets a red signal

So there is no random (event driven) aspect to automating a model railway. The fact that Hornby's LD will send loco IDs to RM is a mere gimmick! It is a waste of time and money.

Perhaps if I had used unexpected instead of random ........

 

Most railways run to a timetable and are therefore procedural BUT points fail, passengers are taken sick or pull they communication cord etc etc. Drivers are there for a reason - namely the unexpected/unplanned event.  The drivers are the equivalent of the LD event.  Blocks do not come into it.  Blocks are macro scale whereas the driver is micro scale.  LD is BD+

[Fishmanoz]

Everyone else is telling you the same as I am, using their own words.  At least 3 other posters have told you exactly what I have.  I seem to be the only one silly enough to persist by trying to explain it in different ways each time you appear to fail to understand in the way used previously.  I may be wrong, you may well understand it, but nothing you have written has led me to the conclusion that you do, hence my trying again.

 

My foot is sound.  As I said, the only access to the record made by RM is to display the schematic and to do what I said above - either switch them or run instructions. Sensors are in no "sense" locations for RM, only things that make detections, upon which detections instructions are carried out.

 

So unless my insight comes up with a different way to explain it, I will remain silent on the matter from here.

 

And in answer to your last question, no, no such implication about sensor IDs.

[RDS]

... Would be interested to hear your thoughts. R-

I am not sure I have the patience for that forum but if I ever do post something, my alias is 'tangerineomega' (RDS was too short)

[hosh]

 

Perhaps if I had used unexpected instead of random ........

 

Most railways run to a timetable and are therefore procedural BUT points fail, passengers are taken sick or pull they communication cord etc etc. Drivers are there for a reason - namely the unexpected/unplanned event.  The drivers are the equivalent of the LD event.  Blocks do not come into it.  Blocks are macro scale whereas the driver is micro scale.  LD is BD+

 

Well now we're in the territory of signals or locos failing - that's a different conversation altogether. All these discussions assume everything is foolproof.

 

These unforseen events are easily dealt with though. RM sends Train T to sensor A - if it doesn't arrive within x seconds then shut down the layout. I'm pretty sure I've seen refernce to such things in RM, correct?

 

But again, this is an entirely different conversation. This issue assumes perfect functionality of all locos, sensors and the system in general.

[hosh]

My foot is sound.  As I said, the only access to the record made by RM is to display the schematic and to do what I said above - either switch them or run instructions. Sensors are in no "sense" locations for RM, only things that make detections, upon which detections instructions are carried out.

 

So are you saying RM as a whole has no idea where a sensor is, or just the shematic?

 

I cannot for the life of me understand why you aren't realising that A SENSOR IS A LOCATION.

 

I cannot for the life of me understand how it's hard for many to understand the concept of a computer being fed specific information about location means that that system knows that locational information - just bizarre!

 

A sensor will be installed, named and then simply represent that location on the layout - simple. When it's tripped, the system, be it LD or any other, will know that Train T is at that location. Simple.

[hosh]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

Completely agree.  Sometimes you have to get round the formal design concepts using something that the language has available but not for its intended use.  In programming terms it is frowned upon - I won't go into details why - but the pragmatic amongst us, like me, are ok with it.  Using a Red/Green signal as an on/off switch isn't pretty but gets the job done.  As I have alluded to previously, it may be that widening the scope of their bespoke scripting language to provide functionality necessary to make LD usable is causing Hornby a headache - and us !!!!

 

Wow - another can of worms!

 

How do you know RM can't do a new set of intructions for consecutive sensors - is that in there now? Surely the release of LD will coincide with a simple way to write sequential programs that simply include the sensors and related instructions. I can't see how this would be difficult.

[Sloop]

Thank you RogerB, I should have read the index before asking the question. I still have to look at the CTI user group forum, but it looks like the problem is getting Elite/elink to run with the CTI system.

 

John B.

[PJ_model_trains]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

I don't follow on the second detection, think I must have missed something here?

There can only be one detection and with that detection there are only two items of data packeted back for processing. The sensor ID and the Loco tag ID. If the same train passes over another sensor although the train ID is the same the sensor ID is different. The only way I see the second detection is to have one sensor in one loop so as when it goes round the same sensor ID and train ID are returned for processing.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

 

The dummy idea is good and is already used for signals. I am sure many who have feathers, for now, have a signal representing their number of aspects and another for a two aspect with feather to control the feather. I realise that was not what you meant but mention it in case someone has a feather signal hand at present it doesn't work. (this may not work correctly as it should now for some due to TT signal problems and when purchased. But will)

 

Regarding my 4 aspect signals you mention above. These work, at present, 4 aspect signals are the only ones that do work correctly in RM. But when it comes to LD, Red/Stop to Green/Clear, are not the ones that would want swapping in aspect, we can call all 4 aspects with 4 aspect signals in RM program and they work correctly. In fact the R, Y, YY, G sequence does work in RM in programs and when clicked on individually.

 

Just to clarify the signal sequence problems experienced are for 2 and 3 aspect TT signals.

 

It is Y and YY that is needed in LD, these work in 4 aspect programs so there should be no reason not to include them in LD. But, we appreciate HRMS are working on signalling issues and the facy Y there are the issues raised including the TT 2 and 3 aspect signals and 3 aspect has a Y aspect it seems to make sense HRMS are working to fix signal issues before adding Y and YY in LD. I think.

 

[PJ_model_trains]

Metman, I agree your reply is excellent.  It got me thinking though - there is nothing in the instruction set relating to locos that would allow a sequence of commands to be executed only on every second detection.  On every detection, the same set of instructions will be executed either for any particular loco, any group of locos, or all locos, depending on a FOR instruction you include specifying one of these 3, no other options.

 

However, that doesn't mean it can't be done because you can, in addition, include a real or dummy signal.  On detection, you can have 2 instructions - for signal RED, set signal GREEN and, for signal GREEN, set signal RED.  And in addition for signal RED, set loco ID/group/all to speed 0.  And of course, once they work, PJ could use his 4 aspect signals to do something every 3rd or 4th detection too.

 

Surely you're not implying that there is no specific identifier for every detector - is that what you're saying?

 

There is one tag on each loco (unless a large one and we choose to or can add a second on the tender but they would have different tag numbers).

 

There is only one ID for every sensor

 

When a loco goes over a sensor, one packet of information is send back through LD controller and PC to RM for processing. (loco ID and sensor ID).

 

There will only be one detection for every pass over sensor. Even if a loco stopped and reversed it would be two etections therefore two packets of data sent back to RM, although they would both be the same items of data there would be two two detections. Even if a loco did a full loop with just one sensor in the loop, there can only be one detection for each pass over of a sensor.

 

[PJ_model_trains]

My foot is sound.  As I said, the only access to the record made by RM is to display the schematic and to do what I said above - either switch them or run instructions. Sensors are in no "sense" locations for RM, only things that make detections, upon which detections instructions are carried out.

 

So are you saying RM as a whole has no idea where a sensor is, or just the shematic?

 

I cannot for the life of me understand why you aren't realising that A SENSOR IS A LOCATION.

 

I cannot for the life of me understand how it's hard for many to understand the concept of a computer being fed specific information about location means that that system knows that locational information - just bizarre!

 

A sensor will be installed, named and then simply represent that location on the layout - simple. When it's tripped, the system, be it LD or any other, will know that Train T is at that location. Simple.

 

Hi hosh

 

Have you heard the saying everyone cannot be wrong. To me if so many said I was wrong on a particular issue I would look again at my thoughts and where I could be missing something or maybe misunderstanding something.

 

Many people have tried to explain different ways. What is clear is that RM only remembers where we put items on the screen so that it can put them back there for us to view.

 

A sensor is shown at an x-y position on the screen (we agree) so that RM can put it back on the screen again in the same place. (we agree)

 

All RM knows it is it is sensor number #1. (or whatever ID we gave it) The ID goes in its database not what we see on screen.

 

When a loco goes over sensor #1 on our track data is sent back saying... loco #1 went over sensor #1.

 

RM accepts this data from LD and looks for any pre-program instructions we may have given it. Under the reference sensor #1. (This is what RM remembered and has in its database, RM also knows the loco ID as we programmed that also and that is on its  database)

 

RM only works on sensor numbers and loco tag numbers when receiving data. We put an image on the screen for our visual benefit, the position of the loco detection icon doesn't matter it is just a visual source on screen to allow us to open it up (in layout editor) and add instructions (instead of having a popup window to type in computer code as instructions). Using this method HRMS have simplified programming methods to make it easier for a much wider section of people, from the beginner to the advanced user.

 

We add the LD icon in the layout design so that it shows on our schematic layout on screen. The schematic layout is just a visual representation of our layout, something like it, not exactly like it. A visual representation for us to use to represent our layouts to make it work in many different ways with ease.

 

All programming is done in Layout Design, in the Layout Editor. This is where we add the codes that RM remembers (not the icons, it remembers the codes we program in in the layout editor)

 

So putting it another way, from an operational perspective, RM doesn't remember what is on screen or where it is, because RM applies codes to all those programmable parts and remembers them only. Track pieces are not programmable parts, points, signals and LD sensors are. They could be anywhere on screen with or without track pieces as was explained previously by RDS. RM only remembers the codes we have programmed so that it can carry out tasks we have set it to do, not the screen elements or their screen positions. So when a train passes a sensor RM is not interested in what is where on screen, it is looking for items we have programmed, items it saved in its database when we programmed them, it is looking for instructions that relate to those codes only.

 

Sensor #1 detects loco #1, data sent back to RM, RM checks 'database' for loco #1 and carries out the tasks we have programmed for this loco. If nothing is programmed for loco #1 it carries on as normal.

 

Lets say the instructions we pre-programmed into RM, for sensor #1, in the program layout editor, Loco #1 speed 30mph.  Nothing happens on screen but the train changes to that speed, it is Data processing not screen processing. It is down to the software not where pieces are on screen they are there as a visual aid for us.

 

We are all trying different ways hosh, trying to help you see the position of things on screen don't matter. It is what and how they have been programmed by us. Switch your computer screen off and the  loco #1 running on the layout will still change the set loco speed to 30mph when the loco passes over sensor #1

 

[PJ_model_trains]

 

The sensors are the location - dead simple.

Spot on hosh... the sensors are the location on our layout.

 

Our schematic layout represents this position in a visual form for us to work with.

 

The sensor was given an ID by us in layout design when we programmed it, RM remembers this programmed ID in its database. Everything works from the database.

 

The sensor when activated sends data to RM software that checks it's database. It then carries out instructions we have pre-programmed from the information received.

 

It is that simple.

 

As MetmanUK was saying everything is subject to random data received, this train passes that sensor, another train passes another etc, random commands.

 

When you buy something in a shop the shop keeper scans this item, then that one, every customer has something different, every time in a different order. Each scan sends data to the main system, it is checked to the database (look-up), a pre-programmed command, or commands are performed based on the data received and then waits the next item of data to be sent to it for it to check and carry out any pre-programmed commands.

 

[Slornie]

I cannot for the life of me understand why you aren't realising that A SENSOR IS A LOCATION.

I cannot for the life of me understand how it's hard for many to understand the concept of a computer being fed specific information about location means that that system knows that locational information - just bizarre!

A sensor will be installed, named and then simply represent that location on the layout - simple. When it's tripped, the system, be it LD or any other, will know that Train T is at that location. Simple.

 

A sensor is a location when it is triggered.  However RM does not understand or remember the position of that location relative to the position of any other locations (triggered sensors) that may exist.

 

Think about the game Blind Man's Bluff.  RM is like the person moving about with their eyes closed.  When they touch (sense) an object it has a location at that moment in time, but they still don't have any concept of where it actually *is* (the position) in relation to anything else.  As soon as they lose contact with it (continue moving around/loco has passed the sensor) the object's location is no longer known.  The physical position of the location (touched or sensed object) in relation to the position of the next or last location is always an unknown.

[Fishmanoz]

PJ, I misled you with my second detection terminology on the previous page.  I intended it to be like your single detector in a loop example.  The second detection occurs at the same sensor the second time the loco goes around the loop.  Metman appeared to suggest that you could program a loco to act differently the second time around.  I said you can't, the same loco instruction set will be there every time.  But if you used a signal that was set to red after the first time round, you could use it to stop the loco the second time.  Then you can also set the signal back to green so the loco won't stop the next time. 

[PJ_model_trains]

PJ, I misled you with my second detection terminology on the previous page.  I intended it to be like your single detector in a loop example.  The second detection occurs at the same sensor the second time the loco goes around the loop.  Metman appeared to suggest that you could program a loco to act differently the second time around.  I said you can't, the same loco instruction set will be there every time.  But if you used a signal that was set to red after the first time round, you could use it to stop the loco the second time.  Then you can also set the signal back to green so the loco won't stop the next time. 

 

Regarding your example, are you not looking at the standard switching, red to green, green back to red signal (2 aspect only)? Surely this would not be the case even in the example of one sensor in a loop.

 

• Loco1 passes over sensor1 RM has pre-programmed instruction change to Red/Stop.
• When the loco1 comes over sensor1 again the same instruction applies so the signal stays Red/Stop

 

In practice this would not happen as no one would have just one sensor on a loop. Unless it is a 4 bend circle that is not long enough for 2 blocks but if that was all a person could afford they wouldn't be looking to install LD.

 

As soon as you have at least 2 sensors in a loop (2 simulated blocks) the problem is solved.

 

• As the loco passes the first sensor, moving into block1, it changes the adjacent signal to Red/Stop. (protecting the block it has entered)
• The loco moves on and passes the second sensor, moving into block2, turning the adjacent signal Red/Stop also.
• When the last carriage/item of the train passes the second sensor/signal it changes the first to Green/Go.

 

Blocks are entered and exited as the train goes round, signals change Red to Green, Green to Red according to whether a Block is occupied or vacant.

 

The switching idea is good but I can't see it relates to this example, it is a nice card to have up our sleeve. I use this switching idea in a different way. I have all my signals set up but the feathers are not programmed to work in RM yet. So for example I have a 2, 3 aspect signal representing the signal on my layout (I don't have 4 aspect with feathers only 2 & 3) but on the schematic layout I also have a 2 aspect signal with feather, next to the main one, set to another port, so I can switch on and off the feather. Utilising what we have now until RM includes in full.

 

[hosh]

2 recurring themes -

 

• walk all over conventional computer terminology relating to what a computer program "knows"
• the insistence that LD will be better because it returns the absolutely redundant loco ID

Allow me to try to help those that seem to believe that LD is better due to returning a loco's ID. Unless we're talking about Gomez Adams' layout that may have multiple locos approaching a sensor simultaneously, then one loco approaches 1 sensor at a time. So train T is sent so sensor A by RM. No other train is going to trip sensor A because there is only one headed toward it. When the sensor is tripped, it is train T because it cannot be any other. There is no need for the sensor to read the trains loco ID tag and send it to RM since it's RM that sent train T to sensor A in the first place - completely redundant.

[Yelrow]

RDS, i bet you wish you had never started this thread. Its a bit like the   circle line on the london tube, goes round in circles, and to my mind, achieves nothing. john

[St1ngr4y]

There is no need for the sensor to read the trains loco ID tag and send it to RM since it's RM that sent train T to sensor A in the first place - completely redundant.

 

.I've been deliberately trying to stay away from this conversation, but I must challenge this statement of yours. RM didn't knowingly send the train to the sensor. All RM did was to tell the loco to move forward or backward at a certain speed. It may also have told one or two points to switch, but RM has no idea of how these collective actions cause a certain loco to move towards a particular sensor.

Ray

[hosh]

There is no need for the sensor to read the trains loco ID tag and send it to RM since it's RM that sent train T to sensor A in the first place - completely redundant.

 

.I've been deliberately trying to stay away from this conversation, but I must challenge this statement of yours. RM didn't knowingly send the train to the sensor. All RM did was to tell the loco to move forward or backward at a certain speed. It may also have told one or two points to switch, but RM has no idea of how these collective actions cause a certain loco to move towards a particular sensor.

Ray

 

Then when you write a program for a train when LD is released, what do you think will be in it.

 

I think it will look something like -

 

go forward

when sensor A tripped, do such and such

when sensor B tripped, do such and such

when sensor C tripped, do such and such

 

The sequence of sensors will be a part of the program. So after the train trips A it's headed for B.

 

Correct?

[Howbi]

@hosh...............you are missing the point, again............there are many situations where several locos pass over the same sensor on a layout.............one obvious example is where a single track leads into a fiddle yard, lets say 6 roads..............3 are occupied so 3 remaining  trains cross the lead-in sensor which, on identifying each loco, fires the relevant points to direct each loco into it's designated siding which you had previously programmed.............and, yes, that will be a location in this instance but you know that already cos you designed it. So the necessity for the loco ID in this example is obvious.  HB.

[hosh]

Btw, I'm seriously thinking about contacting the Guiness Book of Records when LD is released.

 

You see, RM is going to be the first computer program in history to be able to fully automate model trains without even having any idea where any of them are. Truley remarkable.