Loco Detection (2)

[Fishmanoz]

PJ_model_trains said:

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.

Not getting though am I? One last try.

You have it almost right PJ, except why are you putting the loco back to STOP. There

is no need. Leave it running and let the LD system handle it as it proceeds down the line. Including stopping it for the late goods or, if it is the goods, stopping it and putting it in a siding to give priority to the express.

The program doesn't

run the train down the track, it sets the initial conditions needed to get everything ready for it and send it on its way. Then the LD system handles it en route. Maybe you'll run another program at an intermediate sensor, like one to get it in the siding,

then a second to get it out again and start it back on its way. These programs will only run if needed. They'll be conditional on what is found at the intermediate point and what other trains are doing.

As we have both said, route-running programs

won't work as LD defined contingencies will interrupt them and they'll fail. But programs as I've described will work fine as they'll have been run to completion before another LD point has been reached, so they can't be interrupted.

[Fishmanoz]

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.

I doubt very much the new IP will be in the detector, that being a very well researched area. We've already said the clever part is how you use the detection data, so that is where I think they have a

chance to innovate and patent. So that is also where they won't be telling us any more then is already in the public domain, at least until patents are granted.

[PJ_model_trains]

MetmanUK said:

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!

Hi MetmanUK

What you have written is common sense and if I get behind time

I have a McDonald's instead of a meal etc!

That is not the issue it is using a program in RM and sensors programs for LD in RM which I have expressed concern from the beginning they would clash. You are trying to explain in catch a bus basics, I don't

want a bus I want to run trains. I apologise you are finding this frustrating, so am I trying to get my point over. Maybe I am not explaining adequately.

When you set a program it wants a time duration at each stage, plus anything switched on must be

switched off, the program says so.

You say... 'So, for loco detection, we still have a route/plan but it's mostly in our head' does British Rail run like this? They have time tables and priorities (and still don't run on time) included for a bit of

humour ;-)

[PJ_model_trains]

Fishmanoz said:

Not getting though am I? One last try.

You have it almost right PJ, except why are you putting the loco back to STOP. There is no need. Leave it running and let the LD system handle it as it proceeds down the line.

Including stopping it for the late goods or, if it is the goods, stopping it and putting it in a siding to give priority to the express.

The program doesn't run the train down the track, it sets the initial conditions needed to get everything ready

for it and send it on its way. Then the LD system handles it en route. Maybe you'll run another program at an intermediate sensor, like one to get it in the siding, then a second to get it out again and start it back on its way. These programs will only run

if needed. They'll be conditional on what is found at the intermediate point and what other trains are doing.

As we have both said, route-running programs won't work as LD defined contingencies will interrupt them and they'll fail. But programs as

I've described will work fine as they'll have been run to completion before another LD point has been reached, so they can't be interrupted.

Hi Fishy

I am sorry to frustrate a few on this topic, maybe I am not explaining myself adequately.

From

the beginning I have expressed my concern regarding Programs in RM conflicting and changing times and distance when using LD sensor programs at the same time. We have moved on a little and agree with this.

Now we have a slight slant to the situation.

Maybe a chink of light, maybe not I will try another angle.

Earlier today I put a very simple program for RM which was...

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

You are now saying... 'why are you putting the loco back to STOP.'

When I started the program I had

10 seconds - Choose

loco set sound on
20 seconds - Forward to shunt
40 seconds - Forward to cruise

I tried to save it and it told me I had to have a switch OFF command anything that had a switched ON command.

So I did as advised by the software to the

best of my knowledge.

I switched sound on so I had a command to switch it off
I set my loco to shunt then cruise so I had to switch it off, in other words stop it.

I have not tried it yet we have just come home but, if I do as you request

and remove the STOP I then have...

10 seconds - Choose loco set sound on
20 seconds - Forward to shunt
40 seconds - Forward to cruise
70 seconds - Sound Off

So the train continues GOOD but the sound switches off NOT GOOD?

You

have no doubt tested what you say, I have done as above and has the software requests. I can only assume you have not run a loco with sound?

I welcome your comments, preferably not... one last try!

[PJ_model_trains]

Fishmanoz said:

Not getting though am I? One last try.

You have it almost right PJ, except why are you putting the loco back to STOP. There is no need. Leave it running and let the LD system handle it as it proceeds down the line.

Including stopping it for the late goods or, if it is the goods, stopping it and putting it in a siding to give priority to the express.

The program doesn't run the train down the track, it sets the initial conditions needed to get everything ready

for it and send it on its way. Then the LD system handles it en route. Maybe you'll run another program at an intermediate sensor, like one to get it in the siding, then a second to get it out again and start it back on its way. These programs will only run

