Loco Detection (2)

[St1ngr4y]

Gregd99 said:

St1ngr4y said:
RM knows already what speed that loco should be doing.
RayThis is not actually the case.... RM know what speed it has told the loco to run at.

The actual loco speed will be somewhere in the range

from the "commanded speed" to the "previous commanded speed" as the loco speeds up or slows down. RM can estimate where the loco will be in that range.

Often this will be irrelevant but imagine the case where you say:-
1. set loco to max speed
2.

stop loco
3. if locoSpeed = 0 do something
Does RM use the estimated speed or the "commanded speed" in step 3?

Hi Greg,
You are quite right, if you rely on the acceleration/deceration CVs set in the loco decoder. However, if you use

the accelerate/decelerate commands in a RM program, them RM should know much more precisely the speed of the loco at any point during the accelerate/decelerate.
Ray

[PJ_model_trains]

@Fishmanoz

 

Hi Fishy, I cannot help to wonder how suddenly you know all this, where as up to now you have said, stop speculation, wait and see, and that you don't work and have no connection with Hornby.

 

That aside it is important to discuss

 

what the system will and won't do and try understand how it works and how we will use it in our layout system.

 

The 3 components making up the system have been known for a long time, we've learnt nothing new there. We have learnt a little about the

 

capability or capacity of them and prices though.

We all know the three components but what is important now is we know more about where they will go and the sizes of them.

 

This is not a block detection system as such, put simply it

 

is a loco ID tag detection system. However, you can think of it in blocks being the length of track between 2 sensors, and that may not just be a single length if there are points in the middle of it.

 

Having a tag at the front and back of the train

 

will give you an advantage in knowing whether the entire train has passed a single detector or not. Otherwise, you will have to rely only on the loco arriving st the next detector to prove that it has fully passed the previous one. If it stops somewhere in

 

the middle, you won't know whether it has fully passed the previous detector or not.

The railway runs in blocks that is why I word it this way, it is a good way to think of it. I am still wondering about the sensors Fishy, if a train passes sensor

 

'A', data is sent to RM to confirm this. Surly a sensor is not need at the front and back of a train because when the train reaches sensor 'B' RM is notified it has done so, and because the blocks (distance between sensors) is longer than the full train length

 

it is clear to the system it has passed the previous sensor. If it stops in the middle, neither the front of the train or the back of the train have sent any message to RM so the block is still occupied. The only way I see the block front and end to have an

 

advantage is if the train length was small, this could stop in the middle and the end could have past the last sensor.

 

Another question regarding sensors at the front and end of locos. If a loco say 003 is passing sensor 'A' would the back carriage

 

or guards van be coded 003 or is loco tag code say xxx (as read by the system) connected in RM to end of loco tag say xxx? If so this would cause problems if a train changes it's load which I am sure we will all do at some stage.

 

I am trying to visualise

 

how it works from reading the tags placed and trying to make sure one tag doesn't conflict with another. These discussions are very helpful for us to understand more before the system is available.

[PJ_model_trains]

Fishmanoz said:

The LD system will not be able to switch points or signals as such. All it will be able to do is report the detection of an ID tag at a particular sensor. I would also be very simple for it to report the direction of travel

of the tag if appropriately encoded. It may, and I repeat may, be able to report something about speed. However, given that the tag must be short to fit easily under a loco, the system will have to measure quite accurately the time the tag took to pass over

a sensor before that speed reading will have any degree of accuracy. And reading that time at all will be quite different to detecting ID numbers or direction setting codes.

So if that's all it can do, how will an LD system be useful? The utility will

be in your skill at writing programs that take actions with locos, points or signals etc conditional on the detections being reported by the system. Part of this will also mean that RM will have to remember and have available for use in programs the conditions

last set for all of those things - loco last speed and direction, point set direction left or right, and signal state etc.

Hi Fishy, you say...

The LD system will not be able to switch points or signals as such.
The utility will

be in your skill at writing programs that take actions with locos, points or signals etc conditional on the detection's being reported by the system.

2 questions.

1 - Programming loco and sensors in a program in RM
Do we write programs, in

RM, to run the loco and what happens as it passes the various sensors, or

2 - Programming sensors in a program in RM for the loco we are driving
Do we write programs in RM to program the detection of a loco and the things we want to happen if the

