Loco Detection (2)

[PJ_model_trains]

Fishmanoz said:

Pretty fundamental change I think PJ. First thing you are going to have to do is throw away the schematic and put in a real layout, then you'll need an engine to map every last piece of track into the program with its dimensions

and where along its length any sensors might be, and whether it joins to more track or points, crossovers or slips.

Not saying it can't be done, clearly it can, but it hasn't even started yet as no such capability is on the current program, nor do

I think likely in the near future.

I think you are thinking to technically.

Possibly your thinking of lit up blocks showing trains moving in the blocks, between the sensors, hence your comment...
you'll need an engine to map every

last piece of track into the program with its dimensions and where along its length any sensors might be this would be the real McCoy!

What I was suggesting was much simpler. The blue block we place on the RM scheme layout it put in a position to

match that on track. The train passes over the sensor and sends code back to LD and RM which is processed by RM and shows the train code #*** and position of it based on the sensor position on the layout. I think MetmanUK has got this.

We only know

the train position based on the last sensor it passed over which shows on the screen. No problem, subject to system capabilities we add more sensors, Hornby are the winners as we buy more sensors and controllers. We know the present capabilities for number

of sensors it doesn't mean this cannot be expanded, I am sure HRMS will watch this in future especially after the LD has been launched and they see what comments, suggests and other items their may be.

[96RAF]

PJ_model_trains said:

I think you are thinking to technically.

Possibly your thinking of lit up blocks showing trains moving in the blocks, between the sensors, hence your comment...
you'll need an engine to map every last piece

of track into the program with its dimensions and where along its length any sensors might be this would be the real McCoy!

What I was suggesting was much simpler. The blue block we place on the RM scheme layout it put in a position to match that

on track. The train passes over the sensor and sends code back to LD and RM which is processed by RM and shows the train code #*** and position of it based on the sensor position on the layout. I think MetmanUK has got this.

We only know the train position

based on the last sensor it passed over which shows on the screen. No problem, subject to system capabilities we add more sensors, Hornby are the winners as we buy more sensors and controllers. We know the present capabilities for number of sensors it doesn't

mean this cannot be expanded, I am sure HRMS will watch this in future especially after the LD has been launched and they see what comments, suggests and other items their may be.

With hindsight of other railway software such as JMRI and

Rocrail, think about how RM sees your trackplan.

It recognises and knows how to interface with active elements like points, locos, signals, sensors, etc, but it has no real idea of how these are linked together as a plan - i.e. it doesn't recognise

straight bits of track so if you deleted all those from your plan, what is left is what RM has to work.

Now go through the logic as presented previously in the thread and see if/how that applies to what you are expecting from RM. e.g. a route is just

a series of separate points maybe with sensors in various places. RM sets off a loco and by dint of the mechanical linking between these points (rails) the loco passes over sensors if fitted which trigger some event or other to happen, else the loco plods

on to the end of the line.

What I suppose I am trying to say is don't expect RM to work miracles even with the expected LDS, until such time as each length of rail is detectable in real time and a tracking image becomes possible. Neither does GPS in

the real world scale down well to a layout.

[PJ_model_trains]

RAF96 said:

With hindsight of other railway software such as JMRI and Rocrail, think about how RM sees your trackplan.

It recognises and knows how to interface with active elements like points, locos, signals, sensors, etc, but it

has no real idea of how these are linked together as a plan - i.e. it doesn't recognise straight bits of track so if you deleted all those from your plan, what is left is what RM has to work.

Now go through the logic as presented previously in the thread

and see if/how that applies to what you are expecting from RM. e.g. a route is just a series of separate points maybe with sensors in various places. RM sets off a loco and by dint of the mechanical linking between these points (rails) the loco passes over

sensors if fitted which trigger some event or other to happen, else the loco plods on to the end of the line.

What I suppose I am trying to say is don't expect RM to work miracles even with the expected LDS, until such time as each length of rail is

detectable in real time and a tracking image becomes possible. Neither does GPS in the real world scale down well to a layout.

Hi RAF96

I do not expect LD first edition to do this, I did say that but, I do think it is possible in future,

as quoted a Pro version.

I know what you are saying and see what you are saying but, take away all the track as you have suggested that would only be relevant for my point if track was detectable between two sensors. We are left with points, maybe signals,

and sensors when we put them in.

RM and LD doesn't know where they are, they don't have to. But, RM knows where we put the blue square for LD. When we switch on a light the switch doesn't know where the bulb is, it doesn't need to but, by the position

