Programming to Automate your layout

[johnbet]

Could anyone assist with advice on the following with regard to programming to automate your layout on Railmaster please?

 

1. Whilst it it is possible to repeat an instruction a given number of times, is there any way a continuous loop can be established?

2.

 

Is there any way that simultaneous Instructions can be given?

3. Are there macro commands available, if so what and where are they?

 

Many thanks in anticipation.

[96RAF]

1. Not sure if you can loop infinitely or not - would need to RTFM again.

2. RM programming will warn that instruction timings coincide or are out of sequence, however you can run - say - loco A followed almost immediately by loco B and then fire point

 

1, etc thus nesting looping events. The problem with closely timed events is that the controller may skip a command.

3. RM programming is essentially macro commands only with a different front end to say Excel. i.e. it is an editable recording of keystrokes

 

played back upon command.

[johnbet]

RAF96 said:

1. Not sure if you can loop infinitely or not - would need to RTFM again.
2. RM programming will warn that instruction timings coincide or are out of sequence, however you can run - say - loco A followed almost immediately

by loco B and then fire point 1, etc thus nesting looping events. The problem with closely timed events is that the controller may skip a command.
3. RM programming is essentially macro commands only with a different front end to say Excel. i.e. it is an

editable recording of keystrokes played back upon command.

[johnbet]

RAF96 said:

1. Not sure if you can loop infinitely or not - would need to RTFM again.
2. RM programming will warn that instruction timings coincide or are out of sequence, however you can run - say - loco A followed almost immediately

by loco B and then fire point 1, etc thus nesting looping events. The problem with closely timed events is that the controller may skip a command.
3. RM programming is essentially macro commands only with a different front end to say Excel. i.e. it is an

editable recording of keystrokes played back upon command.

[johnbet]

Thanks RAF

 

The manual is a little less than helpful on these matters, guess it may have to be trial and error.

 

johnbet

[96RAF]

There are 2 possibilities as I see it - use the repeat command for 999 times (P80 of manual) or use scheduling to repeat a program, although scheduling doesn't as far as I can see allow inter-overlapping of programs i.e. start program 1 followed by program

 

2 before program 1 has completed.

Others may know more...

[RDS]

RAF96 said:

.... doesn't as far as I can see allow inter-overlapping of programs i.e. start program 1 followed by program 2 before program 1 has completed.
Others may know more...

There is a 'CHAIN' command that is supposed

to do just that but I (and a few others on here) have not had too much success with it. HRMS have indicated that there are some changes in the next RM update that should assist.

The problem that I had was 'CHAIN' always started the programs but the

trains that were started in the program, never stopped. That was months ago and I guess if I had not intervened, they would still be running now!

[St1ngr4y]

How about this for continual repeating of a program...

1. Use the scheduler to run the program at, say, 02:00:00

2. Place as the last command in your program a "Set time" command to 01:59:55

3. To fire it all off, set the RM time to 01:59:55

 

Ray

[St1ngr4y]

RDS said:

There is a 'CHAIN' command that is supposed to do just that but I (and a few others on here) have not had too much success with it. HRMS have indicated that there are some changes in the next RM update that should assist.

The

problem that I had was 'CHAIN' always started the programs but the trains that were started in the program, never stopped. That was months ago and I guess if I had not intervened, they would still be running now!

Hi RDS,
I've been experimenting

with programs involving the CHAIN command, and I've hit a problem which I think is similar to yours, but not exactly the same. I wanted to create two programs for the same train. Both programs would bring the train from its hidden siding and stop at the station.

This would be the end of the first program, but the second I wanted the engine to uncouple from the train, which involves reversing for about half an inch then going forward half an inch. So the second program looks like this:-
0.0 CHAIN Program A (which

is 62 seconds long)
67 Loco F4 Whistle
69 Loco Reverse to [2]
72 Loco Stop
77 Loco F10 Coupler
81 Loco Forward to [2]
83 Loco Stop

When I first ran this program, the very last command 83 was not obeyed, so the loco trundled away on

its own :-)

I tried it a couple of times more and the same happened. So I added an extra command 90 Play a sound
This time the program behaved as I wanted it to, but the sound never played. It looks like RM omits the final command in this scenario.

