LD (Loco Detection) v BD (Block Detection)

[hosh]

RM doesn't need to be or do anything more than it already is, apart from adding the LD hardware.  It is fine as is.

 

And I meant what I said.  RM doesn't know, literally or otherwise, where anything is, but it also doesn't need to know, because we do.  We can look at the layout itself, and the schematic, then program such things as block simulation using only the capability already in RM.  Just as HB, PJ and I have detailed for you above.

 

Sorry, but we'll have to agree to disagree on this point of view. Afaic, RM now knows because we told (programed) it.

 

And let me ask you again - what would RM need to do to have you refer to it as "knowing" where stuff is? It knows what loco is at what detector - it simply does know! LOL

 

You could even label it with a GPS positioning label if you wanted! LOL.

[hosh]

Here's a question - if you have no actual physical signals on your layout, can RM still set a signal at a sensor as though one did exist?

 

In other words, can you set a signal to red even though one doesn't actually exist and thus, when a train passes the sensor where that signal would be if it existed, it tells the train to stop?

[RDS]

... if you have no actual physical signals on your layout, can RM still set a signal at a sensor as though one did exist ...

Yes, of course.

[hosh]

... if you have no actual physical signals on your layout, can RM still set a signal at a sensor as though one did exist ...

Yes, of course.

 

Good to know - would be bad to be forced to have signals.

[Howbi]

So, Hosh............what address would you give to the non-existant decoder of the non-existant signal that you expect RM to send a command to..............it's like sending an invisible postcard to an invisible house,  hahha. HB

[hosh]

So, Hosh............what address would you give to the non-existant decoder of the non-existant signal that you expect RM to send a command to..............it's like sending an invisible postcard to an invisible house,  hahha. HB

 

It seems people have become overly "clever" on this issue.

 

As RM stands now, RM has no idea about locations because there are no sensors. But when LD is released, and RM is working with sensors, then RM knows where stuff is - that's the whole point! LOL

 

The sensor IS THE LOCATION. Then points, signals, etc are associated with that sensor and thus it's location!

 

Points are special though - they define the boudaries between zones along with other potential stopping places like the ends of stations, sidings, etc.

[PJ_model_trains]

Hi guys

 

I read carefully the comments regarding what RM understands and doesn't understand and see that, not just now, but for months, the arguments seem to go round and round more times than my trains.

 

I think sometimes there is a fine line between 'what is meant' by the persons messsage for or against and that of the person replying. Can I try and put this another way (and see what happens)?

 

Firstly RM knows what is where, one can argue yes it does because it is on the screen and the position on the screen is an x-y co-ordinate. So that arguement could be yes it does know but, it doesn't necessarily remember this from the point of view of doing something with the item or processing other instructions. e.g RM know a piece or track or point is at a set place on the screen and it can put it there everytime we open the software and view it on screen. But, that is all it does, this icon/piece at that x-y co-ordinate on the screen and another at another x-y co-ordinate.

 

Now to look at the other argument, RM doesn't know what is where. make a list of all your point addresses and add these at the top of the screen. Next make a list of all your signal addresses and add these at the bottom of the screen. Note your train CV's and list them down the left of the screen, etc. They are just numbers on a screen and that is really what RM understands. A bit like a jigsaw upside down with no edge peices. They could be annywhere on the screen but, if we add numbers to them we can organise them in a way that we can 'use/play' with them. Hence the schematic layout.

 

Another example could possibly be that the computer knowws binary code (and more), code we do not see, but on screen these are items we can understand and use, whether they are characters from a keyboard or the icons for track and points etc in RM. Software is the translator, turning items the system knows as maybe 01010101 into things we can 'SEE' and 'USE' to do so much more.

 

[PJ_model_trains]

Hi hosh

 

You use the term zone, easy mistake I have done so in the past after reading other notes and comments elsewhere.  They are actually Blocks not zones. Not being picky here, please do not think that, I am just aiming for us all to speak the same language/terminology, so that we all understand, especially this time of year as this is when the forum gets more new members.

 

The main difference between LD and BD when considering and installing blocks is that, BD are actual blocks created using isolating fishplates and LD is a simulated block by using sensors. (you are aware of this) But in real terms they are both blocks, a section of track between two isolation points or a section of track between two sensors.

 

Note: the user can use sensors for different things, they are not just for creating simulated blocks. For example, a user may first divide their track lengths or loops into blocks and install those sensors. The user will probably also install additional sensors, station stopping sensors, siding stopping sensors, speed adjusting stopping sensors etc. The system will be very flexible and it will be down each person, their layout, their imagination, their requirements from their prosptective and their wallet how far the do or do not want to go.

 