train in our control passes this or that sensor?

Or should it do both?

[PJ_model_trains]

Loco Detection - Sensors/Tag locations.

 

What do you guys think is the best approach, having considered train length and allocated sensors to control blocks.

 

1 - where would you put a sensor in the approach to a set of points?

 

2 - where

 

would you put a signal in the approach to a set of points and would you put a sensor here also?

 

3 - where would you put a sensor or multiple sensors in an approach to a station

 

Bearing in mind a train may have picked up to 65mph say. I am asking

 

because I am considering slowing down and stopping if signals are on red. It would be no use reaching the sensor and finding out the train should stop if at such speeds as it would over shoot the signal and possibly points.

 

Comments welcome

 

Many

 

thanks PJ

[Fishmanoz]

PJ, I don't "know" any of the stuff I posted because I am Hornby or have been told by them. All I've done is draw some logical conclusions from likely technical capability including technical limitations. I could be talking through my hat again, but I

 

don't think so.

 

Just a couple of points from replies above, starting with where is your train. Loco 003 pulling 6 carriages is proceeding at shunt speed and is detected by sensor A. Immediately it slows to a halt with 5 carriages yet to pass the sensor.

 

How can the system tell if it is clear of the previous block? Only one of 2 ways: either it reaches sensor B; or the sensor fixed to the last carriage is detected by sensor A. But the whole train may pass sensor A before the loco reaches sensor B, and again

 

stop. In this instance, a last carriage sensor will be able to tell us the train has cleared sensor A, even though sensor B has no info.

 

Some have suggested that RM will be able to calculate where a train is by doing some calculations based on knowing

 

when it passed a sensor plus it's throttle settings, including changes made, acceleration and deceleration. RM certainly can't do this presently and, if it could do it accurately, we wouldn't need an LD system.

 

To accommodate LD, RM is going to need

 

more capability. For a start, you will have to be able to allocate a detection tag to a loco: and maybe to rolling stock as well if you have a sensor at each end of the train.

 

PJ, to start to think about what and how you might program, go back to that

 

imaginary sensor you out on your layout and look again at the list of things you can have happen when a detection is made. They are the things you can write into your program. And your program is just a set of logical instructions.

 

As well as having

 

program instructions that say do this, do that, you will now be able to have if/then/else instructions - if a detection occurs, then do this and do that, else carry on as previously instructed.

 

Think about being able to start to write your program

 

by recording a macro while you use voice control to run your layout.

 

And hopefully I'm not talking through my hat this time either.

[Graskie]

Sorry, we've really upset you with all this talk about your hat, haven't we, Fishy? You've obviously become obsessed with it, haven't you? Have you now talked through it so much that its lid has worn away and is now gone?

[PJ_model_trains]

Fishmanoz said:

Just a couple of points from replies above, starting with where is your train. Loco 003 pulling 6 carriages is proceeding at shunt speed and is detected by sensor A. Immediately it slows to a halt with 5 carriages yet to pass

the sensor. How can the system tell if it is clear of the previous block? Only one of 2 ways: either it reaches sensor B; or the sensor fixed to the last carriage is detected by sensor A. But the whole train may pass sensor A before the loco reaches sensor

B, and again stop. In this instance, a last carriage sensor will be able to tell us the train has cleared sensor A, even though sensor B has no info.

Think about being able to start to write your program by recording a macro while you use voice control

to run your layout.

Hi Fishy

I am not getting this. Lets put your hat to one side and chat about it ;-)

If say loco 003 passes sensor 'A' we know it is now in the next block (between sensor A and sensor B for this example)

that we agree.

If it has not reached sensor 'B' then it is still in the block but it's carriages could be in the A to B block or in the previous block, therefore for signal and point purposes it occupies both blocks, that we agree.

If as you

say the train has entered the block between A and B, and 5 carriages have not then it is the same scenario it occupies both blocks and therefore a tag on the end of the loco makes no difference. It is only if the loco stops before it gets to sensor B and the

length of the loco and carriages is smaller allowing it all to be in that block that it would be an advantage.

I am trying to justify that extra sensor at the end and feel, it may be right, it may not, but to debate it has to help us all. I am imagining

