Loco Detection (2)

[RDS]

@HornbyRailMasterSupport

Thank you for your posting.

Loco Detection is without doubt one of the most eagerly awaited enhancements to an already super package that we look forward to being able to use.

 

[PJ_model_trains]

@HornbyRailMasterSupport

 

Thank you for responding to the post and to our frustrations, we also recognise your frustrations as you wait for the patent to go through and be confirmed. It is encouraging that you have replied so quickly, we are most

 

grateful, thank you.

 

We look forward to hearing news of the Loco Detection system when it comes available.

 

PJ

[Fishmanoz]

PJ_model_trains said:

I keep looking at loco detection, and running my trains whilst looking for the ways it will work and any problems that may have to be overcome.

Page 91/92 of the PDF Manual states:
When available, Loco

Detection will allow RailMaster to know where each loco is on your track and to take action accordingly. This allows locos to stop at the correct position each time at stations and to set signals automatically when a loco passes a point.

To know

where each loco is on the track, the tag under the train must be programmed into RM for it to identify it. The current version of RM has many loco detection commands in it, set points, speed, etc, etc but I cannot see where a train could be set up, so can

only assume this will be in the new software version.

If the position of the train is identified by the tags passing over a sensor that confirms control of a loco in RM Pro but, I still have a concern.

A sensor detects a train and tells RM a

train has passed over it, it may say for example something like, reduce loco speed 10mph, change signal red, switch right point. If this is programmed for the sensor every train passing over it gets the same instruction. Change signal red may be fine, change

speed to 10 mph may not be required for the next train, change points may be totally wrong sending a second train on a wrong route.

PJ, you seem to be forgetting some of what we have already figured out. Go back to page 16 where you listed

the detector commands, I said how they can be used and then I further down said what you can put in loco setup about LD ID and train type for each of your locos.

From this info, it is clear that you will be able to have commands apply to individual

locos, or loco types, not just to everything that goes over the sensor. This I think answers one of your questions.

Next, remember that you don't have just one sensor, but many. Think about a train passing a sensor at a signal and setting it to red.

This will stop the next train along if you want it to. But the first train continues on and when it gets 2 blocks down the track and passes over the sensor there, it can now reset that first signal back to green, allowing the second train to continue. But

you ask how the second train can now be made to continue. The answer is that the second sensor, as well as resetting the signal, can run a program to restart the second loco.

The thing to remember here is that, because a detection can run a program,

it can affect not just the loco that has passed over it but others locos called up by the program.

Does that tell you a little more about the power of the system?

With apologies to HRMS on speculating further without waiting for the system to

be available, but I am just making logical deductions from the information we already have.

[PJ_model_trains]

Fishmanoz said:

It is clear that you will be able to have commands apply to individual locos, or loco types, not just to everything that goes over the sensor. This I think answers one of your questions.

Next, remember that you don't

have just one sensor, but many. Think about a train passing a sensor at a signal and setting it to red. This will stop the next train along if you want it to. But the first train continues on and when it gets 2 blocks down the track and passes over the sensor

there, it can now reset that first signal back to green, allowing the second train to continue. But you ask how the second train can now be made to continue. The answer is that the second sensor, as well as resetting the signal, can run a program to restart

the second loco.

The thing to remember here is that, because a detection can run a program, it can affect not just the loco that has passed over it but others locos called up by the program.

Does that tell you a little more about the power

of the system?

I do not doubt the power of the system Fishy but, needed to know it will do what I think it will do ahead of time. Unlike most people I have to rely on others to lift my boards and reach where I can’t reach, therefore

I think ahead, way ahead, to minimise inconveniencing others I have to reply on. I also try minimise the amount of times the board is lifted hence the reason even now I have a couple of hundred feet of wire, all tagged, all connected to switches but not yet

to lighting in cars, street, stations, houses, etc. It will all be done in one go.
The frustration is working out what can or cannot be done when a system is not available, the same reason, once I have the system I will know beforehand where everything

will go and will do it all in one go. I am currently planning £600 worth of signalling and decoders but waiting to see RM Pro as to what Hornby have included, 2,3,4 aspect, feathers? Sidings signals etc? I just have to wait and see how far they go in the upgrade,

but it doesn’t stop me planning ahead various options. With RM Pro so close now I probably won’t wire in the lighting bus and lighting items until I can consider and maybe install signals and decodes.
Hornby, very kindly have confirmed this in their statement