of the bulb we can see it, we know where it is. So it could be with RM using advanced LD. Example: A train goes over the sensor (light switch!), a message is sent to the bulb (power down the wires), the sensor shows Loco 003 (light bulb comes on).

This

is loco detection on screen by confirming which loco has just gone over a sensor. We know where because we have a layout design similar to ours and the blue box, that would show the loco number, is in that position. The system doesn't know or understand, it

doesn't have to. But, we do by where we put the items to detect and where we put the item to show the result.

Train goes clockwise round outer loop, bottom right sensor picks up train 036 and shows this in the blue box (doesn't have to be blue) in that

position on the layout. As it continued it goes over the next sensor, message sent back, 036 (or short name we give it) shows in blue box bottom left and switches off last sensor result showing in bottom right. This follows round the track which ever loop.

Only one train can go over one sensor and which ever train does so on any loop would show that train number, or short name at that point we placed on the layout.

Now if we wanted more, we just add additional sensors and position them between the two

just mentioned for example. Direction indication would be another consideration maybe in the blue box but it could be a simpler way round loco detection showing on screen than block detection with loco position in block.

[MetmanUK]

Fishmanoz said:

Hi Metman, a lie down might be good. There are 2 issues with what you say. The first is that you will quickly run out of sensors given the number you can put on your layout. So every foot will be impractical.

The second

is that, even if you have them every foot, the program still doesn't know where those pieces of track are, only that a sensor is there, but just where where is remains a mystery. The track pieces are only there for your convenience, not for any practical use

by Rm am in controlling your locos.

At least that is what I think. I'm happy to be corrected.

You are right ....... and hopefully that was what I was trying to get across!

[MetmanUK]

Hello PJ,

Rather than repeating your previous posts can I just say that I think you now 'get it'!

 

Programatically, from Hornby's perspective, all they have to do is create an 'image' that can display the detected loco ID (or whatever). It should

 

also be straight forward to code the relevant support routines to make this happen AND to tidy up afterwards. either by switching off the loco identification after a few (or specified) seconds OR when that loco is next detected. The method chosen should be

 

parameter-driven so that we can select what suits our current level of loco detection capabilities. As you say, the current sensor limit may well be easy to increase.

[PJ_model_trains]

Hi MetmanUK

 

I think I will call it another Eureka moment ;-)

 

I am sure Hornby understand what we are saying and how easy it could be for a programmer.

 

Sometimes we look at things and make them to complicated or our thoughts blank

 

us from seeing another direction as we have other things in our mind. I happens to us all at times, it has happened to me I know and is also happening for others.

 

An image in the location of the sensor is ideal. About the same as the box only oblong

 

instead of square. Pictures speak louder than words or codes, even small ones. We know our trains, we know the image, we know where it is on the layout. Loco Detection I call it.

 

One word my friend. Brilliant!

Two words... not complicated. (as it

 

would be for trains in blocks)

 

I would certainly pay to add more sensors and upgrade if needs be.

But first we have to get LD first edition ;-)

 

PJ

[Fishmanoz]

PJ_model_trains said:

But, RM knows where we put the blue square for LD.

His is what I believe to be the fundamental fallacy in a lot of the thinking here. It doesn't, and isn't likely to anytime soon. But I'm perfectly happy

to be proved wrong.

Also, I'm not sure why you want RM to display what loco was last at what sensor, or how there will be sufficient room on a practical schematic to display it. And it can't switch the display of this off when the loco reaches the

"next" sensor as it has no concept of next. It could of course do it when the loco reaches another sensor.

All an LD sensor cares about is that it carries out the steps defined in its setup when it makes a detection.

But I have my hat at the

ready.

[MetmanUK]

Fishmanoz said:

PJ_model_trains said:

But, RM knows where we put the blue square for LD.
His is what I believe to be the fundamental fallacy in a lot of the thinking here. It doesn't, and isn't likely to anytime soon. But I'm

perfectly happy to be proved wrong.

None of us know whether if, when or never, Fishy.

Also, I'm not sure why you want RM to display what loco was last at what sensor,

Why not? It has that info available.

or how there will be sufficient room on a practical schematic to display it.

That's a different problem!

And it can't switch the display of this off when the loco reaches the "next" sensor as it has no concept of next. It could

of course do it when the loco reaches another sensor.

Exactly.

All an LD sensor cares about is that it carries out the steps defined in its setup when it makes a detection.

But the event that the detection fires off

can do anything the programmer desires.

[RDS]