my layout as a straight line not an oval, I split in into say four blocks therefore me line is Blocks 1, 2, 3, 4 and 1... repeated. The lines can be north to south, east to west it doesn't matter our oval is a straight line.

In real life railway, as

I believe it and as I feel we want it, a signal is red because the next block is occupied. If the train has not passed from one block to another the previous signal remains red until it does. (unless we allow yellow to proceed with caution but then we are

allowing two locos in one block and start to risk collisions). So with this in mind, looking forward from where the train is and is moving, sensor A changes signal to red when train has passed but carriages are still in previous zone so previous zone sensor

start is still red. When loco meets sensor B every part of it is in that zone. Then the previous signal turns green and if required then the points at the start of the block discussed can change. Subject to us programming it to do this... then replicating

for each block as the loco progresses.

Hopefully I am explaining it clear enough, I am not saying it is right but explaining how I see it and add it here for discussion. If I am talking out of my hat please don't send yours, just say so but to help

me explain why my thoughts are wrong and I will buy another hat.

Many thanks

PJ

[PJ_model_trains]

Fishmanoz said:


As well as having program instructions that say do this, do that, you will now be able to have if/then/else instructions - if a detection occurs, then do this and do that, else carry on as previously instructed.

If/then/else

instructions... these make PC control really start to work.

[St1ngr4y]

What I can't get my head around is that a Railmaster program is a SEQUENTIAL list of instructions, each having a time in seconds determining when that instruction will be carried out. If/then/else instructions imply that some sort of waiting period will

 

be entered in the program until or while one of these conditional instructions is true. If so, what happens to the clock - does it keep on ticking while this waiting loop executes? Will conditional branch instructions be include to skip forward or backward

 

in the program, bearing in mind that this would equate to time travel!! I think we'll have to wait and see how sophisticated the programming commands provided are, and whether we need to book a place on a Railmaster programming course :-)

 

[PJ_model_trains]

I would say the clock just keeps ticking

 

Train is moving, clock is ticking. Train passes sensor A, instruction was programmed, if train number ××× passes it then signal red else signal green, clock keeps ticking. Things only happen as a tag is read

 

and instructions are passed to RM, clock continues.

[Fishmanoz]

Good point Ray. But remember the if/then/else is triggered by a detection and is in the setup features selected by the detector. So I think well end up with other then sequential instructions. I think we are going to have to wait to see exactly how they

 

implement it, it may be part of the clever second solution that was talked about some time ago. I'm thinking actual detections will not be the clever part, rather what you can do with them.

[Fishmanoz]

Add apostrophe where you think needed.

[St1ngr4y]

PJ_model_trains said:

Things only happen as a tag is read and instructions are passed to RM, clock continues.

Hi PJ,
What sort of instructions are passed to RM, and by what?
Ray

[Fishmanoz]