earlier..,

Hornby HRMS said;

Information that is in the public domain from previous postings on this forum, magazine articles and indeed the settings and information available within the RailMaster program should already give you an idea

that this will be a sophisticated and useful system, giving a new level of control over the running of trains and switching of points and signals on your layouts.

Thank you again Hornby HRMS for such a fast and positive response.

I

thank you Fishy for the details you provided this is very helpful.

Fishmanoz said:

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.

I am sure LD will be an excellent piece of software, as HRMS said... this will be a sophisticated

and useful system, giving a new level of control over the running of trains and switching of points and signals on your layouts.

Having been reassured that we can control loco number xxx and loco number xx1 etc I am happier now. I think the only

problems and limitations may be, working out slowing down speeds to stop in the right place and possible the number of commands in the sensor list, 10 I think you said. Having tried this earlier with different commands for 2-3 trains I soon found I had used

these up as not all trains had the same commands and were not on the same routes.

I thing Gregd99's explanation 7 days ago regarding blocks is very clear, he also includes the yellow signal which most will use when going into signalling. The problem

will be it is another instruction for the sensors and the programming of the 10 lines you mention per sensor will be used up in no time and probably won't be enough.

We have come a long way but really do thank HRMS for confirming they are watching

this thread with interest and for replying today so quickly. They are as excited as we are, they are also as frustrated as we are but they are keeping LD and us on track so to speak. Thank you.

[Fishmanoz]

PJ, the main tool you have to do lots of things on a detection is to have the detections run programs which themselves do lots of things. So what you put in the sensor setup might look something like:

 

If loco A

Run program X

If loco B

Run

 

program Y

If loco type Shunter

Run program Z

 

Then each of those programs can have many lines.

 

I'm not suggesting you can completely avoid using the other instructions as well as running programs but you can see that the system is going

 

to be very capable and flexible.

[PJ_model_trains]

Fishmanoz said:

PJ, the main tool you have to do lots of things on a detection is to have the detections run programs which themselves do lots of things. So what you put in the sensor setup might look something like:

If loco A
Run

program X
If loco B
Run program Y
If loco type Shunter
Run program Z

Then each of those programs can have many lines.

I'm not suggesting you can completely avoid using the other instructions as well as running programs but you can

see that the system is going to be very capable and flexible.

Fishy you are assuming I want to run programs, I am aware of programs, I am aware of the option to run a program in the sensor options, I am also aware of the problems people have

experienced. I have run some programs and tweaked them but they are not that accurate especially if repeated, others have also confirmed this.

Maybe running a program and tweaking it with sensors may work better 'we will have to wait and see', providing

the sensor over-rides the program command and... not interfere with times and stopping for the rest of the journey. Once it over rides the program it will have done just that, problem, running two programs instead of one.

If program X, is running loco

A, and it comes to a sensor with a program for loco A, will the new program instruction over ride the first, again 'we will probably have to wait and see'.

The method you show as an example is in effect using two programs, one for the programming of

a route or series of routes and locos and two the programs in a series of sensors. I would have thought, subject to system capabilities, it would be better to use one program or the other, I would certainly favour controlling locos with sensors. As mentioned

above any changes made to a program by a sensor, has changed the program, and in effect altered running distance and time within the program.

From the information discussed, a sensor can start a loco, it can stop it at it's destination, it can control

what happens on the way, signals past and present, points ahead, sound, speed, etc. Another sensor can do the same, and another do the same. All locos setting off from different locations, all on route to their destination(s), and all through the sensors,

providing the system is capable of taking the number of commands per sensor.

I was looking at loco detection as a replacement for programs, giving more accurate control of my system, a worthy investment if it can do all the above.

It is good

to discuss what can and cannot be done as we have but, some things, we just have to wait and see. I am reassured by HRMS with their comments yesterday, but no doubt the system will have limitations, probably another entry level piece of software. The suggestions

for improvements are probably already starting to emerge but, we will just have to wait and see, we could be pleasantly surprised, we could be pleased but frustrated. Meanwhile there are still lots of other things to talk about on what we know so far.

[MetmanUK]

PJ

You are, understandably, getting confused between prescriptive programming and event-driven or reactive programming.

 

Your routing programs are prescriptive because they tell each loco precisely what to do, when and how long for. There is no

 