I am sure HRMS are fascinated (and probably amused) that 27 pages of guesses have been generated on this thread.

My policy is: Wait and See.

[Graskie]

I agree, RDS. I detect a sense of desperate guessing here. I'm just glad I'm nowhere near LD considerations yet.

[PJ_model_trains]

Fishmanoz said:

PJ_model_trains said:

But, RM knows where we put the blue square for LD

Fishmanoz said:
His is what I believe to be the fundamental fallacy in a lot of the thinking here. It doesn't, and isn't likely to anytime

soon. But I'm perfectly happy to be proved wrong.

CORRECTION see yesterday's message below...

14:04 02 May 2014

RM and LD doesn't know where they are, they don't have to.
But, RM knows where we put the

blue square for LD. When we switch on a light the switch doesn't know where the bulb is, it doesn't need to but, by the position of the bulb we can see it, we know where it is. So it could be with RM using advanced LD. Example: A train goes over the sensor

(light switch!), a message is sent to the bulb (power down the wires), the sensor shows Loco 003 (light bulb comes on).

This is loco detection on screen by confirming which loco has just gone over a sensor. We know where because we have a layout design

similar to ours and the blue box, that would show the loco number, is in that position.
The system doesn't know or understand, it doesn't have to. But, we do by where we put the items to detect and where we put the item to show the result.

Fishmanoz

said:
Also, I'm not sure why you want RM to display what loco was last at what sensor, or how there will be sufficient room on a practical schematic to display it. And it can't switch the display of this off when the loco reaches the "next" sensor as it

has no concept of next. It could of course do it when the loco reaches another sensor.

Simples Fishy, Loco Detection, it shows you on your layout on screen where the loco is.

Instead of a blue box this could be a small image

of your loco, just short of a length of track in the layout scheme and slightly wider. Train goes say left as we view it loco shows left, train goes right as we view it loco goes right. Same for up and down as viewed, 45 degree angles to match track angles

can also be easily included on layout in RM. It could also be loco code or words but as MetmanUK said it could be an image and it could similar to that detailed above.

There is sufficient information sent back when a train passes over a sensor to do

this. RM would use that data as programmed.

I think the thoughts behind this is really to how the trains are run. If you use a controller you watch your trains and twiddle with your knobs, thats great. But if you run RM you are running the system from

the computer screen and watching happen before your eyes. Let me put another angle here. Why do we have points on screen, why do we look at the screen to change them. Because that is where they are controlled from. Why would we expect to see locos on screen,

because that is where they are controlled from.

Fishmanoz said:

All an LD sensor cares about is that it carries out the steps defined in its setup when it makes a detection.

All it cares about and what it could

do with the information sent back are two different things.

Fishmanoz said:

But I have my hat at the ready.

Small bites fishy and don't choke on the corks.
(humour icon if we had one so not taken wrong way)

We

all realise we don't have the first edition of LD yet and are discussing here future things that can be done with it. Is it wrong to discuss them, I don't think so, these are items that will not be in the first edition from what we understand so far that could

enhance the software further. HRMS watch and listen, I do not think they laugh at these type of comments as it has been said, they take them on board with their own ideas and 'they' decide if they are worth taking forward in future or not. I believe many ideas

come from many, as one idea can generate another point of view, Hornby spent a lot of time with LD first edition, the resulting system was not one persons idea but many and the Eureka moment may have been one person but was probably due to collective ideas

to that point. BT used to use the saying... its good to talk!

As for us we have two choices, we can be involved, with comments and constructive criticism or we can switch off and read other comments that interest us more.

[PJ_model_trains]

MetmanUK said:

Fishmanoz said:

PJ_model_trains said:

But, RM knows where we put the blue square for LD.
His is what I believe to be the fundamental fallacy in a lot of the thinking here. It doesn't, and isn't likely to

anytime soon. But I'm perfectly happy to be proved wrong.

None of us know whether if, when or never, Fishy.

Also, I'm not sure why you want RM to display what loco was last at what sensor,
Why not? It has that info available.

or how

there will be sufficient room on a practical schematic to display it.
That's a different problem!

And it can't switch the display of this off when the loco reaches the "next" sensor as it has no concept of next. It could of course do it when

the loco reaches another sensor.
Exactly.

All an LD sensor cares about is that it carries out the steps defined in its setup when it makes a detection.
But the event that the detection fires off can do anything the programmer desires.

Well

put MetmanUK.

It is good to share ideas because by doing so other ideas come from them.

The main facts are, although not in the first LD to come out, the main point here is data is being sent back from the sensor that RM 'could' use to further

