What Might RM with LD Know about Positions in the Future

[Fishmanoz]

For those of you who agree that RM currently contains no positional information, and who have just read PJ's eloquent explanation in the Is This How LD Works thread as to how LD allows full automation of layouts in the absence of such information, and for those who have layouts with sensors included in them for trial purposes at present, can I ask you all to do something for me:

 

Please go into Layout Design in your trial layout, right click on a sensor and check what is now available in the line above the program area for the sensor.  You may find that has something to do with entry of an X and Y for the sensor, and those parameters can be the actual parameters on your real layout, as opposed to parameters on your schematic.

 

This may just answer the item in the manual on page 139 about knowing about where your trains are with LD.  But answer me this:  how does it help to know where a loco is on your layout at the instant of detection if that is all you know, and you don't know anything about the track connections between those isolated detection positions?

[hosh]

This may just answer the item in the manual on page 139 about knowing about where your trains are with LD.  But answer me this:  how does it help to know where a loco is on your layout at the instant of detection if that is all you know, and you don't know anything about the track connections between those isolated detection positions?

 

Well this is the whole point. We only need to know what "block" a sensor is in from a programming point of view.

 

And as far as I'm concerned, that's all that's meant by RM knowing where stuff is.

 

Can't see why they'd have an x,y co-ord for anything other than the RM schematic - what'd be the point? A name I can see, but an x,y co-ord?

[Fishmanoz]

There's no such thing as blocks hosh, although they can be simulated.  You could check if I'm wrong though by doing a search for block in the manual, you found loco positions on page 139.

 

But put a sensor in a track plan and report back on what you find in its setup, noting I said this thread applies to those who have done that so they can see for themselves.

 

And why would you need to enter coordinates for where a sensor is on a track plan, that you can already see on screen?

[St1ngr4y]

EVERY item which is placed onto a layout diagram is stored in the .PLN file with the x,y co-ordinates of it's cell on the diagram, so these co-ordinates shouldn't be for the sensor itself.

Ray

[hosh]

There's no such thing as blocks hosh, although they can be simulated.  You could check if I'm wrong though by doing a search for block in the manual, you found loco positions on page 139.

 

By "blocks" i simply mean the primary sections of track basically separated by points, stations, etc.

 

From any given block, for any given direction, you can go into X other blocks - that's the only info ever needed to give a train a route.

 

My point in pointing out Hornby's vernacular on page 139 was to show that it's the typical way to refer to a system that's fed specific info - the system is said to "know".

 

People need to see RM plus LD as just the RM "system" and stop being so clever and confusing the stuffing out of everything! LOL. All this stuff about sensors or RM itself not knowing where stuff is is just nonsense!

[PJ_model_trains]

Please go into Layout Design in your trial layout, right click on a sensor and check what is now available in the line above the program area for the sensor.  You may find that has something to do with entry of an X and Y for the sensor, and those parameters can be the actual parameters on your real layout, as opposed to parameters on your schematic.

 

I cannot open RM at this stage as my system is down to the New Year. Well actually stood up but it is down if you know what I mean ;o) Just thought I would throw that in.  ;o)

 

Now the X, Y exlpanation above baffles me a bit in your explanation. To me the X, Y co-ordinates are ONLY for the PC system to be able to redraw the screen, putting everything back where it was on the screen. How they relate to the Real Layout I do not understand at all?

 

[PJ_model_trains]

 

And as far as I'm concerned, that's all that's meant by RM knowing where stuff is.

 

Can't see why they'd have an x,y co-ord for anything other than the RM schematic - what'd be the point? A name I can see, but an x,y co-ord?

 

We agree on this hosh, the X, Y co-ordinate is the position on a screen, used to re-draw the screen, putting bits in the places we put them when we designed our Schematic Layout.

 

 

[PJ_model_trains]

There's no such thing as blocks hosh, although they can be simulated.

 

And why would you need to enter coordinates for where a sensor is on a track plan, that you can already see on screen?

 

Blocks in BD are 'created' to separate sections of track for 'controlling locos' isolating one section of track from another section of track. (This of course we know but is not like the real railway system it is a method of controlling our model trains)

 

Blocks in LD however are simulated, instead of having isolation track joiners separating two sections of live track in BD, we have sensors between the rails in LD which are in effect 'Block Marker Sensors'. The track remains live from block to block the Block Sensors create for us simulated blocks.

 

The main difference is that BD controls power to, or not to, blocks of track. LD provides sensors which we can use with RM to give program instructions to our locos.

 

