LD (Loco Detection) v BD (Block Detection)

[hosh]

@hosh...............you are missing the point, again............there are many situations where several locos pass over the same sensor on a layout...........

 

All at the same time Gomez?

[MetmanUK]

 

@hosh,

Your example is procedural.  With LD we are talking event-driven.  BIG BIG difference.  Until you understand the difference you just wont get why LD is superior (in theory).  I would have hoped a computer diploma would have helped you but ........ (sorry to be so critical but 20 pages of this says it all).

[PJ_model_trains]

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?

 

In a word.... No!

 

Firstly, sensors are not tripped. Sensors read tags and send back 2 items of data as a packet, the sensor ID and the loco tag ID

 

Secondly they would not read sensors A, B, C you are applying visual titles to what you have named your Blocks, in LD your simulated blocks.

 

Also the number of blocks sending back data will depend upon

 

• The number of trains running that have tags
• The number of last carriages, wagons or guards vans that have tags
• The number of sensors installed

 

You could a lot of data comming back to RM for processing, they will all be small packets of data, they will all include a loco tag ID and a sensor ID. As MetmanUK was saying these are random not A, B, C, they could be any tag on any length or loop of track. The fast the locos are running the more data send back.

 

• Train-1 may be express on an outer loop running at say 65mph. There may be 4, 5 6 simulated blocks on that length. The loco and last carriage will be sendng data back for every sensor passed over.
• Train-2 may be good in another loop, running slower but the same applies
• Locos-3 & 4 may be shuttle service DMU's using sidings stations as well as other routes.
• There may be locos moving over sensors in the goods/fiddle yard also.

 

They are all at different times, in different places, travelling over different sensors, sending loco and sensor ID's back to RM for further instructions. These packets of data will be random the only item dictating data being sent back is an item with programmed tag going over a programmed sensor.

 

[PJ_model_trains]

I totally agree with Ray

 

The beauty of LD is it allows us to run our trains as we wish. A loco cannot turn right or left other than at a curve in the track or a branch. It can only go forward or reverse, and that is all RM can tell it to do regarding movement. Forward, Stop, Reverse, Stop.

 

Points and signals take us a step further, points dictating direction, signals providing instructions for the driver of a loco, as on the railways, as with traffic lights on our roads they tell the driver what he should do. The points dictate direction a loco cannot do anything else but follow the track, but signals are telling the train driver what he should observe, so are speed limit signs and other items they are instructions for safe driving.

 

LD using sensors will take us a step further in railway modelling reality, allowing us to tell the loco (driver) what speed the loco should run or stop. To aid us we can simulate blocks, which in turn work with other elements in RM to help us 'do more' and 'run more' trains safer and more accurately.

 

But no matter what we can do, no matter what we achieve, a loco can only move forward or reverse on any length of track based on an instruction from us.

 

[96RAF]

 As a loco can only turn when the rails allow it I wonder why drivers need to undergo route learning given they can only go where the signallers send them.

one of life's little mysteries ...

... given I want to drive my train from A to X I presume I have to file a preferred route with central control and someone there will tag my loco and press the right buttons at exactly the right time to get me there...

[Howbi]

@hosh...............you are missing the point, again............there are many situations where several locos pass over the same sensor on a layout...........

 

Your reply does not make sense nor do your recent posts so whilst I have enjoyed our debating I am withdrawing from further discussion but I do wish you and yours a very Merry Christmas........HB.

[RDS]

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

No, on the contary John, I am delighted I started it, otherwise all these circles would have been completed on our 'sweep' thread.

I find it is a bit like a soap on TV in that you can miss a complete page (or episode) and still be up to date with the never ending story.

There are some very good analogies though and I particularly like the blind mans buff one.

[Fishmanoz]

Just a word or two on programming when you eventually have LD.

 

To find out what programming can be done, all you have to do is open RM and the manual and try it, you'll be able to see what's possible without even connecting to a layout or having locos running.  You can write programs to control the throttle on locos, and change points signals and accessories.  But you can't write a program as such to make an LD sensor detect anything, that can only happen when an actual LD ID tag passes over it.

 

So what can you do?  Everything you can do based on a detection is in the setup for the sensor and the full instruction set you can use for this is earlier in this thread.  It includes conditional If/Then sequences of instructions and the ability to run a program, an even more powerful feature.  It does way beyond the things you can do in point and signal setups where changing one can allow you to change a number of others.

 