[96RAF]

on screen bits are purely for the better understanding of the operator. X,y,z coordinates mean nothing to the machine except to say where it is on screen.

you could for example delete every bit of straight track from your plan, move all your points into a line side by side or top to bottom but separated and your layout would still work as it did before with the pretty plan.

when LD comes along and you have sensors on track the same will apply.

rm uses the ID you give points and sensors not their actual location to run in its logic.

[PJ_model_trains]

Spot on RAF

 

Another example... when I am testing signals I sometimes create a new file and just add a string or signals

in the order I want to test them.

 

No track pieces on screen or anything else just the signal icons, RM only knows they are image files and the ports I have allocate to them.

The signal aspects only change if I give an instruction to do so or program them to change as required through the software.

 

[PJ_model_trains]

@magfan / @hosh

 

It is very kind of you to go to the trouble of showing the various sensors but, to me it doesn't really matter.

 

All I need to know is...

• that I install the sensors provided with LD in the track in accordance with the instructions.
• I wire it from the sensors to the LD controller as recommended
• I connect the LD controller to the PC using the USB cable provided
• I install software for it if requested to and set the USB com port if I need to
• I add LD sensor icons to our track on screen that represents the position on the layout (I have done that already)
• I add tags to the underside of loco's, tenders, wagons, carriages, guards van and program them in RM
• I test each sensor one by one to make sure they are working

 

Thats about it I am then ready to start programming sensors with signals and points for general running or routes and start to play ;-)

 

What type of sensor, whether it is reading a bar code or uses another method doesn't really matter, all that matters (to me) is I know how to install and program the parts and that it works. My only other consideration which has been considered already is the aesthetics and with small sensors as we are told so far that is not a concern at all.

 

This leaves me with maybe the odd consideration

• When is it coming and how much is it going to be
• Has another system come out already that could be better or easier

And finally maybe my main concern

• Has anyone experienced issues with the system, particularly the fitting of tags to the underside of the above items, the right distance from the sensor, without damaging or scuffing the info on the tags.

Keeping sensors clean will always be paramount with any upward facing sensor system.

 

[Yelrow]

PJ, hi, bearing in mind how long it took yo install your signals, and given the eventual release of LD, and  then the inordinate amount of time its going to take you to install it, given the present location of your layout, you need, as a matter of early consideration, to come up with a hoist/  simple way of keeping your layout handy. To this end, have you weighed it, as i weighed my wifes washing on her line this morning, and came up, with about 19 kilos. It was not full. john

[PJ_model_trains]

PJ, hi, bearing in mind how long it took yo install your signals, and given the eventual release of LD, and  then the inordinate amount of time its going to take you to install it, given the present location of your layout, you need, as a matter of early consideration, to come up with a hoist/  simple way of keeping your layout handy. To this end, have you weighed it, as i weighed my wifes washing on her line this morning, and came up, with about 19 kilos. It was not full. john

 

Ermmm

Sounds like your wallet was still in your pants John

Sorry John, I re-read your message... it is your wife's washing not yours!

She obviously has your wallet in her pants, I mean washed items  ;o)

 

[PJ_model_trains]

Christmas is just arround the corner,

wouldn't it be nice if on Christmas Day we looked in our Christmas stockings and heard the Christmas song...

 

Here it is Merry Christmas everbody's having fun.

Look at your presents now...  LD has just begun.

 

Dream on ;o)

 

Maybe the second line of the song is more apt...

Look to the future now its only just begun!    (2012 and still looking) 

 

Joke all meant in good fun, I think.

 

[hosh]

when LD comes along and you have sensors on track the same will apply.

rm uses the ID you give points and sensors not their actual location to run in its logic.

 

Yes, of course. And all those will be associated with the sensor/s in that location in general.

 

The whole reason to put a sensor somewhere is to generally stop a train. This happens at -

• points
• stations
• sidings
• signals

All of the above will also usually be associated with a signal. So we stop at signals.

 

So, for example, to look at the typical case of a point, it's associated signal and associated sensor/s, a loco trips the sensor, RM looks at the signal and points and instructs all 3 (the loco, points and signal) as per the programming of the user considering the state at that time. This all happens in the sensor's location and any points, signals, etc that are the reason for that sensor being there in the first place are associated with it's location. It's just that simple. :)

 