allowance for unexpected events like a loco running slower than normal.

 

Loco detection introduces a feature which will allow you to do just that, to a greater or lesser degree. You can still set up your routes but allow them to be slightly more flexible

 

and less prescriptive. You will, for example, be able to cope with a slow, late running train by queuing others behind it. Yes, this will be more complicated but also more life-like and interesting I think.

 

What loco detection does is alert you that

 

a detection event has occurred and allow you to respond to it given that it will tell you what loco has triggered it, it's speed and direction. What it will not do is control things in the way that you currently understand it.

 

Please don't try to understand

 

it in detail yet as I believe you will find it quite difficult without trying things out with the hardware and software. There is going to be quite a learning curve to climb!

 

PS As I am currently building my layout and plan to include detection I am

 

just as impatient as you!!!

[PJ_model_trains]

MetmanUK said:

PJ
You are, understandably, getting confused between prescriptive programming and event-driven or reactive programming.

Your routing programs are prescriptive because they tell each loco precisely what to do, when

and how long for. There is no allowance for unexpected events like a loco running slower than normal.

Loco detection introduces a feature which will allow you to do just that, to a greater or lesser degree. You can still set up your routes but allow

them to be slightly more flexible and less prescriptive. You will, for example, be able to cope with a slow, late running train by queuing others behind it. Yes, this will be more complicated but also more life-like and interesting I think.

What loco

detection does is alert you that a detection event has occurred and allow you to respond to it given that it will tell you what loco has triggered it, it's speed and direction. What it will not do is control things in the way that you currently understand

it.

Please don't try to understand it in detail yet as I believe you will find it quite difficult without trying things out with the hardware and software. There is going to be quite a learning curve to climb!

PS As I am currently building my

layout and plan to include detection I am just as impatient as you!!!

Hi MetmanUK

Many thanks for your post. I do get frustrated I cannot help that, when we were in business I sat at a computer and gave instructions from there, it was

simple but now I am back to relying on people to do things for me, lifting, picking up, etc. To add to my frustration I feel terrible getting my wife who is not well and a friend to lift the layout for me. After being so active in the past it is hard to cope

with at times.

To add more to my frustrations is trying to do what is a hobby with items that are not yet available. Anyway enough of all that back to the topic in hand.

What I can't seem to grasp is, if loco 003 is programmed to go from A to

D via B & C and in the program it remembers all points, speeds etc. (we will stick to the one loco) it does so in the program according to the time allowed. That loco has a tag and the tag goes over a sensor, if a sensor says loco 003 do this or that or all

trains do this or that, will this not change the program by the instruction just read and received?

Are you referring to a manually programmed route or a recorded route or both? I have only played with recorded routes.

I am shall I say a little

impatient, I guess it is because of my health I need to be occupied but am limited in what I can do, I expected to go buy what I wanted off the shelf and get on with it. I/we are fortunate we are at the start of all these fantastic improvements but it doesn't

stop us all being impatient. From my point of view I am a very planned person, I know what I want to do and do it within my limitations, all this not knowing is the hardest. If I knew more of what I could and couldn't do it would help.

Thanks again

for your supportive comments and guidance, I am grateful.

[MetmanUK]

What I can't seem to grasp is, if loco 003 is programmed to go from A to D via B & C and in the program it remembers all points, speeds etc. (we will stick to the one loco) it does so in the program according to the time allowed. That loco has

a tag and the tag goes over a sensor, if a sensor says loco 003 do this or that or all trains do this or that, will this not change the program by the instruction just read and received?

This is something we will not know for sure until the

manual is available. My guess is that RM will run both sets of code asynchronously meaning that they can/will interfere with each other. The onus would then been us to ensure that they do not do so. But that is only a guess!

[Fishmanoz]

PJ, Metman has it figured, and in a perverse way, so do you.

 

What you have figured is that there is no use running what I'll call a prescriptive (Metman word) route-running program if a sensor half way down the route is going to intervene and throw

 

it out. But that doesn't take away from the power of programs, nor does LD replace programs of the right type.

 

Consider this programming scenario: loco A pulling the afternoon express to Wherever 2 pulls into the station at Wherever 1 at 2.45pm. It

 

is due to leave at 3pm and has priority all the way through to Wherever 2. It crosses the station sensor as it pulls in.

 

The station sensor is setup to take account of the express. In part, it says, if loco A, run program X. So what can program X do?

 