I feel LD is more natural than BD, although this is just my view. ;o) On mainline railway the engine driver controls (forward, reverse, stop) for a loco, which we do through RM. The loco goes from A to B between simulated blocks, the gap between signals. The signals give the train driver guidance to safe driving, e.g. Red light Stop the track/block ahead is occupied, Yellow Light proceed into next block with extra caution, two Yellow lights proceed into next block with caution, Green light the track/block ahead is clear. These would be the basic safe driving, visual items every train driver would be watching for, signal to signal, block to block as the train runs it's journey. Additionally there may of course be AWS alarms proir to signals, that the driver has to respond to, but these are advanced safety warning system items.

 

The basic of block simulation is as above, signal to signal mainline railway, block sensor to another sensor (simulated) on our RM controlled railway using LD purely for sensing locos to be able to provide through RM pre-programmed instructions. Signals naturallly being placed close to block sensors etc.

[PJ_model_trains]

There's no such thing as blocks hosh, although they can be simulated.  You could check if I'm wrong though by doing a search for block in the manual, you found loco positions on page 139.

 

By "blocks" i simply mean the primary sections of track basically separated by points, stations, etc.

 

From any given block, for any given direction, you can go into X other blocks - that's the only info ever needed to give a train a route.

 

My point in pointing out Hornby's vernacular on page 139 was to show that it's the typical way to refer to a system that's fed specific info - the system is said to "know".

 

People need to see RM plus LD as just the RM "system" and stop being so clever and confusing the stuffing out of everything! LOL. All this stuff about sensors or RM itself not knowing where stuff is is just nonsense!

 

Blocks would be better defined by saying, it is the section of track between two chosen positions on our track. In the case of using LD it would be the section of track between two sensors, which creates the simulated block between those two locations.  Not necessarily as you say... separated by points, stations, etc

 

Each person, subject to their track design, would need to decide where they put their sensors in conjunction with points, etc. Some may decide they need an additional sensor (not a block marker sensor) for additional control on some sections, for example, stopping at the exit of a station or even entering one for reducing speed, or stopping near the end of a siding etc.

 

LD is very flexible, but because everyones track is different, we will all put our sensors in positions best suited to out layout. The rule of thumb for Block Sensors is that the distance between the these sensor should be slightly longer than a persons rake of loco/carriages or loco/wagons/guards van.

 

Regarding your last statement, I disagree totally, as do many others on here. RM is your model railway operating system, LD is an additional item to aid running your trains more effectively, all LD does is send back to RM a packet of data for it to process every time a sensor is passed over, that packet of data includes just two small items of data, Sensor ID and Tag ID.

 

You do not need LD to run your locos, but by adding LD when avaialable, it will be 'an addition' to the RM system, an add on, to help us do much more. It will be a separate controller, we wire the sensors back to the LD controller then add to our system with a USB cable, plug and play addition, it is an extra to RM not actaully part of RM. RM will have, as it has now, commands for those who want LD but it is not an essential part of RM.

 

[PJ_model_trains]

What Might RM with LD Know about Positions in the Future

 

This is an interesting one... I think. ;o)

 

Example: take a layout, standard oval. Lets say 4x straight track, leading to 4x bends either end and 4x straight track joining the other end of the bends to make the oval.

 

The above oval has 4x Block Marker Sensors evenly distributed. Lets say either end of the straights so that one simulated block is the length of 4x straight track, the next is the 4x bends, the next is the 4x straights, the next the 4x bends, oval complete, 4 blocks simulated.

 

At present we have track in our schematic layout of a set colour, each peice of track is just an icon image in a set position on the screen.

 

Imagine if RM allowed us to... Click on all the pieces in a Block and group then. e.g. straights 1, 2, 3 & 4. This creates a Block on screen. Next do the 4 bends bends 1, 2, 3, 4 and group as another block, then the next 4 straights grouped as another block 5, 6, 7, 8, then the other 4 blends grouped as the fourth block, bends 5, 6, 7, 8. All RM knows at this stage is there are 4 Blocks on screen, in the postions we have placed and grouped them.

 

It is how RM is programmed to do this grouping and using the data from LD so that can give us a visual representation on screen showing blocks which are occupied! How, by changing the colour of the group of track pieces on screen when a loco has gone over a sensor on the layout. A Block could be the colour it is now for occupied and white or light green when clear. The blocks wouldn't need to represent the various signal aspects of R, Y, YY, G the two options above would give a visual representation of a Block on our schematic layout as occupied or Clear. There could also be an option in RM or ini file to turn this on or off for those who do not want it.

 

Room for thought I think. After all the control rooms for the railway network have sections that light up and give information to the controller.

 

[St1ngr4y]