The end of the log file is interesting:-
23/04/14 18:15:29 01:02 Executing: Stop for: 60139 Sea Eagle ................ this is the last command in Program A
23/04/14 18:15:34 01:07 Executing: F4: Whistle 3 for: 60139 Sea Eagle
23/04/14 18:15:36 01:09

Executing: Reverse to [2] for: 60139 Sea Eagle
23/04/14 18:15:39 01:12 Executing: Stop for: 60139 Sea Eagle
23/04/14 18:15:44 01:17 Executing: F10: Coupler for: 60139 Sea Eagle
23/04/14 18:15:48 01:21 Executing: Forward to [2] for: 60139 Sea Eagle
23/04/14

18:15:50 01:23 Executing: Stop for: 60139 Sea Eagle
23/04/14 18:15:50 00:00 Executing: for:

The last line of the log should have reflected the "lay sound"command which I added. Is this anything like your problem and have you reported a fault to

HRMS?
Ray

[RDS]

@St1ngr4y

Hi Ray

I have also had the problem where the 'for:' line appears. It is just like yours because it appears with 00:00 where the time is usually shown. I have not looked at it since, or even tried to write a program with the Chain command

 

since then. Looking at my .txt listing now though, there are no 'Stop' commands for my Bmann loco's. Maybe they have been replaced by the 'for:' line in the listing. Yes, I did contact HRMS and they responded, asking for copies of my programs. This was last

 

November as you will see from the date on the txt file (copied below) I sent at the time. I have not had any further contact but I think I read somewhere that changes are planned for the chain command in a future update. Fingers crossed!

 

23/11/13 09:21:15

 

00:01 Executing: Zoom 50%

23/11/13 09:21:30 00:16 Executing: Reverse to [30] for: Hornby LMS 0-4-0 16023

23/11/13 09:21:30 00:00 Executing: for:

23/11/13 09:21:33 00:19 Executing: Accelerate Reverse [0] to [3] for: Bmann Class 47

23/11/13 09:21:35

 

00:21 Executing: Accelerate Forward [0] to [30] for: Bmann Class 37

23/11/13 09:21:36 00:22 Executing: Zoom 50%

23/11/13 09:21:37 00:23 Executing: Forward to [30] for: Bmann Class 20

23/11/13 09:21:40 00:26 Executing: Accelerate Forward [0] to [30]

 

for: 2-6-4T Class 4MT LMS

23/11/13 09:21:44 00:30 Executing: Stop for: Hornby LMS 0-4-0 16023

23/11/13 09:21:54 00:40 Executing: Forward to [30] for: Hornby LMS 0-4-0 16023

23/11/13 09:21:54 00:00 Executing: for:

23/11/13 09:21:54 00:00 Executing:

 

for:

23/11/13 09:22:15 01:01 Executing: Reverse to [30] for: Hornby LMS 0-4-0 16023

23/11/13 09:22:29 01:15 Executing: Stop for: Hornby LMS 0-4-0 16023

23/11/13 09:22:35 01:21 Executing: Decelerate Forward [30] to [15] for: Bmann Class 37

23/11/13

 

09:22:35 00:00 Executing: for:

23/11/13 09:22:35 00:00 Executing: for:

23/11/13 09:22:35 00:00 Executing: for:

23/11/13 09:22:39 01:25 Executing: Forward to [30] for: Hornby LMS 0-4-0 16023

23/11/13 09:22:52 01:38 Executing: Stop for: Hornby

 

LMS 0-4-0 16023

[PJ_model_trains]

You guys RDS & St1ngr4y are doing a wonderful job. Publishing these situations for HRMS and members of the forum to see.

 

I kicked programming in to touch due to comments in the earlier days, as nothing was mentioned much afterwards I thought things

 

were the same. Programming was not accurate and got worse with recurring use.

 

You guys have brought it to the front again, important as we will probably use it more with Loco Detection, keep up the good work.

 

 

[RDS]

Hi PJ

Thanks. I must point out that the only problem I have had with programming RM is with the Chain command. Other than that, I have found it to be superb.

I have one program I use a lot.

