LD (Loco Detection) v BD (Block Detection)

[hosh]

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

 

Lookout, I might report you for accusing me of being a politician! :) LOL

[St1ngr4y]

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.

 

You tell the train to move, you adjust the points ahead so that they move towards sensor A. But RM doesn't know that the train is now heading towards sensor A. It has no way of knowing where the train is on your layout diagram. The purpose of the layout diagram in RM (at present) is simply to allow you to locate the points and signals when you want to operate them. In no way does RM use the layout diagram to spacially connect the positions of sensors , signals, points relative to each other.

You could take your layout diagram, delete all of the curved and straight pieces, line up all of your points in a column on the left and all of your signals on the right, and all of your LD sensors along the bottom. When you click the points and signals, they will still operate the points and signals. But RM is just as aware of their relative positions as it was before i.e. not aware at all.

Ray

[hosh]

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.

 

You tell the train to move, you adjust the points ahead so that they move towards sensor A. But RM doesn't know that the train is now heading towards sensor A. It has no way of knowing where the train is on your layout diagram. The purpose of the layout diagram in RM (at present) is simply to allow you to locate the points and signals when you want to operate them. In no way does RM use the layout diagram to spacially connect the positions of sensors , signals, points relative to each other.

You could take your layout diagram, delete all of the curved and straight pieces, line up all of your points in a column on the left and all of your signals on the right, and all of your LD sensors along the bottom. When you click the points and signals, they will still operate the points and signals. But RM is just as aware of their relative positions as it was before i.e. not aware at all.

Ray

 

So the point of contention is finally clear.

 

You are saying that info on a schematic is the qualification for RM "knowing".

 

I disagree and in basic conventional venacular with regard to any computer system, if data relating to specific parameters is fed into that system then the system "knows" about those parameters. How that knowledge manifests itself is irrelevant. In fact, the system might not even make use of that information but if it is made available to it it is still said to "know" about it.

 

Whether this information is shown blatantly via a the RM schematic is irrelevant. The fact is, this data is referenced via each and every train's programs, that are saved in RM and run by RM. At this point RM not only "knows" but is using this knowledge about the relative positions of sensors and other devices relative to them.

[St1ngr4y]

@hosh

"At this point RM not only "knows" but is using this knowledge about the relative positions of sensors and other devices relative to them."

The only knowledge RM has of their relative positions is their x,y co-ordinates to enable them to be displayed on the screen. RM does not use this knowledge to determine the relative position of these items to each other with respect to train movements.

Ray

[hosh]

@hosh

"At this point RM not only "knows" but is using this knowledge about the relative positions of sensors and other devices relative to them."

The only knowledge RM has of their relative positions is their x,y co-ordinates to enable them to be displayed on the screen. RM does not use this knowledge to determine the relative position of these items to each other with respect to train movements.

Ray

 

So it will not be implied in the program (route) for every single train?

 

e.g.

 

sensor A tripped, set signals, set points for sensor B, stop/continue, etc

sensor B tripped, set signals, set points for sensor C, stop/continue, etc

sensor C tripped, set signals, set points for sensor D, stop/continue, etc

etc.

 

So here we see the implied relative positions of the sensors with every train's program. A program previously saved to RM and presently being run by it.

 

Btw, PJ has said the programs won't look like this - I'm waiting patiently for him or anyone else to tell us how they will look. :)

[St1ngr4y]

So you are now changing to implied rather than knowledge :-)

 

As far as incorporation into programs is concerned, PJ knows that I have always had reservations about how this will be achieved without major changes to the current structure of programs, which at present, in my view, does not fit in with an event-driven system. Having said that, I could have a try at suggesting a very simple example...

Suppose we have a train which starts at one end of a layout, and is to be brought into a station. There is a signal guarding the entrance to the station, and we place a LD sensor at that signal. Let's create program A, which sets all of the points and signals to reach the station platform, then starts the train using an accelerate command.