This is simple for me - a sensor/s (by singular/plural I mean maybe the user needs 2 sensors - one to slow the train and another to stop it dead) represents a location and is usually associated with signals, points, stations, sidings, etc.

 

Why make mountains out of mole hills? RM with LD is blind, RM with LD sees - that's why they're called SENSors.

 

You fellas need to come to your sensors! LOL

[hosh]

You use the term zone, easy mistake I have done so in the past after reading other notes and comments elsewhere.  They are actually Blocks not zones. Not being picky here, please do not think that, I am just aiming for us all to speak the same language/terminology, so that we all understand, especially this time of year as this is when the forum gets more new members.

 

Who cares - what's the difference? In the context of this conversation I don't envisage anyone getting confused.

 

How can the use of the word "zone" lead to any confusion - power zones on a DC layout?

 

Please! Enough with the dinosaur concepts! LOL

 

I can't imagine how confusing a noob must find all the pedantism and incorrect perspectives of those who simply overthink everything and try to be way too clever!

[PJ_model_trains]

The whole reason to put a sensor somewhere is to generally stop a train. This happens at -

• points
• stations
• sidings
• signals

All of the above will also usually be associated with a signal. So we stop at signals.

 

Not necessarily hosh.

In most cases possibly so, but you are thinking on the lines of sensors for Block control only (I think)

 

Additional sensors can also be added in other locations, between Block sensors would be an example.

 

Why would I do that?