My layout (no secenery, other than a few 1960's cars)

 

has 4 concentric ovals with multiple sidings and a turntable in the middle. I have arranged the sidings so that I can have 4 loco's that run forwards and backwards, end to end, with a buffer at each end. I realise that my layout would hold no interest at all

 

for a true serious model railway enthusiast.

I have written a program that involves 8 loco's (4 around the loops and another 4 in the sidings). The program is 3 minutes long. The trains start and stop, forward and reverse at various times and at a few times

 

during the 3 minutes, they are all moving together. I have included a repeat command at the beginning of the program and I have a few versions of the same program that just contain a different number in the repeat command. The one I use the most I guess is

 

the 3 times repeat, so about 9 minutes in total.

I just love setting this program running and watching the trains go by and my grandchildren like to see Thomas and Bill running up and down the sidings.

I have the Elite controller, so I can take manual

 

control if I wish.

I will get more adventurous I am sure when detection comes out.

As I have said before, all this (including the turntable) is with just one connection to the track via an R8206 on the outer oval.

[PJ_model_trains]

RDS said:

I just love setting this program running and watching the trains go by and my grandchildren like to see Thomas and Bill running up and down the sidings.

It sounds brilliant.

Thanks also for the confirmation

that other than the Chain command, you have not had any problems. Do you find the stopping position to be accurate each time? I need to play and test more but at the present time I am putting static grass on a hill near the track so all trains are out of the

way, the stuff gets all over the track and surrounding area. I quite like the modelling side of the hobby as well.

[St1ngr4y]

PJ_model_trains said:
Do you find the stopping position to be accurate each time? I need to play and test more but at the present time

I use the accelerate/decelerate commands to start/stop trains. I find I can achieve very realistic

movements with these commands, rather than relying on the acceleration/deceleration CVs in the loco's decoders. I find the best way to gain accuracy in stops, is to decelerate to a crawl (scale walking speed say 3 mph) and proceed at this for 3 or 4 seconds

before stopping. Have a go with these commands and see what you think.

Ray

[96RAF]

St1ngr4y said:

I use the accelerate/decelerate commands to start/stop trains. I find I can achieve very realistic movements with these commands, rather than relying on the acceleration/deceleration CVs in the loco's decoders. I find the best

way to gain accuracy in stops, is to decelerate to a crawl (scale walking speed say 3 mph) and proceed at this for 3 or 4 seconds before stopping. Have a go with these commands and see what you think.

Ray

Despite having set the option

of a controlled stop I still get those locos with their accel/decell CVs set to 5 skidding to a handbrake stop. Those with the CVs set to 15 are a tad more gentile. My layout is too short for any longer a speed transition.

[RDS]

PJ_model_trains said:

... Do you find the stopping position to be accurate each time? ...

Sorry, I don't know too much about that, basically because it doesn't matter to me. I will look at that more when detection comes

out and I will then allow a loco onto the turntable. At the moment it just turns on its own.

[RDS]

@PJ_model_trains

I should have added, I don't think it is RailMaster or it's program that will affect the accuracy of the stopping position. It is the loco and as Ray says above, the speed at which it is travelling.

 

[PJ_model_trains]

St1ngr4y said:

I use the accelerate/decelerate commands to start/stop trains. I find I can achieve very realistic movements with these commands, rather than relying on the acceleration/deceleration CVs in the loco's decoders. I find the best

way to gain accuracy in stops, is to decelerate to a crawl (scale walking speed say 3 mph) and proceed at this for 3 or 4 seconds before stopping. Have a go with these commands and see what you think.

Ray

Hi Ray, thanks for sharing this.

That

was why I mentioned slowing to 4mph, to do exactly the same.

I think thinks will also improve with loco detection where we can check the distance to slow down then if 50mph is to fast come down a notch at a time and test each run. So that for example

46mph could slow the train to the the part where we can set it to 3 or 4 mph and then stop realistically. This was why I mentioned previously of maybe another sensor in the block between the two block markers. Speed control for slowing then stopping.

There

could be another advantage now with a short program in a point set up.

PJ

[PJ_model_trains]

RAF96 said:

Despite having set the option of a controlled stop I still get those locos with their accel/decell CVs set to 5 skidding to a handbrake stop. Those with the CVs set to 15 are a tad more gentile. My layout is too short for any

longer a speed transition.

Hi RAF96, every loco is different, it will be trial and error till we get it right. We are going to have a lot of fun running, testing and setting.

If the trains weren't run in they will be ;-)

PJ

[PJ_model_trains]

RAF96 said:

My layout is too short for any longer a speed transition.

I too don't have a large layout, I guess that sums up a lot of us.

Although the cruise speed of some trains is 65 mph I am already looking

at 50 mph as a more realistic speed for my layout. I will probably look at changing the CV's to slow down the cruise speed, but again, every loco is different and all will be tested one by one.

Drive at a speed that looks right for your layout and if

sound loco's the best sounding speed for your layout.

PJ

[PJ_model_trains]

RDS said:

@PJ_model_trains
I should have added, I don't think it is RailMaster or it's program that will affect the accuracy of the stopping position. It is the loco and as Ray says above, the speed at which it is travelling.

I

think you are right. And also that the track is spotless.

[Fishmanoz]

PJ_model_trains said:

There could be another advantage now with a short program in a point set up.

PJ

Given that the same program runs no matter which way the point is thrown, this feature has limited capability currently.

It will be useful for signals if they operate on a latching basis so switch from one state to the other when the point is thrown. They would be quite useless for running a train somewhere.

However, if conditional commands are introduced, they would

be much more powerful. By that I mean commands like if set left do this and if set right do that. Like the 7 conditional commands that are in sensor setup.

[PJ_model_trains]

Fishmanoz said:

PJ_model_trains said:

There could be another advantage now with a short program in a point set up.

PJ
Given that the same program runs no matter which way the point is thrown, this feature has limited capability

currently. It will be useful for signals if they operate on a latching basis so switch from one state to the other when the point is thrown. They would be quite useless for running a train somewhere.

However, if conditional commands are introduced,

they would be much more powerful. By that I mean commands like if set left do this and if set right do that. Like the 7 conditional commands that are in sensor setup.

I agree, it would open another door to controlling our trains.

[PJ_model_trains]

Hi Guys

 

Which do you find easiest or best? Writing a program or recording a program?

 

Today I have tried both and think I prefer the record a program and edit it. Trouble is if you use the slide controls (not recommended by Hornby) you get

 

a mile of code. Probably why they suggest not using it. Slight exaggeration I know but you get the point.

 

I found writing the code meant constantly running and checking stopping position. Where as with programming I didn't need to do it as much. Having

 

said that, when I had a string of speeds due to slow movement of the speed control, and the frustrating up and down a midges with the mouse to get 4mph I edited these out of the program then a slight tweak to make sure it stopped as planned. Hopefully the

 

larger touch screen will make setting loco speed to say 4mph much easier. I agree with Ray, shunt and cruise speed is not good enough, with steam locos the speed comes down gradually but 4mph is also needed for that nice clean stop. With DMU's and similar

 

the train jumps to shunt speed and lurches to cruise speed and the same principle when de-accelerating. For these I will use slide controls and if recording adjust the speed in steps.

 

I ran a steam loco with sound to do 4 stops. I also created another

 

route for a Class 153, edited them as above and then Chained them together. I need to tweak each program individually before running as a Chained program but it seems to work so far. Not sure about the last line mentioned by RDS & St1ngr4y I haven't completed

 

a full run yet so I will watch for that. Thanks for confirming this.

 

Has anyone come across any other problems or has any tips. What did you find worked best for you? Not checked yet, just a thought, does it make a difference if when Chained that two

 

locos have the same time slot?

 

As mentioned previously, I didn't bother with programming because I understood some people were having problems, I am now starting from scratch so am interested in any comments you may have.

 

At present we program

 

routes and chain them, looking for trains to run and stop as we have planned. I am assuming it will be even easier with loco detection, we set a train off on a route and have a long running period where we control between this with the information from the

 

sensors as the train passes over them.

 

All comments welcome

 

Thanks

 

PJ

[Fishmanoz]

PJ, if you are getting jumping and lurching under program control, you will be getting that under similar manual control too. Even though you can smooth it out by gradual throttle adjustment manually, this shouldn't happen if your CVs are well set up.

 

You should be able to go from stop to shunt to cruise smoothly, otherwise what is the point of defining these in the loco setup.

 

I would be looking at accel, decel, speed tables and back EMF for a start and assuming these are supported in your decoders.

 

Also, check the recent blue box decoder discussion on not running smoothly and manufacturer-defined CVs to adjust to fix this.