Please go into Layout Design in your trial layout, right click on a sensor and check what is now available in the line above the program area for the sensor.  You may find that has something to do with entry of an X and Y for the sensor, and those parameters can be the actual parameters on your real layout, as opposed to parameters on your schematic.

 

Well spotted Fishy. I notice that the letters "cm" appear after the description in the sensor setup, so they must be describing a distance from some other point - but which point. This picture shows a sensor I created this morning. It must be still work in progress, as I entered the numbers 25,35 in the "Position (X,Y) cm:" box, but when the parameters box was re-displayed later, these numbers were shown in the wrong place, as you can see:-

/media/tinymce_upload/dc6aeb4cecc864673c76d498a44af6c7.png

 

Ray

[Fishmanoz]

EVERY item which is placed onto a layout diagram is stored in the .PLN file with the x,y co-ordinates of it's cell on the diagram, so these co-ordinates shouldn't be for the sensor itself.

Ray

 

Ray, returning to your observation about layout diagrams or schematics stored in .PLN files.

 

I agree with everything you've said except the last clause.  If everything is in a cell (everything is, including sensors) with X,Y coordinates, why then would you want to repeat those coordinates in the sensor setup along with sensor number, LDM number and port number?  To me, these coordinates must be something different, and the only something different I can think of is the actual X,Y coordinates on the layout itself.

 

But here I come to a halt as I can't see the reason for knowing the position of sensors if you don't also know the position of other things.  And I haven't noticed the setup for other things also having a place to put X,Y coordinates.  And the little bird which gave me the clue to look in the sensor setup wasn't forthcoming on anything else either.

[Fishmanoz]

PJ, just on the info sent back on a detection being made - the sensor doesn't have to send its ID, that is already in its setup along with the port it is connected to.  It does of course send back loco ID and we are told it also sends speed and direction.  I was having trouble with direction as it is meaningless without other positional information.  Now we sre apparently to have sensor position so maybe direction starts to make sense.

[hosh]

EVERY item which is placed onto a layout diagram is stored in the .PLN file with the x,y co-ordinates of it's cell on the diagram, so these co-ordinates shouldn't be for the sensor itself.

Ray

 

Ray, returning to your observation about layout diagrams or schematics stored in .PLN files.

 

I agree with everything you've said except the last clause.  If everything is in a cell (everything is, including sensors) with X,Y coordinates, why then would you want to repeat those coordinates in the sensor setup along with sensor number, LDM number and port number?  To me, these coordinates must be something different, and the only something different I can think of is the actual X,Y coordinates on the layout itself.

 

But here I come to a halt as I can't see the reason for knowing the position of sensors if you don't also know the position of other things.  And I haven't noticed the setup for other things also having a place to put X,Y coordinates.  And the little bird which gave me the clue to look in the sensor setup wasn't forthcoming on anything else either.

 

Is it possible that you need to match those co-ordinates to the ones in the schematic so that RM knows what sensor is where? Just to synch them?

 

So you place a sensor on the RM schematic at x,y and then when you install the sensor you allocate a sensor at that x,y co-ord in the sensor setup window?

 

Sorry if this is junk since my demo has expired.

[PJ_model_trains]

EVERY item which is placed onto a layout diagram is stored in the .PLN file with the x,y co-ordinates of it's cell on the diagram, so these co-ordinates shouldn't be for the sensor itself.

Ray

 

Ray, returning to your observation about layout diagrams or schematics stored in .PLN files.

 

I agree with everything you've said except the last clause.  If everything is in a cell (everything is, including sensors) with X,Y coordinates, why then would you want to repeat those coordinates in the sensor setup along with sensor number, LDM number and port number?  To me, these coordinates must be something different, and the only something different I can think of is the actual X,Y coordinates on the layout itself.

 

But here I come to a halt as I can't see the reason for knowing the position of sensors if you don't also know the position of other things.  And I haven't noticed the setup for other things also having a place to put X,Y coordinates.  And the little bird which gave me the clue to look in the sensor setup wasn't forthcoming on anything else either.

 

Unfortunately I am not getting this? Possibly not understanding what you are trying to say?

 

The schematic layout is only a proportional representation of our layout, not a scale of the original. So if one doesn't match the other in scale what use would the screen x,y co-ordinates be?

 

Loco speed? - as it is only a schematic layout on screen, not reflecting a scale of the layout surely it cannot be used to calculate speed

 

Loco direction? - if a loco is going forward (instruction in RM) when it passes sensor A, logically it would be going forward when it passes the next sensor. If the loco is going in reverse (instruction in RM) then it is going in reverse when it meets the next sensor. (unless there was a turntable in the middle of that run of track)

 