enhance the software.

To be discussing these matters now just shows the interest in the system, ad excitement as to what it can do in the future.

[MetmanUK]

PJ_model_trains said:

Well put MetmanUK.

It is good to share ideas because by doing so other ideas come from them.

The main facts are, although not in the first LD to come out, the main point here is data is being sent back

from the sensor that RM 'could' use to further enhance the software.

To be discussing these matters now just shows the interest in the system, ad excitement as to what it can do in the future.

In another thread I made the case for a programmer's

API. One of my assertions was that Hornby cannot have ALL of the best ideas, especially as they probably have/use a very small development team. So, if their software developers are good at their jobs, they will appreciate all feedback (can't think of a better

word at present) as it will help them to confirm/amend/improve their plans for RM and LD.

PJ and Hornby are not the only ones who can have (or initiate) eureka moments!

[RDS]

Post a new reply...

[RDS]

PJ_model_trains said:

... I do not think they laugh at these type of comments as it has been said ...

PJ, Just for the record, I did not say that HRMS laugh at the comments.
I don't laugh at them myself but I am 'amused'

by the ongoing discussion.

[Gregd99]

MetmanUK said:

PJ_model_trains said:

Well put MetmanUK.

It is good to share ideas because by doing so other ideas come from them.

The main facts are, although not in the first LD to come out, the main point here is data

is being sent back from the sensor that RM 'could' use to further enhance the software.

To be discussing these matters now just shows the interest in the system, ad excitement as to what it can do in the future.

In another thread I made the case

for a programmer's API. One of my assertions was that Hornby cannot have ALL of the best ideas, especially as they probably have/use a very small development team. So, if their software developers are good at their jobs, they will appreciate all feedback (can't

think of a better word at present) as it will help them to confirm/amend/improve their plans for RM and LD.

PJ and Hornby are not the only ones who can have (or initiate) eureka moments!

Personally, I think an API and scripting capability

in a language like python would be GREAT. I also think that this is probably getting out of the RM target market. have a look at JMRI if you are interested in complete flexibility and customization.... but do be prepared to invest time to get something going.

[PJ_model_trains]

RDS said:

PJ, Just for the record, I did not say that HRMS laugh at the comments.
I don't laugh at them myself but I am 'amused' by the ongoing discussion.

Fair point RDS. It is better to be amused than critical without

good reason. I find sometimes an odd person, very knowledgeable, can attempt to shoot down something they do not see as feasible, or shall I say, that is how it comes over at times.

[PJ_model_trains]

MetmanUK said:

PJ_model_trains said:

Well put MetmanUK.

It is good to share ideas because by doing so other ideas come from them.

The main facts are, although not in the first LD to come out, the main point here is data

is being sent back from the sensor that RM 'could' use to further enhance the software.

To be discussing these matters now just shows the interest in the system, ad excitement as to what it can do in the future.

In another thread I made the case

for a programmer's API. One of my assertions was that Hornby cannot have ALL of the best ideas, especially as they probably have/use a very small development team. So, if their software developers are good at their jobs, they will appreciate all feedback (can't

think of a better word at present) as it will help them to confirm/amend/improve their plans for RM and LD.

PJ and Hornby are not the only ones who can have (or initiate) eureka moments!

Hi MetmanUK

I apologise if that is how it

came over, it was not intended to. Occasionally certain people shoot things down, come over abrupt, don't seem to want to see both sides. Shame really, it just causes others to raise the argument to try get the point over, this is the worry as it stretches

the arguments. I just felt, hang on, there is more than one person saying the information from the sensors is already there it is how it could be used in RM but, others were thinking of a more complicated option, actual detection on a section of track, not

what was at that time being discussed. Maybe what I was explaining was not clear enough?

I agree we are talking of Pro here when the first edition has not been launched that could be criticised by some but, like the TV we don't have to read or watch

them, we can switch off or move to something that interests us more.

More importantly you saw these benefits also, some before I did, but again it doesn't matter who saw them or came up with them, I still say, one persons ideas trigger another persons,

it is the things we share together that may or may not cause Hornby to say I like this but not that. They are doing a fantastic job, and they are listening but, the final decision is theirs, no one elses. They will know if an idea can be profitable and can

be advanced, they have their ways to monitor interest and gauge demand, they really are doing a great job.

I didn't see your comment in the other thread you mention but agree fully with you. It doesn't necessarily have to be a small team or a large