Now create program B, which is initiated when the train passes the sensor at the station home signal. This program will change the signal to red, then initiate a decelerate command for the train, ending with a stop command for the train.

I believe these simple programs would be achievable with the commands we know about currently. 

Ray

[hosh]

So you are now changing to implied rather than knowledge :-)

 

 

I have mentioned "implied" in many posts previous. Knowledge is knowledge, implied or not.

 

As far as incorporation into programs is concerned, PJ knows that I have always had reservations about how this will be achieved without major changes to the current structure of programs, which at present, in my view, does not fit in with an event-driven system. Having said that, I could have a try at suggesting a very simple example...

Suppose we have a train which starts at one end of a layout, and is to be brought into a station. There is a signal guarding the entrance to the station, and we place a LD sensor at that signal. Let's create program A, which sets all of the points and signals to reach the station platform, then starts the train using an accelerate command.

Now create program B, which is initiated when the train passes the sensor at the station home signal. This program will change the signal to red, then initiate a decelerate command for the train, ending with a stop command for the train.

I believe these simple programs would be achievable with the commands we know about currently. 

Ray

 

Is this different to what I outlined in my previous post?

[PJ_model_trains]

@hosh

"At this point RM not only "knows" but is using this knowledge about the relative positions of sensors and other devices relative to them."

The only knowledge RM has of their relative positions is their x,y co-ordinates to enable them to be displayed on the screen. RM does not use this knowledge to determine the relative position of these items to each other with respect to train movements.

Ray

 

So it will not be implied in the program (route) for every single train?

 

e.g.

 

sensor A tripped, set signals, set points for sensor B, stop/continue, etc

sensor B tripped, set signals, set points for sensor C, stop/continue, etc

sensor C tripped, set signals, set points for sensor D, stop/continue, etc

etc.

 

So here we see the implied relative positions of the sensors with every train's program. A program previously saved to RM and presently being run by it.

 

Btw, PJ has said the programs won't look like this - I'm waiting patiently for him or anyone else to tell us how they will look. :)

 

hosh

 

What I said was... that we will no doubt have many trains/locos running at once, these will pass over sensors at 'random', as will last carriages, wagons or guards vans. Each will send back a small packet of information, namely the sensor ID and the loco (or other item) tag ID.

 

I was trying to get your mind from everything happening as A, B, C although I appreciate if that is what you have called your blocks, and your 'one' loco is moving towards your named blocks then they could be A, B, C. Things will not happen as A, B, C as MetmanUK took time to explain, to many other things will happen on your layout at once... each one caused by an item passing over a sensor.

 

You will also remember I said to you that sensors will not be tripped, (that could be your definition for the action) they will activate when a recognisable tag passes over them, it will read the tag and send the packet of information back for processing. The two items of data mentioned above Sensor ID and Tag ID (for every tag read at 'random').

 

Come away from BD hosh, not all sensors will change points, not all sensors will change signals, not all sensors will be Block Marker Positions. LD will be much more flexible than BD.

 

Sensors could be used for Block marker positions, positions that simulate the block entry and exit positions. This we agree but other sensors may be used, as St1ingr4y has stated at the entrance to a station. This may not be a Block Marker Sensor it could be an additional sensor, these could be anywhere for what ever reason we choose. They could be in sidings to stop a loco before a buffer and used for nothing else. Although this same sensor could be used for horn, brake noise, release steam valves, etc, etc.

 

Not all sensors are block Sensors, we may have intermediate ones for speed control. The choice is down to each individual as to what that person sees best for their layout. You will be able to do as little, or as much, as you wish with LD, LD will be much more than a Block Detection system.

 

[hosh]

@hosh

"At this point RM not only "knows" but is using this knowledge about the relative positions of sensors and other devices relative to them."

The only knowledge RM has of their relative positions is their x,y co-ordinates to enable them to be displayed on the screen. RM does not use this knowledge to determine the relative position of these items to each other with respect to train movements.