Ray, add a detector to your schematic (I know you don't actually have one but do it anyway). Now right click on it to bring up its setup window, then click on one of the lines that come up and see the drop down of all your choices when a detection occurs.

 

I think that is what PJ is referring to.

 

I think all the LD system itself is going to tell RM is that a detection has occurred with a particular tag ID, and probably which direction it is going, don't think it will tell us speed. That info will go

 

to RM and it is here that the clever stuff will start.

[St1ngr4y]

Fishmanoz said:

Ray, add a detector to your schematic (I know you don't actually have one but do it anyway). Now right click on it to bring up its setup window, then click on one of the lines that come up and see the drop down of all your

choices when a detection occurs. I think that is what PJ is referring to.

I think all the LD system itself is going to tell RM is that a detection has occurred with a particular tag ID, and probably which direction it is going, don't think it will

tell us speed. That info will go to RM and it is here that the clever stuff will start.

Gotcha, I'll have a look at that tomorrow (or tonight your time :-) )
Ray

[PJ_model_trains]

Fishmanoz said:

Ray, add a detector to your schematic (I know you don't actually have one but do it anyway). Now right click on it to bring up its setup window, then click on one of the lines that come up and see the drop down of all your

choices when a detection occurs. I think that is what PJ is referring to.

I think all the LD system itself is going to tell RM is that a detection has occurred with a particular tag ID, and probably which direction it is going, don't think it will

tell us speed. That info will go to RM and it is here that the clever stuff will start.

Ray/Fishy

Yes that is what I was referring to. It is worth doing what Fishy has suggested to familiarise yourself with what is there etc but, I am

sure there will be others when the if. then, else is included.

These are the current commands, some you can add further instructions some not, check them out

On signal green
On signal red
For Locos;
For train type(s)
For forward direction
For

reverse direction
For any direction
Stop loco
Stop loco on signal
Resume loco on signal
Reduce loco speed to
Increase loco speed to
Set to cruise speed
Switch right point
Switch left point
Set clear signal
Set danger signal
Activate

loco function
Play sound file
Run program file

Initially I was thinking commands would be sent back to RM, having heard what fishy said and that it is 'Loco detection' then I am sure that is all it is a tag detecting something at a sensor. The

real programming will be in RM.

Some data will be sent back to RM, I am sure, but we don't know what. I guess we will add the tags and let RM know what they are. They may be just bar code numbers sent back but RM will process that bar code number. We

may say train is... (your favourite), RM knows it as say CV 1, address 003. We may put bar code 27 for example on train 003, the sensor reads the tag and sends that back to RM, it has detected it. RM will probably do nothing with it unless we have written

a program that says train 003 (barcode 27) stop if signal is red else continue if signal is green.

I am thinking that I will set my blocks by the position of sensors, blocks will probably start before points and signals and also exits from stations.

RM will probably be programmed to say if 'any' train reaches this sensor and signals are red then stop. Signals to be red when a train is in the next block. I am thinking I may then add sensors before the points to provide slowing down of trains if a signal

is red so that when it reaches the point sensor it can stop in time if the signal is red.

But, I am still thinking and listening to every ones ideas.

LD may know which way a train is going by thee direction it reads the bar code.

LD may

be able to estimate speed by the trains set speeds and the time between two sensor tags.

I don't think programming will be a problem once we know what it does and start playing with it, my biggest concern is wiring under the layout again, I guess that

will be my biggest hurdle as I have to get people to do it for me and I won't want to be doing it in bits. Maybe I will consider the position of all sensors and wire them in, noting the barcode number or what ever we are given to identify them. As long as

I know which sensor is where the rest can be programmed from the computer.

[St1ngr4y]

Hi PJ,

The only item on the list of 'commands' that I would be happy with is the last one - Run a program file - provided there is enough time for RM to open the file, read it and start executing the commands therein before the loco which has been detected

 

has travelled too far. I would need to see the documentation of the others before passing comment. Some of them seem a little too simple to me - for example, stop loco on signal. Presumably this would refer to the next signal past the detector - but different

 

locos have different deceleration rates. How can the system ensure that all locos detected in this way, slow down and stop and the correct place if the signal is showing red.

Ray

[PJ_model_trains]

Hi Ray

 

I agree, different locos have different deacceloration rates, you cannot say when a train reaches sensor for red signal stop, it is to late to stop. That was why I mentioned in the example we may need another sensor before the one at the

 

signal to slow the train down if the next signal is red. This would also be the same approaching a station.

 

PJ

[Fishmanoz]

Guys, again some logical thinking here. The LD system consists of receivers (max 2) connected by USB to computer, sensors (max 24 each receiver, found easily by looking at the ID you can select for that sensor you put in your layout to play with) and tags

 

(over 200 at any one time).

 

In the first instance, we know logically that when a tag passes over a sensor, the sensor tells the receiver and the receiver tells RM that tag No? Has been detected. Does it do anything else? It's easy to see that it does

 

- instructions 5, 6 and 7 relate to direction, so clearly the sensor can tell which direction the tag was travelling and tell this to RM via the receiver. By the same logic, no instruction relates to a detected speed so we can conclude it does not detect speed.

 

And time between sensors would only give us any measure of speed if the loco didn't change speed between those sensors and, as we can't assume that, we can't use the time difference to tell us speed. So the LD system is not going to tell us speed at all.

 

Now

 

take another look at the instruction set PJ has kindly reproduced. The first 7 instructions are "if" instructions - they require some condition to be met. The balance are "then" instructions - do something. Note there are no "else" instructions as I suggested,

 

the "else" is always continue unchanged.

 

Now again look at the sensor setup window. Note you can only bring up the instruction drop down list by clicking in the left column of the 2 you have, not the right column. But now put an instruction in the

 

left like For Locos: or Increase Loco Speed To and then click next to it in the right column. Now you see a box in which you enter the data required by the instruction. And also note you have available I think 10 instruction lines so you can do a number of

 

things when a detection occurs.

 

Finally, remember these instructions are not in the LD system as such, they are in RM because you put them in the RM sensor setup window. Again, all the LD system is going to do is detect tag IDs and direction of travel.

 

QED.

 

Becoming clearer?

[Fishmanoz]

Note second line second para says that tag number question mark has been detected, it is not a sentence which is a question followed by another sentence of 3 words, in case that was unclear.

[Fishmanoz]

One more thing - go into loco setup window and select one. Notice near the bottom of its window there is a box for detection ID and next to that a Type with options like Express, Branch, Maintenance and Shunter.

 

Put that together with mine above,

 

and it is getting clearer still I think.

[Gregd99]

Fishmanoz said:

In the first instance, we know logically that when a tag passes over a sensor, the sensor tells the receiver and the receiver tells RM that tag No? Has been detected. Does it do anything else? It's easy to see that it does

- instructions 5, 6 and 7 relate to direction, so clearly the sensor can tell which direction the tag was traveling and tell this to RM via the receiver.
Becoming clearer?

I think that we will find that all the detector tells RM is that loco

id X has been detected by detector Y.

RM knows where you have position detector Y on the layout from the track schematic. RM can also match the id X to a specific loco and the associated speed and direction.

From my experience location detectors

are quite "dumb" devices. their job is to reliably detect (which can be hard) but everything else is up to the host software on your pc et al.

if the above is correct then an interesting question is raised if we fit id rags to wagons. RM will not know

anything about their speed or direction.

[St1ngr4y]

I've been trying to imagine how a layout with LD would be operated. Is the intention to get things moving and then sit back and let everything operate automatically, with LD preventing crashes? In the real world, track circuiting protects blocks of track

 

by changing signals to red as trains pass them, but that system still assumes there are drivers in the trains who can react to the signals. Is LD intended to allow RM to be the drivers of all trains ?

Or is the way LD is implemented down to the user who

 

can choose how to incorporate the features of LD to his own requirements?

I would be interested to hear from those forum members who are eagerly awaiting LD how they would envisage it being utilised on their own layout.

Ray

[Gregd99]

St1ngr4y said:

I've been trying to imagine how a layout with LD would be operated.

I have no inside information but I doubt that RM+LD will allow fully automated operation at this stage.

The capabilities seem to be focused

on "when a loco arrives at point x do something". This gives a lot of fun options with play sounds and slowing down in sidings etc.

When you look at auto operation then you need to know the location of every train with respect to each other and to ensure

that blocks are allocated/de-allocated as required with trains being stopped and started as required if signals are set against them and/or blocks are available.

a sequence might go...
1. train 1 is driving from block n to block n+2
2. if block

n+2 is occupied then set signal in block n+2 to red and block n+1 (and possibly n depending on block size and train speed) to yellow
3. as train enters yellow signalled blocks then set speed of train 1 to such that it will stop within the yellow blocks.
4.

when block n+2 becomes free then set signals in blocks n-n+2 to green
5. now signals are green set train 1 speed to the speed determined by signals ahead (n+2, n+3...)

Depending on your interests the sort of programming above is very interesting

(or complicated or boring because you want to drive your own trains)

I think, at least initially, RM will stay away form the complexity of full auto-running.

My layout, when I have time, runs automatically using JMRI. This was a really interesting

project in which I learned an enormous amount about signalling and blocks and... this is code for saying it took a long time to get it right:-)

[PJ_model_trains]

Fishmanoz said:

Think about being able to start to write your program by recording a macro while you use voice control to run your layout.

I don't particularly want voice control Fishy, but because it is Hornby's big

thing they have included most of the extras we have suggested and want, in RM Pro version.

Why would I pay hundred(s) of pounds for sound locos and override it by talking to the system, to me it doesn't appeal to me, I want to hear my sound locos and

control them through my computer enjoying every step of sound with each loco. I will probably later add station sounds so again I do not see the point of voice control but have to pay for it in the upgrade to get the other items we suggested.

just a

reply to your comment Fishy; back to the main topic, loco detection, this is much more appealing and interesting.