if needed. They'll be conditional on what is found at the intermediate point and what other trains are doing.

As we have both said, route-running programs won't work as LD defined contingencies will interrupt them and they'll fail. But programs as

I've described will work fine as they'll have been run to completion before another LD point has been reached, so they can't be interrupted.

Hi Fishy

I am sorry to frustrate a few on this topic, maybe I am not explaining myself adequately.

From

the beginning I have expressed my concern regarding Programs in RM conflicting and changing times and distance when using LD sensor programs at the same time. We have moved on a little and agree with this.

Now we have a different angle to discuss.

Earlier

today I put a very simple program for RM which was...

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

You are now saying... 'why are you putting the loco back to STOP.'

When I started the program I had

10 seconds - Choose loco set sound on
20 seconds - Forward to shunt
40 seconds

- Forward to cruise

I tried to save it and it told me I had to have a switch OFF command anything that had a switched ON command.

So I did as advised by the software to the best of my knowledge.

I switched sound on so I had a command

to switch it off
I set my loco to shunt then cruise so I had to switch it off, in other words stop it.

I have not tried it yet we have just come home but, if I do as you request and remove the STOP I then have...

10 seconds - Choose loco set

sound on
20 seconds - Forward to shunt
40 seconds - Forward to cruise
70 seconds - Sound Off

So the train continues GOOD but the sound switches off NOT GOOD?

You have no doubt tested what you say, I have done as above and has the software

requests. I can only assume you have not run a loco with sound?

I welcome your comments, preferably not... one last try!

[Fishmanoz]

Just checked the manual and can't see anywhere it tells me I have to stop what I start. Do you have a page reference?

 

All the example programs do have stops but without LD things would go on forever without a stop. With LD, it can stop them.

[Fishmanoz]

Ok, you posted the answer while I was typing. But you can still get around it. Put stop after a long time, the exact time being irrelevant. Then the LD system will interrupt and stop the program before the program stops the loco. And everything except

 

that stop command will have been completed before interruption as everything else is initial conditions.

[PJ_model_trains]

Fishmanoz said:

Ok, you posted the answer while I was typing. But you can still get around it. Put stop after a long time, the exact time being irrelevant. Then the LD system will interrupt and stop the program before the program stops the

loco. And everything except that stop command will have been completed before interruption as everything else is initial conditions.

At last we are getting somewhere. Our Eureka moment ;-)

It is easy to get frustrated with someone and

them with you but there always has to be a reason. We were looking at the target but from different angles. I felt frustrated because people were repeating what I had already said, as if I didn't understand, I felt frustrated, almost to the point of feeling

people thought I was thick, but the examples provided to me were not what I was aiming at, which was avoiding clashes between RM programs and LD sensor programs and with what I was experiencing it didn't at that time possible.

In the end I felt the

only way, although with quite long replies, was to provide my example so you could see where I was coming from, I am glad I did as it could have run on except for statements like 'one last reply' for which I felt was totally unnecessary and uncalled for.

I

cannot help but wonder now if anyone did test it out on track, if it had been tested out people would have known, as I found out, that you have to add the 'command off' command.

Not to worry we have moved forward a little more today. If I frustrated

the hell out of anyone I can only apologise, I feel I had reason for concern initially with system conflicts and then with the situation now discussed. Thank you for your patience.

[St1ngr4y]

Hi PJ & Fishy,

The message you get from RM when you save a program usually refers to latching functions sound on/off and lights on/off. This message is something I disagree with Hornby about. Why do they insist on sound or lights being switched off

 

in a program which has switched them on. I have programs which take trains from hidden sidings and stop at the station. At the start of these programs, the loco sound and lights are switched on, but I don't want to switch them off again in the same program

 

because the train has arrived in the station. I have complementary programs which return the trains from the station to the hidden sidings, and these finish with switching the sound and lights off. I get the same annoying message when I save these programs

 

too. I just try to ignore them.

Ray

[PJ_model_trains]

Hello Ray

 

I am now kicking myself, I know you have done a lot with RM programs, why didn't I speak with you. No disrespect to MetmanUK and Fishy here.

 

I think the reason Hornby make you switch these features off is in case you have a problem

 

and start again. If the features have not been switched off then there will be reverse problems and people would complain sound and lights is switched or programmed on but they are off.

 

When I was testing a program route I found this, I was running

 

a loco from A to B to stop exactly where I wanted it in another station. At first it stopped short then I adjusted it, then I stopped it and took the loco to the start to start again and what I have explained happened to me and I wondered why there was no

 

sound.

 