It does this:

 

Set all intermediate points to express route

Set all signals on branches into express route to danger

At 3pm, set loco A to shunt speed, then to cruise speed

End of program

 

So the program sets up the route for the express,

 

stops all other trains from entering the route, and sends the express off from Wherever 1 on time. Now the LD system on the route takes over and allows the express through, or handles contingencies. A contingency might be shunter C late off the express route

 

but the LD system knows its there and takes the action needed to hold back loco A until C has cleared the track, then A continues.

 

Why did I need to use a program and not just have all this setup in the station sensor? Because there are too many lines

 

in program X by the time it sets all the signals and points on the route. This way, we use only 2 lines for loco A, leaving other lines to handle locos B, D and F, also due through the station that day. If necessary, these will also be handled by programs

 

so they also only take up 2 lines in the sensor setup.

 

Does that help your understanding?

[Fishmanoz]

Metman posted while I was typing and I think mine shows how to answer his question for a particular scenario. I am suggesting that you don't right prescriptive programs that can interfere with each other. Write reactive programs that run sequentially and

 

handle the contingencies as they go.

[Fishmanoz]

Oops, wrong right in there, substitute write.

[Gregd99]

HornbyRailMasterSupport said:

We have been watching this thread with interest and the continued speculation regarding the up-coming Loco Detection System.

We are unable to give you specific details about how the system will work as

the patenting process is still on-going however, the information that is in the public domain from previous postings on this forum, magazine articles and indeed the settings and information available within the RailMaster program should already give you an

idea that this will be a sophisticated and useful system, giving a new level of control over the running of trains and switching of points and signals on your layouts.

Please wait until the system is made available and then all your detailed questions

will be answered. A separate PDF guide will be included with the system and Loco Detection will remain a standard feature within the RailMaster software, i.e. you will only have to purchase the hardware.

HornbyRailMasterSupport, I think that is

perhaps a little disingenuous.

The focus of the discussion is very much about what you can do with the system rather than how it works. Unless you have come up with something quite extraordinary then surely all the detector does is communicate to the

RM sw on the PC that tag X has passed over the detector and the novelty is in the way in which this detection occurs.

I think what people mainly interested is what they can do with an RM system with detectors equipped. Is it just reacting to detection

events or something more sophisticated?

Would some communication in this area put a patent at risk?

[PJ_model_trains]

Gregd99 said:

HornbyRailMasterSupport said:

We have been watching this thread with interest and the continued speculation regarding the up-coming Loco Detection System.

We are unable to give you specific details about how the

system will work as the patenting process is still on-going however, the information that is in the public domain from previous postings on this forum, magazine articles and indeed the settings and information available within the RailMaster program should

already give you an idea that this will be a sophisticated and useful system, giving a new level of control over the running of trains and switching of points and signals on your layouts.

Please wait until the system is made available and then all your

detailed questions will be answered. A separate PDF guide will be included with the system and Loco Detection will remain a standard feature within the RailMaster software, i.e. you will only have to purchase the hardware.
HornbyRailMasterSupport, I think

that is perhaps a little disingenuous.

The focus of the discussion is very much about what you can do with the system rather than how it works. Unless you have come up with something quite extraordinary then surely all the detector does is communicate

to the RM sw on the PC that tag X has passed over the detector and the novelty is in the way in which this detection occurs.

I think what people mainly interested is what they can do with an RM system with detectors equipped. Is it just reacting to

detection events or something more sophisticated?

Would some communication in this area put a patent at risk?

Hi Gregd99

Lets not put HRMS off, we are grateful for their input, a wall of silence is worse.

Having said that

and previously thanked Hornby HRMS, I do agree, we are not asking how a system works with regard to what is being patented, we are asking for nuts and bolts of how the system works.

A little bit more of, with the system you will be able to do this and

that, or the previous post was correct but, you will not be able to do that but can do this. It boils down to not wanting the up in the air facts that are part of the patent, but the grass roots, on the ground info.

In my view, it is my view, I feel

Hornby can do a lot of good and generate a lot more interest if they said what was possible with LD in RM. The increased interest with then bear fruit as the system is made available and in the run up to Christmas. Fear of doing or saying the wrong thing grips

many of us. I think HRMS will not be able to discuss the system as we wish without authority to do so but, put correctly and positively to those who can give authority (how much information can be discussed) it really could be to their advantage. But these