For speed control mainly but these sensors could do anything within the limits of the programming commands. Even make a clock chime sound (or fry a fireman's breakfast LOL)

 

I plan to use signals with LD to control speed as well as stopping locos before signals, in stations, or in sidings. Initially I would control them using back down the line signalling. Say a loco is running at 65mph and passes a Green/Clear signal the signal changes to Red/Stop. When the last carriage passes the same signal I would have the previous change to Y, the one before to YY and the one before that to G. But, I would also want to program the sensor instructions if signal Y or YY to reduce the speed of the loco.

 

At present the LD commands only allow for...

On signal green or On signal red not for

On signal Y or on signal YY but hopefully this will come.

Possibly I could just use Reduce loco speed to when a loco passes the signal but this would not be totally satisfactory as it is an overall instruction.

 

To be able to program for...

On signal Y --- Reduce loco speed to 30mph

On signal YY --- Reduce loco speed to 45mph

 

This would be most realist control speeds automatically reducing 'back down the line' in accordance with signal commands... Proceed with caution or proceed with extra caution.

 

It also ensures speed is reduced prior to arriving at a red signal.

 

This also works the other way... if two ttrains are on the same section of track, one could be running fater than the other therefore catch up to the one in front. The train ahead should have controlled the signals back down the line as well as protecting the block(s) it is in. As a reult the train catching up is slowed down because of the Y or YY aspects and speed changes because of their status.

 

>>> HRMS >>>

I also notice that the LD commands for speed change are only the ones mentioned above, what is not included are

accelerate to (x) mph

decelerate to (x) mph

 

So as it seems LD, based on current commands listed on page 9 of this thread as in RM now is only part way there.

 

We do not have commands for YY or Y signal aspects in the programming

We do not have accelerate or decerate to a speed commands

Unless of course they are adding these but are not yet in RM

 

Just to conclude on the other option for sensors other than for stopping, we may have a sensor at the entrance to a station and use it to set the speed of loco(s) just before entering the station. This is not a Block Sensor but an additional one used for other things. Speed control I think will be very important for locos stopping in the same pplace each time. By reducing loco speed before getting to the sensor requesting the loco to stop the position the train stops will be more accurate.

 

 

[hosh]

You completely detracted from the simple point I was making which was that sensing is associated with locations. Whether there is any other devices associated with a sensing area is irrelevant!

 

All the stuff regarding Y and YY signalling is understood.

 

As for accelerating/decelerating trains in a prototypical manner, can't the actual loco's decoders be set up to do that so that RM simply needs to give them a target speed?

[PJ_model_trains]

As for accelerating/decelerating trains in a prototypical manner, can't the actual loco's decoders be set up to do that so that RM simply needs to give them a target speed?

 

I am referring to acceleration/deceleration by program command rather than go to speed (x) mph

 

I use it in programming routes, I know another member does a lot. It is more realistic but, takes more time to build up (or reduce) speed. It is not realistic to see a loco doing 70mph then reduce to 40mph in one step, it also knocks sound out of sync for locos that have sound.

 

Just double checked these commands are in LD (List on page 9 of this thread)

Reduce loco speed to

Increase loco speed to

 

But the signal commands

On signal Y and

On signall YY are not 'yet' in the list and really should be included

 

RM includes for up to 4 aspect signals, LD should also

 

 

[PJ_model_trains]

As for accelerating/decelerating trains in a prototypical manner, can't the actual loco's decoders be set up to do that so that RM simply needs to give them a target speed?

 

Ignore this.. it was an edit of the last post!

System put all of your last message in last postt instead of this bit and on edit gave this as well as the above...  in two post?????

[Fishmanoz]

Having just spent some time reading the last day's worth of this and the How Does It Work thread, I think we might be getting close to a common understanding, although there is still some possibility we haven't. So let me see if I can eliminate any remaining doubts by putting some info a little differently to the way it has been put before.

 

Let's start with the schematic of the layout.  Clearly RM holds this in .PLN files and these files must have X,Y coordinates associated with them for every element that is on the schematic.  That includes when we add LD sensors, as we can do already.  When the layout is rendered on screen using these X,Y coordinates to put everything in its proper place, it is also possible for us to see the relationships between each of these elements.  We can see that particular elements are joined to each other in particular sequences represented by the lines of track on the screen.  However, given that all RM does is place each of the elements on screen in their X,Y positions, it doesn't need to hold the relationship between the elements (eg.  straight track A is connected to curve B is connected to RH point C etc) within the .PLN file to render the layout on screen.  So it is not necessary to hold in the file any information of the type which would allow it to be determined that a loco going in a particular direction arriving at sensor B has come from sensor A and is going to sensor C.

 

Now let's get outside the area of RM rendering the schematic on screen and into the part that actually carries out instructions to change points and signals, start and stop locos, receive detections from sensors, carry out the instructions included in the setup info for points, signals and sensors and finally run programs which do those things.  My point is that none, absolutely none, of that X,Y information from the schematic is available in the area carrying out these instructions.  Further, as there was no need to hold the relative positions of and connections between elements from the schematic in the first place, no such information can be available in the instruction area either.  So no instructions carried out can take account of absolute or relative positional information in the execution of those instructions.

 

That is what I mean when I say RM knows nothing about where anything is. I mean instructions cannot take account of such positional information in their execution.  However, when we include such instructions in the setup for points, signals and sensors, or in programs we wish RM to execute, all as part of automation of the layout, we do know where everything is so we can do the setups and write the programs taking positions, absolute and relative, into account.

 

Does that make it clearer for everyone, hosh in particular?

 

Finally, if we are agreed on this, can we also agree that we don't need any positional information in the setups and programs we use to fully automate our layouts, and the lack of it will not limit such automation?  I am convinced it won't. 

[hosh]

That is what I mean when I say RM knows nothing about where anything is. I mean instructions cannot take account of such positional information in their execution.  However, when we include such instructions in the setup for points, signals and sensors, or in programs we wish RM to execute, all as part of automation of the layout, we do know where everything is so we can do the setups and write the programs taking positions, absolute and relative, into account.

 

Does that make it clearer for everyone, hosh in particular?

 

No! LOL.

 

To imply that RM is no wiser after LD than before is making zero sense to me I'm afraid!

[Howbi]

@ hosh.............I don't think 'wisdom' is an attribute you can ascribe to RM or the Computer come to that. In the Human world, events can be affected by both wisdom and logic but in the Digital world only Logic is applied. HB.

[Fishmanoz]

RM is certainly more capable with LD because of all the conditional and unconditional things it can be programmed to do when detections are made at sensors.  However, I still don't believe any of this will require the inclusion of positional information on the layout to make RM achieve this increased capability.

[hosh]

To me the logic is pretty simple.

 

I have sensors that represent locations.

 

Let's consider location A and look in both directions from there, say north and south.

North of A I might have a point that leads to 2 potential locations, B and C.

South I might have 2 sets of points, one after the other, that lead to potential locations X, Y and Z.

 

So when I start thinking about scripting a route, it might be -

 

• BAZ (heading south)
• YAC (heading north)

etc. Every location (sensor or group of sensors) can be thought of this way and routes scripted accordingly.

 

Furthermore, such locations will typically be before a signal, which in turn is before a set of points for example. This means said signal and point is now also associated with that location and direction.

 

So a sensor designated as "A" could be associated with signal "A" and point/s "A". And thus RM now knows the location of locos and everything else.

 

Pre LD, RM has no notion of the location of anything - it simply runs programs when the user tells it to. It knows what train it is, but knows nothing of it's location or geographical direction.