PS.  For those of you who understand that RM holds no positional information whatsoever, don't get fooled into thinking this changes at the instant of detection at a sensor, it doesn't. Detection implies only that, a detection has been made, there is no implication of location.  And there is also no implication that any sequence is known about a number of sensors by RM, because that too would imply locations that don't exist.  But also realise this "lack" doesn't limit what you can do running your layout.  PJ for instance, has posted many times how he intends to simulate block operation by having consequent changes to points and signals when detections are made up and down the line he, but not RM, knows he has placed them on.  Put it this way, as long as the driver and the signalman know where everything is, and they clearly do, they can either run the railway themselves, which they also clearly do, or they can write a program to fully automate the railway. And RM allows just that.

[hosh]

@hosh...............you are missing the point, again............there are many situations where several locos pass over the same sensor on a layout...........

 All at the same time Gomez?

Your reply does not make sense nor do your recent posts so whilst I have enjoyed our debating I am withdrawing from further discussion but I do wish you and yours a very Merry Christmas........HB.

 

And this is where you and others are failing completely.

 

I will ask again - do you intend to have trains on your layout that will simultaneously be heading toward a given sensor?

 

To those of you that will, and are talking about the randomness of everything, please have a video camera on hand when you first run RM with LD - me and Gomez will be watching with glee! :)

[hosh]

 

@hosh,

Your example is procedural.  With LD we are talking event-driven.  BIG BIG difference.  Until you understand the difference you just wont get why LD is superior (in theory).  I would have hoped a computer diploma would have helped you but ........ (sorry to be so critical but 20 pages of this says it all).

 

Get that video cam ready! :)

[hosh]

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?

 

In a word.... No!

 

Firstly, sensors are not tripped. Sensors read tags and send back 2 items of data as a packet, the sensor ID and the loco tag ID

 

Secondly they would not read sensors A, B, C you are applying visual titles to what you have named your Blocks, in LD your simulated blocks.

 

Also the number of blocks sending back data will depend upon

 

• The number of trains running that have tags
• The number of last carriages, wagons or guards vans that have tags
• The number of sensors installed

 

You could a lot of data comming back to RM for processing, they will all be small packets of data, they will all include a loco tag ID and a sensor ID. As MetmanUK was saying these are random not A, B, C, they could be any tag on any length or loop of track. The fast the locos are running the more data send back.

 

• Train-1 may be express on an outer loop running at say 65mph. There may be 4, 5 6 simulated blocks on that length. The loco and last carriage will be sendng data back for every sensor passed over.
• Train-2 may be good in another loop, running slower but the same applies
• Locos-3 & 4 may be shuttle service DMU's using sidings stations as well as other routes.
• There may be locos moving over sensors in the goods/fiddle yard also.

 

They are all at different times, in different places, travelling over different sensors, sending loco and sensor ID's back to RM for further instructions. These packets of data will be random the only item dictating data being sent back is an item with programmed tag going over a programmed sensor.

 

 

You are so off base here and missing the point it's incredible.

 

There is no chaos - no randomness at all. Unless the user has no idea of what they're doing.

 

We only need to concentrate on 1 train and it's program at a time.

 

Let's have train T just leaving sensor A and headed for sensor B. RM has just sent T to B and knows that the next time sensor B is tripped that it's train T. Other trains wanting to get to B (that are in blocks adjacent to B) will sit and wait for T to vacate B and then they in turn will move to B. There is only ever 1 train at any point in time about to trip a given sensor.

 

RM as a whole will know what trains are where all the time and what blocks are occupied and which aren't and will adjust signalling accordingly. Any given train on it's route (program) will have this information passed to it every time it trips a sensor and be instructed accordingly (basically stop or continue). If there is already another train headed toward the next sensor in it's route then it gets a red signal and sits and waits it's turn. Again, 1 train toward a given sensor at any given time.

 

There is no randomness.

 

The only randomness, which is completely different to what's been alluded to, is the way that routes interact over time. This is random, but still totally understood and controlled by RM. The implication that RM has no idea what train is about to trip what sensor, and thus needs loco ID info from the sensor, is utter rubbish. Go and look at Phul007's post regarding his CTI system. Do some of you hear any words other than your own?

[hosh]