are just my thoughts and every company has reasons what to discuss and when, they are responsible for the sales and profit made not us.

[PJ_model_trains]

Fishmanoz said:

Oops, wrong right in there, substitute write.

Come on fishy, get it write, or was it right. Cannot tell your side of the world, your northern neighbours don't know wrong from wong!

I went to a chinese

and placed an order, the person said 'to take out' I looked at the women and said, sorry forget it. ;-)

[96RAF]

PJ_model_trains said:

Come on fishy, get it write, or was it right. Cannot tell your side of the world, your northern neighbours don't know wrong from wong!

I went to a chinese and placed an order, the person said 'to take out' I looked

at the women and said, sorry forget it. ;-)

PJ - Its bad enough translating Oz-speak on the hoof, without getting into Chinglish as well. My next door neighbour is Chinese so I am blessed with a translator.

Back on track - I agree that

RHMS could contribute more within the pat-pending scenario without giving away any trade secrets. After all - we the customers are only trying to pre-understand how a long promised bit of kit works.

They could also give some indication of when we are

likely to see this kit, given their statement that LD will be a basic inclusion in RM and that the only additional expense will be the odd GBP70+ for the hardware - thanks for small mercies.

Whilst on the subject of when? - when can we expect to see

RM v1.56 so we can all assess what is basic functionality and what is additional worth and at what cost.

[PJ_model_trains]

Fishmanoz said:

PJ, Metman has it figured, and in a perverse way, so do you.

What you have figured is that there is no use running what I'll call a prescriptive (Metman word) route-running program if a sensor half way down the route

is going to intervene and throw it out. But that doesn't take away from the power of programs, nor does LD replace programs of the right type.

Consider this programming scenario: loco A pulling the afternoon express to Wherever 2 pulls into the station

at Wherever 1 at 2.45pm. It is due to leave at 3pm and has priority all the way through to Wherever 2. It crosses the station sensor as it pulls in.

The station sensor is setup to take account of the express. In part, it says, if loco A, run program

X. So what can program X do? It does this:

Set all intermediate points to express route
Set all signals on branches into express route to danger
At 3pm, set loco A to shunt speed, then to cruise speed
End of program

So the program sets

up the route for the express, stops all other trains from entering the route, and sends the express off from Wherever 1 on time. Now the LD system on the route takes over and allows the express through, or handles contingencies. A contingency might be shunter

C late off the express route but the LD system knows its there and takes the action needed to hold back loco A until C has cleared the track, then A continues.

Why did I need to use a program and not just have all this setup in the station sensor?

Because there are too many lines in program X by the time it sets all the signals and points on the route. This way, we use only 2 lines for loco A, leaving other lines to handle locos B, D and F, also due through the station that day. If necessary, these

will also be handled by programs so they also only take up 2 lines in the sensor setup.

Does that help your understanding?

Hi Fishy

I will come back to this, I need to do some checking out.

But, as I said previously, before

your explanation, as I saw it, programs and sensor programs can conflict and if a program has times in it any additional instruction affects those times and as a result the stopping positions and times. This is now confirmed but not by HRMS which is where

we need the fundamental operation, the capabilities of the system explaining. I do believe it could be to their advantage.

I will not go further at this stage but in what you say Fishy you make it sound simple-ish with just a couple of commands. Not

so, when we actually get down to programming sensors we will want to adjust speeds, make sounds (other than on here), and change signals and points. It is to a degree the latter that will use the commands allowed although they are all needed to run a system.

Signals not being red and green and not being the one for the track ahead but also for previous ones including, red, yellow, green, yellow and if possible feathers.

I'll be back. But you guessed that didn't you ;-)

PJ

[PJ_model_trains]

RAF96 said:

PJ - Its bad enough translating Oz-speak on the hoof, without getting into Chinglish as well. My next door neighbour is Chinese so I am blessed with a translator.

Brilliant... Fishy's neighbours are Chinese

also.

Just say OK Mate oz will understand ;-)

Back on track - I agree that RHMS could contribute more within the pat-pending scenario without giving away any trade secrets. After all - we the customers are only trying to pre-understand

how a long promised bit of kit works.

HRMS are professional guys but they also have bosses. Have they discussed this with their bosses?
The amount discusses has to be authorised.

They could also give some indication