Ray

So it will not be implied in the program (route) for every single train?

e.g.

sensor A tripped, set signals, set points for sensor B, stop/continue, etc

sensor B tripped, set signals, set points for sensor C, stop/continue, etc

sensor C tripped, set signals, set points for sensor D, stop/continue, etc

etc.

So here we see the implied relative positions of the sensors with every train's program. A program previously saved to RM and presently being run by it.

Btw, PJ has said the programs won't look like this - I'm waiting patiently for him or anyone else to tell us how they will look. :)

hosh

What I said was... that we will no doubt have many trains/locos running at once, these will pass over sensors at 'random', as will last carriages, wagons or guards vans. Each will send back a small packet of information, namely the sensor ID and the loco (or other item) tag ID.

 

 

Sorry, but there will be nothing "random" about the way locos trip sensors at all. They will be sent to that sensor by instructions triggered by the previous sensor.

 

I was trying to get your mind from everything happening as A, B, C although I appreciate if that is what you have called your blocks, and your 'one' loco is moving towards your named blocks then they could be A, B, C. Things will not happen as A, B, C as MetmanUK took time to explain, to many other things will happen on your layout at once... each one caused by an item passing over a sensor.

 

Yes, and they will pass over that sensor because of the instructions issued by the tripping of the previous sensor. And it will be in the order of A, B, C if so programmed - where's the hard part to understand? Nothing will happen at once. Computers do nothing "at once". It's all a procedure. It might happen so fast it apears that way but each instruction will be issued in order.

You will also remember I said to you that sensors will not be tripped, (that could be your definition for the action) they will activate when a recognisable tag passes over them, it will read the tag and send the packet of information back for processing. The two items of data mentioned above Sensor ID and Tag ID (for every tag read at 'random').

 

If the sensors don't get tripped then they must be faulty.

 

Come away from BD hosh, not all sensors will change points, not all sensors will change signals, not all sensors will be Block Marker Positions. LD will be much more flexible than BD.

 

What has BD vs LD got to do with anything? There is no difference and I've been specifically talking about LD anyway. Have you read and understood a word I've written?

 

Sensors could be used for Block marker positions, positions that simulate the block entry and exit positions. This we agree but other sensors may be used, as St1ingr4y has stated at the entrance to a station. This may not be a Block Marker Sensor it could be an additional sensor, these could be anywhere for what ever reason we choose. They could be in sidings to stop a loco before a buffer and used for nothing else. Although this same sensor could be used for horn, brake noise, release steam valves, etc, etc.

 

And your point is?

 

Not all sensors are block Sensors, we may have intermediate ones for speed control. The choice is down to each individual as to what that person sees best for their layout. You will be able to do as little, or as much, as you wish with LD, LD will be much more than a Block Detection system.

 

And your point is?

 

So do you have an example of how this wonderous and mysterious "event driven" system is going to work?

[NormanQ4]

Zzzzzzzzzzzzzzzzzz will someone please wake me when all this nonsense is done?

Page 22!!! why don't you just agree to disagree, surely you "experts" are smart enough to see that there is not going to be a winner in this debate.

Put it to bed, kiss and make up.

[hosh]

Zzzzzzzzzzzzzzzzzz will someone please wake me when all this nonsense is done?

Page 22!!! why don't you just agree to disagree, surely you "experts" are smart enough to see that there is not going to be a winner in this debate.

Put it to bed, kiss and make up.

 

LOL.

 

Well it seems that it has degenerated to a mere competition - I just don't know what about. I am simply trying to understand what some others are saying but as it goes along it just gets weirder and weirder! (shrugs).

[MetmanUK]

Yes, and they will pass over that sensor because of the instructions issued by the tripping of the previous sensor. And it will be in the order of A, B, C if so programmed - where's the hard part to understand? Nothing will happen at once. Computers do nothing "at once". It's all a procedure. It might happen so fast it apears that way but each instruction will be issued in order.