So based on the above we are back where we started, RM already knows speed and direction of a loco why would we even consider LD to provide the same information. LD is a slave to RM nothing more.

 

I may however have missed something in the explanation regarding the screen x,y co-ordinates and those stored in/for the LD sensor? If so please try another route of explanation.   LOL

 

 

[PJ_model_trains]

PJ, just on the info sent back on a detection being made - the sensor doesn't have to send its ID, that is already in its setup along with the port it is connected to.  It does of course send back loco ID and we are told it also sends speed and direction.  I was having trouble with direction as it is meaningless without other positional information.  Now we sre apparently to have sensor position so maybe direction starts to make sense.

 

We have been saying for a while the sensor sends back two items of data, the sensor ID and the loco tag ID, I must admit in writing to hosh earlier today it became clear that the system already knows the sensor ID so really only needs to know loco (or other ittem) tag ID that passed over the sensor. But I steered away from creating further confusion.  ;o)

 

Here also we are seeing what RM already knows, information already in RM in what we have previously set up.

 

LD is getting simpler by the minute!!! Wait for someone now to comment on Hornby justifying the price. LOL Research, testing, technical support etc, etc, etc.

 

As for direction of a loco, I am still in the RM knows stage, and asking again why would LD provide information for what RM already knows, LD it is only a delivery system for sensor data as received randomly as items pass over them.

[PJ_model_trains]

PJ, just on the info sent back on a detection being made - the sensor doesn't have to send its ID, that is already in its setup along with the port it is connected to.  It does of course send back loco ID and we are told it also sends speed and direction.  I was having trouble with direction as it is meaningless without other positional information.  Now we sre apparently to have sensor position so maybe direction starts to make sense.

Regarding the high-lighted statement above, does it really send back speed and direction?

 

I am still of a mind, why would LD waste time sending back to RM information it already knows?

 

The fact that the User Guide says it may not be that LD actually does it. There have been mistakes before, we are all human, it could also make LD sound good. ;o) My wife says Oh you are suspicious. LOL

 

Two things I think are certain at this stage...

- Hornby are not going to say yet

- If it does send back information already know to RM there has to be a reason (doing things twice when whether needed or not carries with it additional risks!)

 

I have always viewed doing things twice as a waste of time and money and risky.

 

 

[Fishmanoz]

Hosh, on the placement of sensors:

 

When you put a sensor on your schematic, you drag and drop a sensor icon onto a specific piece of track.  All pieces of track are in cells to which you dragged and dropped them previously, and the x,y coordinates of those cells are known.  So the x,y coordinates of the sensor are known.

 

But which sensor?  That you specify by right clicking on the sensor and doing its setup.  You first say which sensor number it is, what LD module (LDM, one of 2 you can have) it is to be connected to, and what port number it is to be allocated to (1 of 48).  This is all that is needed to fully specify the sensor.  We don't need to separately tell RM its x,y coordinates, the setup was done to the specific sensor in that cell on the schematic.

 

So again, given we can also identify x, y coordinates as part of the setup, and there is no point these being the cell coordinates because these are known, I believe these must be actual layout coordinates.   I could of course be wrong, it is speculation on my part, but I can see no reason for duplicating the known cell coordinates.

 

PS.  Also to be clear, it is within that same setup that we specify the subsequent actions that can be made when a detection occurs, using the previously published extensive set of conditional instructions.

[Fishmanoz]

PJ, on speed and direction:

 

First on speed, I agree the throttle information contains this, so why get LD to transmit it separately?  Well, if on being detected, a loco has only just been programmed to change speed, it may still be subject to acceleration  or deceleration.  Consequently, an accurate speed determination can only be made by calculating what speed it started from, what speed it is changing to, how long it will take to change (which will mean knowing what the accel/ decel CVs are set to), and how long it has actually been changing. All of that is straightforward, it's simple Newtonian laws of motion.  But rather than collecting and keeping all that information and doing the calculations, wouldn't it be easier to simply record time to pass the sensor and convert that to instantaneous speed, without having to worry about accelerations?

 

On direction, clearly there is a forward or reverse set in the throttle.  But we already know if there is a reversing loop, a loco can pass a sensor just outside the loop, then proceed around the loop without changing its throttle direction, and arrive back at that same sensor heading the other way.  So I think direction of passing over a sensor provides information not necessarily available  from the throttle.

[RDS]

...  I always viewed doing things twice as a waste of time and money and risky ...

 

Hmm, not so sure about that one.  'Measure Twice, Cut Once, springs immediately to mind!' 

[St1ngr4y]