of when we are likely to see this kit, given their statement that LD will be a basic inclusion in RM and that the only additional expense will be the odd GBP70+ for the hardware - thanks for small mercies.

I don't think they will be

able to say, they don't like giving dates and them being wrong. If still waiting patent, they will no doubt wait. But do we then have to wait for manufacturing? Again this involves others and dates which they have learnt best not to give.

Whilst

on the subject of when? - when can we expect to see RM v1.56 so we can all assess what is basic functionality and what is additional worth and at what cost.

This I am sure as a company they could probably give indication on, providing

it is near complete. If not again they will hold back as they have said, April/May this year.

[PJ_model_trains]

The amount of frustration out here is clearly visible.

 

I find it all very frustrating but, stepping back, I feel for the retailers. If 25% of their annual turn over was Hornby, the lack of stock has hit their sales big time. But what cannot be measured

 

is the damage done. Big companies and their reps say, it is not that bad, if a customer goes to one shop and they don't have what they want they go to another then realise no one has it. I would argue against this, as a retailer, prior to retirement, you work

 

so hard to build up a good reputation, people come back to you because of this, not for one item but regularly. Once a customer looks round they find other retailers and it does affect trade long term. It is then hard to build backup again.

 

Oops back

 

to the topic.

[Fishmanoz]

Can I summarise my last point:

 

Write programs that do not conflict with LD data while they run. They won't work if they do conflict.

 

So don't write a program that says run 003 from A to B via C and D if you have LD sensors at C and D which

 

can interrupt the running of the program. But do write a program that says if 003, set the points to the route from A to B via C and D, set signals to stop other trains entering the route and start 003 running from A at its timetable departure time. Now let

 

LD controlled signalling and point setting take care of it as it proceeds.

 

How did you lot know I have Chinese neighbours, one side at least?

 

And a point on intellectual property (IP) law as it applies to patenting. You cannot patent something

 

that is already in the public domain (disclosure to the government is an exception). Consequently, you cannot talk about what you are attempting to patent until it is patented. Clearly, that only applies to the IP in the patent application. So you can say

 

I'm patenting an LD system but as soon as you start talking about how it works you run the risk of disclosing IP and so not get your patent, or get it and have it struck down later by the courts.

 

Then when you have received your patent, all of the

 

details in the patent are published (there is an exception for patents falling under the Official Secrets Act). That tells your competitors exactly how it was done and is the first clue they get on what is possible and that is often all they need to figure

 

out another way to do it not covered by your patent. So there is a double-edged sword to patenting and it is often better to just go to market with the product without patent and publication. You rely on the advantage you have in the market until others catch

 

up to recover your costs and make your profit. In either case, any disclosure you make before the product is in the shops just eats into the advantage you have.

 

So not surprising HRMS are saying very little. And you can be assured what they are saying

 

has nothing to do with the IP in the patent.

[Gregd99]

per my previous.... I can only imagine that the novelty for which a patent is sought is to do with the detection mechanism. That IP will be interesting at some stage to the engineering types. What is more interesting to most is what RM will do with the

 

detected events.

 

- will auto-operation be feasible (ie with block allocation and routes programmed)? Don't think so.

- will specific operations in response to a detection event be possible (eg change signals/points..) - clearly yes.

- will something

 

else be feasible?

 

Would sharing this sort of info disclose patentable IP?

[PJ_model_trains]

Here is the frustration.

 

We do not want to strip the gear box down, or know how the cogs work, or how the clutch engages. We are driving our trains, like driving a car, we don't need to know what goes on inside the system, just what happens when

 

we are in each gear. We won't even look down at the gear stick, but do need to know when to change gear and what happens when we do so we can plan our driving carefully and safely.

 

Basic information, thats all we are asking, Hornby don't get chance

 

to answer, if they would, fishy keeps taking their tablets.

[PJ_model_trains]

Gregd99 said:

per my previous.... I can only imagine that the novelty for which a patent is sought is to do with the detection mechanism. That IP will be interesting at some stage to the engineering types. What is more interesting to most

is what RM will do with the detected events.

- will auto-operation be feasible (ie with block allocation and routes programmed)? Don't think so.
- will specific operations in response to a detection event be possible (eg change signals/points..)

- clearly yes.
- will something else be feasible?

Would sharing this sort of info disclose patentable IP?

Hi Greg

It has to do with the detection system, they have told us the sensor is in the sleeper so the position of the