PS.  For those of you who understand that RM holds no positional information whatsoever, don't get fooled into thinking this changes at the instant of detection at a sensor, it doesn't. Detection implies only that, a detection has been made, there is no implication of location.  And there is also no implication that any sequence is known about a number of sensors by RM, because that too would imply locations that don't exist.  But also realise this "lack" doesn't limit what you can do running your layout.  PJ for instance, has posted many times how he intends to simulate block operation by having consequent changes to points and signals when detections are made up and down the line he, but not RM, knows he has placed them on.  Put it this way, as long as the driver and the signalman know where everything is, and they clearly do, they can either run the railway themselves, which they also clearly do, or they can write a program to fully automate the railway. And RM allows just that.

 

I wonder what some of you think is going to be in a given train's program.

[hosh]

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?

 

In a word.... No!

 

 

 

So would you care to give us an example of what one of your loco's programs is going to look like when you hook LD up to RM?

[MetmanUK]

It can be quite interesting feeding WUMs as those wanting to learn can become better informed by the 'discussion'.  At some stage, though, yoou have to stop feeding them.  I'm out.

[37lover]

I'm going to kick myself but please what is a WUM?

[96RAF]

I'm going to kick myself but please what is a WUM?

Wind up merchants???

[PJ_model_trains]

Dear hosh

 

A lot of people have taken a lot of time trying explain to you the difference between BD and LD. It appears to me that although we have listened to your arguments for BD and given you explanations of the difference between the two systems you are not considering the replies with an open mind. It is as though there are two windows to look out of, the BD one which you see clearly and the LD one where you have the curtains closed, you hear what we are saying but instead of considering, what so many are telling you, you fail to consider both the explanations and examples provided to help you. You only see out of the BD window!

 

Due to the amount of discussions held on the forum, the amount of examples given, the amount of patience many have shown, including advice from several retired computer programmers! We appear to have hit a brick wall with you, you can only see out of the one window.

 

The tone of replies on the thread has changed over the last few days, this is clear. On this basis and for the reasons stated above I confirm 'I am out'

 

Good luck with what ever you choose to do with your trains, good luck with what ever system you think is best for you. That is meant sincerely. Happy Christmas.

 

[hosh]

Well I suppose the above replies are as good of a way to avoid admitting defeat as any.

 

Good luck to you all in your version of the automated future and I hope you put a lot o videos up of your locos smashing into ech other as they simultaneously approach the same sensor/s. LOL

 

cheers!

[hosh]

Btw, some of you might like to drop Hornby a bit of a note about a pretty big mistake they have made on page 139 of the PDF file -

 

When available, Loco Detection will allow RailMaster to know where each loco is on your track and to take action accordingly.

 

 

hehehehe..........those old silly Billys!

[hosh]

Gooday Phill,

 

If you could give a brief outline of what a program looks like for one of the trains on your layout then I'd appreciate it. Especially regarding signals, points and sensors and the way you actually create a route.

[MetmanUK]

Hi all,

 

I’ve had to make a number of changes to this thread. At the very least, please keep all discussion on the Forum civil.

 

If this topic continues to draw negative comments and rude posts I’ll have no choice but to remove it

Perhaps I can respectfully suggest that if you are going to do this you at least be consistent.

[PJ_model_trains]

Hi all,

 

I’ve had to make a number of changes to this thread. At the very least, please keep all discussion on the Forum civil.

 

If this topic continues to draw negative comments and rude posts I’ll have no choice but to remove it

 

Hello Adam

 

Nice to see the forum is being watched over but, I do wonder if the statement you make regarding 'negative comments' needs further clarification.

 

Some comments and replies are going to be negative, or appear to some to be negative, depending on the type of conversation and these could be totally acceptable, however rude posts and the like we appreciate are not acceptable.

 

[hosh]

There are some around here who have made it clear how precious they are and my reaction to that is simple - I will simply ignore their posts as much as possible and not respond to them.

 

After all, there is freedom of speech and people shouldn't be burdened with actually knowing what they're talking about. They should be able to talk with great authority about things they know nothing about without any threat whatsoever of any ridicule.

 

Long live democracy! :)

[96RAF]

After all, there is freedom of speech and people shouldn't be burdened with actually knowing what they're talking about. They should be able to talk with great authority about things they know nothing about without any threat whatsoever of any ridicule.

Long live democracy! :)

you are not an MP or even the PM posting incognito are you hosh ...

[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

 

So when you tell the train to move, and adjust the points ahead so that they lead to sensor A, then how is that not RM knowingly sending the train to sensor A? (shrugs)

 

You have written that program (route) for that train, saved it to RM and run it with RM - and thus RM now "knows".

 

I continues to amaze me that this isn't a no brainer for you all.

 

I think too many are being side tracked by the plethora of seemingly clever points of view that are simply wrong.