Factually incorrect.

 

(Sorry if that count as a negative comment, Admin)

[PJ_model_trains]

Dear hosh, or Oh dear hosh that may be the question!

 

If I had hair I would now be bald. If I resorted to banging my head against a wall I would have probably damaged the wall!  Joking aside...

 

All we have 'all' tried to do hosh is come up with different ways to explain LD to you but you are blinkered with your own ideas and BD that you don't seem to want to even consider what is said. One could write an essay on the incorrect thinking you have stated above but, it is clear it would be a waste of time.

 

Christmas is coming the forum thread is getting fat,

no agreement on LD maybe fishy will eat his hat,

someone is playing a blinder and doesn't understand,

Is it possibly a wind up, or maybe LD is closer at hand

 

If it was it could some people out of their misery, I think   :~]

 

One question hosh, do you think based on what you feel you know now, that BD is best and LD is of no use to you?

 

Happy Christmas ;o)

 

[RDS]

... you "experts" ...

 

At times like this it is always worth remembering the definition of an expert:

An 'ex' is a has been and a 'spurt' is a drip under pressure.

 

[PJ_model_trains]

My wife has just had some Christmas music playing, a well known tune, one we all know no doubt, I tried to listen to the words with my hearing aid taken out  ;o)

 

It was I think...

 

Here it is Merry Christmas everybody's having fun

Look to the future now, a wind up has just begun...

 

On Christmas day hosh is going to say... there you are see, I managed to wind you all up didn't I?

 

In true form for this time of year our reply has to be... Oh no you didn't!!!

 

[Yelrow]

PJ, for a person who declared himself out, you have been drawn back in. This whole thread, in my view is being deliberately, misunderstood, and not for the first time.  My mother used to say i was born holding a wooden spoon, as i loved stiring things up. Methinks the same applies here. john

[PJ_model_trains]

Hi John

 

You are so right, drawn back in!  I only replied because of hosh's statement...

 

Btw, PJ has said the programs won't look like this - I'm waiting patiently for him or anyone else to tell us how they will look. :)

 

I must admit after the last statement from him it appears he is not just failing to grasp what LD will do, he has gone round and round so many times he has further confused himself, hence the statement, it would take an essay to explain but if he aint got it now he aint going to get it.

 

The best for hosh, I mean it sincerely, is for him to wait and see.

 

My conclusion is, there is only so much we can do and say, and a lot of people have tried so many different ways to explain.

 

And if you don't mind me saying young man, put that spoon away, no stirring allowed, unless you have mixed your drinks ;o)

 

[MetmanUK]

PJ, for a person who declared himself out, you have been drawn back in. This whole thread, in my view is being deliberately, misunderstood, and not for the first time.  My mother used to say i was born holding a wooden spoon, as i loved stiring things up. Methinks the same applies here. john

Be careful !   The admin police will be after you for suggesting that !    ;-)

[hosh]

One question hosh, do you think based on what you feel you know now, that BD is best and LD is of no use to you? 

 

The BD vs LD concept hasn't been in play for pages.

 

People imply that LD will be so much different or better due to sending the loco ID back to RM. The fact is that all automated systems keep track of every train on the layout anyway and know where everything is, where it's headed, what it's dong and where it's been. So how will LD be different ot better?

 

People are using terms like "random" toward a system that is supposed to be anything but random - the entire purpose of automation is to control everything on the layout - random = collisions.

 

People say things won't be procedural - how can a train be automated without a procedural set of commands occuring as it trips each sensor on it's route.

 

People use expressions like "event driven" as though there is such a thing as any automated system that can be anything other than "event driven" (sensors trip and commands issued) as though LD will be special in this way somehow.

 

I propose a way that LD might work using programs for each train and people say it won't work that way but seem to have no idea how it will work.

 

So where is any of this stuff coming from - have Hornby alluded to some sort of "event driven" system and qualified exactly what this means or are people just making stuff up?