team, this applies to chemists, scientists etc. It is initially a team effort of shared ideas and then one (in the very small or very large team, company, etc) comes up with the Eureka moment. A lot of work and ideas happened before a rocket went to space,

a cure for a specific cancer was found, RailMaster was born and the fruits of the harvest with LD will become available to us.

Forums are a fantastic way for companies and individuals of all knowledge and backgrounds to come together and share thoughts

and ideas and openly help one another in the subject or hobby we all enjoy.

[PJ_model_trains]

Gregd99 said:

Personally, I think an API and scripting capability in a language like python would be GREAT. I also think that this is probably getting out of the RM target market. have a look at JMRI if you are interested in complete flexibility

and customization.... but do be prepared to invest time to get something going.

Hi Greg

I understand your comments 'it is probably' getting out of RM market, it may be now, but when RM was born, people would have said the same about LD,

out of Hornby's depth very probably.

Your comments are good, some over my head I admit, but good. You too see the potential, Hornby will have to get LD out and see the demand but if they see potential profit being made by advancing it, I am sure they

will advance it. Meanwhile we just share our thoughts and views and hope Hornby sees them as possible, maybe not now, maybe in the future. My guess is they are noting these things and will consider the ones they think could work for them along with all their

ideas as things progress.

Exciting times for model train enthusiasts.

[RDS]

PJ_model_trains said:

... I didn't see your comment in the other thread you mention ...

@Desirable Features ... ' Page 2, 22nd April 2013

[PJ_model_trains]

RDS said:

@Desirable Features ... ' Page 2, 22nd April 2013

Thanks for this RDS, the post was before my time on here.

API sounds interesting (not boring) and MetmanUK knows what he is talking about but, looking

where we are 12 months on from the above mentioned post, does it not seem Hornby want to retain control as much as possible. Possibly they do but maybe they are realising they can't do everything, hence the various aspect signalling coming in RM Pro and Hornby

don't have their own signals to sell.

KetmanUk has a valid point, the result would be a superior Railmaster/e-Link product from which Hornby and users would both benefit. More heads, more ideas.

[PJ_model_trains]

Thanks for this RDS, the post was before my time on here.

 

API sounds interesting (not boring) and MetmanUK knows what he is talking about but, looking where we are 12 months on from the above mentioned post, does it not seem Hornby want to retain

 

control as much as possible. Possibly they do but maybe they are realising they can't do everything, hence the various aspect signalling coming in RM Pro and Hornby don't have their own signals to sell.

 

MetmanUk has a valid point, the result would be

 

a superior Railmaster/e-Link product from which Hornby and users would both benefit. More heads, more ideas.

[MetmanUK]

PJ_model_trains said:

Hi MetmanUK

I apologise if that is how it came over, it was not intended to. Occasionally certain people shoot things down, come over abrupt, don't seem to want to see both sides.

That's OK PJ

- I wasn't aiming at you at all.

My working life was spent talking to prospective users who wanted a computer system to be designed for them personally or for their team. They usually had some ideas but wre often handicapped by what they thought a computer

could do. I would tell them to forget that as that was my job. I asked them to just dream of anything and everything that they wanted to help them with their work and when they come up with something note it down on a piece of paper that they should always

keep to hand. That way I got a better idea of what may be required - it was still only a starting point though.

That's why these threads should be useful to Hornby because there just might be something useful to them and ultimately us.

[PJ_model_trains]

MetmanUK said:

That's OK PJ - I wasn't aiming at you at all.

My working life was spent talking to prospective users who wanted a computer system to be designed for them personally or for their team. They usually had some ideas but

wre often handicapped by what they thought a computer could do. I would tell them to forget that as that was my job. I asked them to just dream of anything and everything that they wanted to help them with their work and when they come up with something note

it down on a piece of paper that they should always keep to hand. That way I got a better idea of what may be required - it was still only a starting point though.

That's why these threads should be useful to Hornby because there just might be something

useful to them and ultimately us.

No worries MetmanUK

I never took it the wrong way.

I am with you all the way, I think it is right to discuss, share ideas, even look ahead with our ideas and let Hornby decide with their ideas

what they think is best for the company and the system which is getting better and I do not doubt given time (that is the frustrating part) it will continue to get better.

Maybe Hornby should look at what they do best and allow a little more freedom

from elsewhere whilst holding on the the core product and licence. Trying to do everything is good to a degree, but the product(s) could do a lot more, as you have said, and everyone can gain.

[Fishmanoz]

Phil, don't forget you can write long or short programs for individual locos then use the Chain or Merge commands to run them together.