detector is not included.

I wonder about the powers of the Vat man, HMRC not mentioned.

PJ

[PJ_model_trains]

Fishmanoz said:

Consider this programming scenario: loco A pulling the afternoon express to Wherever 2 pulls into the station at Wherever 1 at 2.45pm. It is due to leave at 3pm and has priority all the way through to Wherever 2. It crosses

the station sensor as it pulls in.

The station sensor is setup to take account of the express. In part, it says, if loco A, run program X. So what can program X do? It does this:

Set all intermediate points to express route
Set all signals

on branches into express route to danger
At 3pm, set loco A to shunt speed, then to cruise speed
End of program

So the program sets up the route for the express, stops all other trains from entering the route, and sends the express off from Wherever

1 on time. Now the LD system on the route takes over and allows the express through, or handles contingencies. A contingency might be shunter C late off the express route but the LD system knows its there and takes the action needed to hold back loco A until

C has cleared the track, then A continues.

Why did I need to use a program and not just have all this setup in the station sensor? Because there are too many lines in program X by the time it sets all the signals and points on the route. This way,

we use only 2 lines for loco A, leaving other lines to handle locos B, D and F, also due through the station that day. If necessary, these will also be handled by programs so they also only take up 2 lines in the sensor setup.

Does that help your understanding?

Sorry

not following.

If I set a loco in a program I have to set times?

eg.
10 seconds - Choose loco set sound on
20 seconds - Forward to shunt
40 seconds - Forward to cruise
60 seconds (or whatever time set) - Stop
70 seconds - Sound

Off

In the program I have to set times but, I also have to switch off what has been switched on, in the above this is sound and speed to STOP.

But, this is a program and is sensors are used in LD to two conflict and throw timings out?

This

may be program X and the Express train but, a goods train is running late!

Another example may be, it is not an express train and another train has caused a delay therefore the program timings and positions are out? All I am seeing at present is two

systems (program and LD sensor programs) conflicting with each other.

[MetmanUK]

Hello PJ,

In my previous post I tried to keep things simple and steer you away from doing too much forward planning. I obviously failed so I'll try another way of explaining.

 

Lets look at a real-world scenario. I want to go by bus to a shopping

 

centre, buy some clothes and have a meal, then return home. In the 'plan everything in advance' world - we'll call it 'prescriptive'. In this world I would :-

1. Leave house at 11am and walk to bus stop

2. Catch 11:06 bus.

3. Arrive at shopping centre

 

at 11:39.

4. At 11:42 commence shopping.

5. At 12:57 finish shopping.

6. Arrive at restaurant at 13:00 for meal.

7. Finish meal and pay bill at 14:10.

8. Catch 14:15 bus home.

 

This world is akin to your detailed planning of routes and

 

timings. There is scope for things to go wrong with the plan. It will most likely take longer than expected. You may be lucky but the more times you try it, eventually it WILL fail.

 

So what would the event-driven plan look like. Perhaps something like

 

this.

1. Leave house at 11am and walk to bus stop.

2. Catch next bus.

3. Arrive at shopping centre. This should be 11:39, in which case continue with plan. If it's later then consider changing plan - you may wish to eat straight away to avoid longer

 

queues later.

4. Assuming we stick to our original plan, do our shopping.

5. At 12:57 revise our plan if necessary. Have we completed the shopping? Do we finish shopping regardless, not eat or get a later bus home?

6. Carry out the rest of our (revised)

 

plan at the shopping centre.

7. Go to bus stop.

8. Catch next bus home.

 

This is much more real-world. We have a sort of plan which, as events occur (eg the bus detector tells us it is 20mins late !), we change/refine as necessary.

 

So, for

 

loco detection, we still have a route/plan but it's mostly in our head with only small bits prescribed/coded (eg we know precisely how long it will take us to walk to the bus stop or a train to wait at a station for passengers). As the route/plan progresses

 

we revise it as events are notified to us (eg train breaks down so all routes passing that point are suspended until train removed.

 

Yes, its much, much more complicated, but so is the real world. You may have a plan of how long it takes to go from station

 

A to station B but in reality the time it takes is dependant on how quick it is 'passed' from signal to signal. How long it should take is almost irrelevant - what is more important is knowing that it has arrived at station B. Our routes/plans just have to

 

be flexible and responsive to events (detections) that happen.

 

Hopefully that makes some sense!