So if you have a program that runs perfectly, as I am sure you have many now Ray, you would not get the problem but, for anyone who runs an unfinished program this could happen to them. The answer is, if you didn't finish a program and you are

 

starting again. May sure sound and lights features like this are put back to the off position before you restart.

 

PJ

 

[St1ngr4y]

Hi PJ,

This brings us to another of my gripes, but it's not with Hornby, it's with the whole DCC concept of so-called 'latching' functions. In RM, these are identified by including 'on/off' in its description. The commonest are sound on/off and lights

 

on/off. RM (or even your controller) cannot send a command saying switch sound on. Nor can they send a command saying switch sound off. All they can do is send a command saying "flip the sound status". i.e. if sound is on switch it off, if it's off switch

 

it on. Why oh why couldn't they have allowed two function codes for sound, two for lights etc. e.g. F0 = lights on F1 = lights off F2 = sound on F3 = sound off.

Ray

[PJ_model_trains]

I am only assuming Ray,

 

That was how they started and maybe they did so to preserve the number of functions for other things.

 

We may complain if 4 functions were used just to put sound and lights on and off.

We may say,

 

what a waste of functions.

 

We may ;-)

 

Sorry I haven't taken any Hornby tablets, honest ;-)

 

PJ

[RDS]

St1ngr4y said:

.... Why oh why couldn't they have allowed two function codes for sound, two for lights etc. e.g. F0 = lights on F1 = lights off ...
Ray

I think I also asked for this in our 'Desirable features' thread.
I

do like to switch lights ON at the start of my programs and OFF at the end (or when the Loco stops) but sometimes the 'ON' does not work, so when it toggles at the end of the program, the lights come ON.

[St1ngr4y]

If on and off were separate functions, you could do two on's at the start and two off's at the end, to make sure :-)

[St1ngr4y]

PJ_model_trains said:


We may complain if 4 functions were used just to put sound and lights on and off.
We may say, what a waste of functions.

We may ;-)

PJ

CV's (I think) are 8-bit bytes which can hold

values of 0 to 255. I'm guessing that the function code sent along the DCC bus is probably an 8-bit byte, which would give us F0 thru F255 perhaps ... maybe ... only guessing :-)

Ray

[Gregd99]

Fishmanoz said:
We've already said the clever part is how you use the detection data

I wasn't aware of that. Are you able to provide the link?

That would indeed be novel.... as there has been much scientific and industrial research

on train control over many years.

[Fishmanoz]

St1ngr4y said:

CV's (I think) are 8-bit bytes which can hold values of 0 to 255. I'm guessing that the function code sent along the DCC bus is probably an 8-bit byte, which would give us F0 thru F255 perhaps ... maybe ... only guessing :-)

Ray

Not

quite true Ray. Functions are controlled by CVs33-46 but these CVs aren't allowed the full 255 values. For the long and complicated explanation, see the NMRA spec for them at http://www.nmra.org/standards/DCC/standards_rps/rp922.html

[Fishmanoz]

Gregd99 said:

Fishmanoz said:
We've already said the clever part is how you use the detection data
I wasn't aware of that. Are you able to provide the link?

That would indeed be novel.... as there has been much scientific and

industrial research on train control over many years.

Nothing authoritative Greg, just the opinions of various people on this thread.

[walkingthedog]

Do I take it that all the details about how detection will work is now available going by the amount of amazing detail you are going in to?

[PJ_model_trains]

No wonder Ray wants Loco Detection, he has hidden sidings ;-)

[St1ngr4y]

PJ_model_trains said:

No wonder Ray wants Loco Detection, he has hidden sidings ;-)

They are only hidden from the viewing audience, not from the operator :-)

Ray

[Fishmanoz]

walkingthedog said:

Do I take it that all the details about how detection will work is now available going by the amount of amazing detail you are going in to?

Not quite WTD, more informed speculation.

There is a lot of

detail in RM already to start from. Even without the hardware, you can put a loco detector into your schematic, then when you right clock on it, it brings up its setup window such that hen you then click in the white area in the window, it gives you a lot

of programming options.

If you now go back to page 16 of this thread, PJ has listed those commands. Then read from there what has been figured out.

[Fishmanoz]

Tick it, don't tock it, or something like that.

[walkingthedog]

That's not speculation it's pages and pages of ...... Well you tell me.

 

Is the stuff on a Railmaster what they were going to do before eureka or what they plan to do since the Eureka moment. I wouldn't have thought they'd have put a single clue

 

on anything until the patent is signed and sealed.

[Fishmanoz]

We don't know the answer to that WTD. But I agree they won't have said anything about what they are patenting. If they do, they can't patent it.

 

I do wonder if some of our speculation bears on the patent though. Time will tell.