EVERY item which is placed onto a layout diagram is stored in the .PLN file with the x,y co-ordinates of it's cell on the diagram, so these co-ordinates shouldn't be for the sensor itself.

Ray

 

I agree with everything you've said except the last clause.  .............  To me, these coordinates must be something different, and the only something different I can think of is the actual X,Y coordinates on the layout itself.

 

That's exactly what I was trying to say in that post, Fishy :-) Since then I have posted another message on this topic, which includes a picture of the sensor setup in the Layout Designer. In that post I point out that "cm:" is displayed at the end of the field description, which suggests to me even more that these co-ordinates are relative to something else measured in centimeters, rather than screen pixels - but to what ? - I am open to suggestions.

Ray

[St1ngr4y]

PJ, just on the info sent back on a detection being made - the sensor doesn't have to send its ID, that is already in its setup along with the port it is connected to.  It does of course send back loco ID and we are told it also sends speed and direction.  I was having trouble with direction as it is meaningless without other positional information.  Now we sre apparently to have sensor position so maybe direction starts to make sense.

 

We have been saying for a while the sensor sends back two items of data, the sensor ID and the loco tag ID, I must admit in writing to hosh earlier today it became clear that the system already knows the sensor ID so really only needs to know loco (or other ittem) tag ID that passed over the sensor. But I steered away from creating further confusion.  ;o)

 

PJ,

The packet of information sent by a sensor to the controller MUST contain at least the sensor id and the loco id. If the sensor id wasn't there, how would the system know which sensor had been tripped?

Ray

[PJ_model_trains]

...  I always viewed doing things twice as a waste of time and money and risky ...

 

Hmm, not so sure about that one.  'Measure Twice, Cut Once, springs immediately to mind!' 

 

Nice one RDS  ;o)

 

But having worked for local authority for almost 11 years and seen duplication and waste, I always apply the term 'what price checking'. Some things are cost effective to check twice as you point out in your example but others double or triple the cost of a task or job. Hence 'What price checking'

 

Having also been in business prior to the LA post and since the LA post, I was always conscious of time wasted can be money wasted. Never put two people on a job if one person can do it. Accountability also comes in here.

 

Hence another term in business, if you are doing things that cost you money you are not making money.   ;o)

 

[PJ_model_trains]

...  I always viewed doing things twice as a waste of time and money and risky ...

 

Hmm, not so sure about that one.  'Measure Twice, Cut Once, springs immediately to mind!' 

 

Nice one RDS  ;o)

 

But having worked for local authority for almost 11 years and seen duplication and waste, I always apply the term 'what price checking'. Some things are cost effective to check twice as you point out in your example but others double or triple the cost of a task or job. Hence 'What price checking'

 

Having also been in business prior to the LA post and since the LA post, I was always conscious of time wasted can be money wasted. Never put two people on a job if one person can do it. Accountability also comes in here.

 

Hence another term in business, if you are doing things that cost you money you are not making money.   ;o)

 

[PJ_model_trains]

PJ, just on the info sent back on a detection being made - the sensor doesn't have to send its ID, that is already in its setup along with the port it is connected to.  It does of course send back loco ID and we are told it also sends speed and direction.  I was having trouble with direction as it is meaningless without other positional information.  Now we sre apparently to have sensor position so maybe direction starts to make sense.

 

We have been saying for a while the sensor sends back two items of data, the sensor ID and the loco tag ID, I must admit in writing to hosh earlier today it became clear that the system already knows the sensor ID so really only needs to know loco (or other ittem) tag ID that passed over the sensor. But I steered away from creating further confusion.  ;o)

 

PJ,

The packet of information sent by a sensor to the controller MUST contain at least the sensor id and the loco id. If the sensor id wasn't there, how would the system know which sensor had been tripped?

Ray

 

Hi Ray

 

That is the way we have all been talking and it made sense that each tie a sensor is activated and tag read that two items of data are sent back, Sensor ID and Tag ID.

 

But then came the thought that the system aleady knows the Sensor ID at a position we placed it so why would it need to send that information back? We gave that sensor an ID, the system knows which it is by its x,y co-ordinate if nothing else. We couldn't have two sensors with the same co-ordinates that would not be possible so RM knows which sensor. Could this be the reason for sensors having the x,y co-ordinate? That way only the Loco tag Id needs to be sent back to RM? Comments guys?

 

Now comes the strange bit, we have been talking for some time that the sensor will read the tag, I am fully with this, then magfan placed this on page 35 of Is this how LD works... for each loco being profiled you will need to add a small reflective strip.

 

Is this reflective strip just for speed profiling or similar strip for the sensors discussed here, or was reflective stips an initial consideration then HRMS changed their minds?