Chain Program command

[RDS]

I have written a program that consists of just four lines.

Each line is a Chain command to run another program.

 

Each of the 4 chained programs, which are just simple programs involving one (different) locomotive run perfectly as an individual

 

program but when I run the program containing the 4 Chain commands, the programs all start as expected but do not end.

The trains just keep on running.

Any ideas please?

[Deltic_Malc]

RDS said:

I have written a program that consists of just four lines.
Each line is a Chain command to run another program.

Each of the 4 chained programs, which are just simple programs involving one (different) locomotive run perfectly

as an individual program but when I run the program containing the 4 Chain commands, the programs all start as expected but do not end.
The trains just keep on running.
Any ideas please?

I think I had a similar problem. I put a command to stop

the loco as the last line in each program and I think that cured it.

[RDS]

@Deltic_Malc

Thanks, we have gone through a similar thought process here.

I have already tried that one.

Each of my programs has the stop command as it's last line.

[St1ngr4y]

Do the programs overlap timewise? What are the 4 times on the chain commands and what is the elapsed time of each individual program?

Ray

[RDS]

Ray, Actually, when looking to answer your question, I realised that there are 5 different programs that are Chained, not four, 1 of which is chained twice. So here goes...

 

Prog 1 (called Loop Class 20)

1 second, Accelerate Forward a Blue Box

 

Class 20 [0] to [30]

91 seconds, Stop

 

Prog 2 (called Loop Class 37)

1 second, Accelerate Forward a Blue Box Class 37 [0] to [30]

61 seconds, Decelerate Forward a Blue Box Class 37 [30] to [15]

120 seconds, Stop

 

Prog 3 (called Loop

 

Class 47)

1 second, Accelerate Reverse a Blue Box Class 47 [0] to [3]

71 seconds, Stop

 

Prog 4 (called Loop Class 4MT)

1 second, Accelerate Forward a Hornby Class 4MT [0] to [30]

91 seconds, Stop

 

Prog 5 (called Siding LMS 16023)

1.0

 

seconds, Reverse to [30]

15.0 seconds, Stop

25.0 seconds, Forward to [30]

38.0 seconds, Stop

42.0 seconds, End Program

 

The consolidated program is as follows:

1.0 seconds, Zoom 50%

1.5 seconds, Chain Loop Class 20

5.0 seconds, Chain

 

Loop Class 4MT

10.0 seconds, Chain Loop Class 37

16.0 seconds, Chain Siding LMS 16023

18.0 seconds, Chain Loop Class 47

60.0 seconds, Chain Siding LMS 16023

350.0 seconds, End Program

 

Incidentally, when I wrote another program to just

 

chain one of the programs (Class 20), it worked perfectly.

 

[Fishmanoz]

Suggest you email RM Support. They should be able to clear this one up for you in no time flat.

 

I get the feeling some are reluctant to do this. They are the first place I go for some things.

[Deltic_Malc]

RDS said:

Ray, Actually, when looking to answer your question, I realised that there are 5 different programs that are Chained, not four, 1 of which is chained twice. So here goes...

Prog 1 (called Loop Class 20)
1 second, Accelerate

Forward a Blue Box Class 20 [0] to [30]
91 seconds, Stop

Prog 2 (called Loop Class 37)
1 second, Accelerate Forward a Blue Box Class 37 [0] to [30]
61 seconds, Decelerate Forward a Blue Box Class 37 [30] to [15]
120 seconds, Stop

Prog

3 (called Loop Class 47)
1 second, Accelerate Reverse a Blue Box Class 47 [0] to [3]
71 seconds, Stop

Prog 4 (called Loop Class 4MT)
1 second, Accelerate Forward a Hornby Class 4MT [0] to [30]
91 seconds, Stop

Prog 5 (called Siding

LMS 16023)
1.0 seconds, Reverse to [30]
15.0 seconds, Stop
25.0 seconds, Forward to [30]
38.0 seconds, Stop
42.0 seconds, End Program

The consolidated program is as follows:
1.0 seconds, Zoom 50%
1.5 seconds, Chain Loop Class 20
5.0

seconds, Chain Loop Class 4MT
10.0 seconds, Chain Loop Class 37
16.0 seconds, Chain Siding LMS 16023
18.0 seconds, Chain Loop Class 47
60.0 seconds, Chain Siding LMS 16023
350.0 seconds, End Program

Incidentally, when I wrote another

program to just chain one of the programs (Class 20), it worked perfectly.

Have you tried it without the end program command after the 42 second on program 5?

[St1ngr4y]

Deltic Malc has spotted the problem. The resultant program (after the chaining) would look like this:-

1.0 seconds, Zoom 50%

2.5 second, Accelerate Forward a Blue Box Class 20 [0] to [30]

6 second, Accelerate Forward a Hornby Class 4MT [0] to

 

[30]

11 second, Accelerate Forward a Blue Box Class 37 [0] to [30]

17.0 seconds, Reverse to [30]

19 second, Accelerate Reverse a Blue Box Class 47 [0] to [3]

31.0 seconds, Stop

41.0 seconds, Forward to [30]

54.0 seconds, Stop

58.0 seconds,

 

End Program (from Program 5)

61.0 seconds, Reverse to [30]

71 seconds, Decelerate Forward a Blue Box Class 37 [30] to [15]

75.0 seconds, Stop

85.0 seconds, Forward to [30]

89 seconds, Stop

92.5 seconds, Stop

96 seconds, Stop

98.0 seconds,

 

Stop

102.0 seconds, End Program (from program 5)

130 seconds, Stop

350.0 seconds, End Program

 

So at 58 seconds, the merged program stops, leaving running a few locos.

 

Ray

[St1ngr4y]

By the way, the decelerate command which is obeyed in the composite program at 71 seconds, may take longer to achieve than when run in the original program at 61 seconds. This is why I was asking for help in the thread "Help request - accelerate/decelerate

 

commands", to which, disappointingly, only RDS replied to, and even then it was a reply with a question!

Ray

[RDS]

@St1ngr4y

Ray

Thank you very much for taking the time to put together such a detailed response. Unfortunately though, it has made no difference. I really felt that it would though because it seems to make so much sense.

Back to the drawing board!

 

Incidentally,

 

sorry you had to follow-up your posting with a reminder about your program from a month or so ago. Hopefully, better late than never, I have now done your test and posted the results I get.

[RDS]

@Deltic_Malc

Thank you very much for your suggestion. When I looked at it, I was convinced it was going to work. Unfortunately not though.

What I have noticed is that the program clock disappears (stops) at 97 seconds when running the consolidated

 

program.

[St1ngr4y]

Have you had a look in the LOG.TXT file in the Railmaster folder? Maybe you can glean something from that.

Ray

[Deltic_Malc]

I spent most of yesterday working with chain programs trying to get three programs running together and experienced a similar problem to you. When I was using the "repeat" command and a "chain" command within the "repeat". I removed the "chain" command

 

from the "repeat" loop and it was fine. I manually put the lines of the "chain" command into the "repeat" part of the program and it was ok. It was a bit long winded, working out the times but worth it in the end,. Hope this makes sense and helps.

[RDS]

@St1ngr4y

Sorry for the delay in responding but I had not noticed your reply.

I was not aware of that txt file but it certainly looks interesting.

I will check fully later but the first thing I have noticed it that there are a number of items

 

in the program execution that I do not recognise from my individual programs.

For example, where the program lines normally show the elapsed program time and the command,

i.e.

00:16 Executing Reverse to [30] for: Hornby LMS 0-4-0 16023

these

 

'extra' lines have an elapsed time of 00:00 with a command of Executing: for: and nothing else.

i.e.

00:00 Executing: for:

 

Thanks

[RDS]

@Deltic_Malc

I have just been made aware of a log.txt file in the RailMaster folder by Ray in his post above.

I will check it more closely when I have some time later but the txt file may help you as well. (unless you already knew about it)

In

 

one way it is good that you can also find a problem when using the chain command because it does tend to suggest that something is not quite right. I have not used the repeat command this time but I have used it very successfully previously but not in conjunction

 

with a Chain command.

 

[St1ngr4y]

Deltic_Malc said:

I spent most of yesterday working with chain programs trying to get three programs running together and experienced a similar problem to you. When I was using the "repeat" command and a "chain" command within the "repeat".

I removed the "chain" command from the "repeat" loop and it was fine. I manually put the lines of the "chain" command into the "repeat" part of the program and it was ok. It was a bit long winded, working out the times but worth it in the end,. Hope this makes

sense and helps.

@Deltic_Malc
I've just come across a problem with the repeat command, and the only reason I mention it here is that I remember you and RDS saying you had used them. The only time I've used them is for testing 'sticky' points.

What I've just noticed (and I can't say whether it has arisen since the last two versions 1.54 & 1.55 were released), is that the command following the Repeat command is skipped in every repeat. It is actioned first time through, but thereafter is skipped.

When you run such a program in the development window, the clock returns to the time of the instruction after the repeat, but does not action it. To test it I created a small program:-
0 Repeat [9] times
2 Program Command Play Sound "One"
4 Program

Command Play Sound "Two"
6 Program Command Play Sound "Three"
8 Program Command Play Sound "Four"
10 End Repeat

Of course, I used the full hierarchical file name of the sound files, but when the program runs, it goes:-
1 2 3 4 2 3 4 2 3

4 2 3 4...
Have you (or anyone else reading this) noticed this?

Ray

[RDS]

@St1ngr4y

Ray, I don't know whether this is of any relevance but Hornby mention somewhere in the instructions about sound files and leaving enough time after the command before the next one in order to allow it time to complete and pass control back

 

to the program.

It may be an idea to extend the time space between each to see if this has any affect.

 

[St1ngr4y]

@RDS

I thought of that so I highlighted line 2 and added 6 seconds from that point, so that the program became:-

0 Repeat [9] times

8 Program Command Play Sound "Two"

10 Program Command Play Sound "Three"

12 Program Command Play Sound "Four"

14

 

End Repeat

 

It was still the same and each time around the loop, it went straight from 14 End Repeat to 8 secs without the 6 second gap between the 0 Repeat and 8 Program Command, but it still didn't action the instruction at 8 seconds.

Ray

[St1ngr4y]

@RDS

I changed the first command after the repeat from Play Sound One to Display Message, and again the Display Message only appeared on the first pass.

Ray

[St1ngr4y]

Having been given a new loco as a birthday present from my wife, I have been creating a few programs to add to the portfolio.

With one program, the new loco pulls a rake of coaches into the station and uncouples. A second program takes the loco into a siding on the other side of the station. A third program fetches a different loco from another siding and backs it on to the other end of the train.

I decided to try merging these second and third programs together by creating a fourth program which contains two chain commands, these commands being at 0.00 seconds and 1.00 seconds respectively. Each of the chained programs start with changing of points and signals before the locos start to move. I've noticed that there are very rapid point changes carried out when the (fourth) program starts. Now I can understand that lines in the individual programs will have very similar times, and that the system is trying to interleave them. However, the points are firing even more rapidly than I would expect, and a closer look at the screen when the program starts and the program toolbar clock appears, reveals that the first time to appear on the clock is 4.00 seconds. I am guessing that the clock is being started before the merging of the chained programs has finished, so that when the merging has finished, and lines start to be executed, all of the lines which should have been executed in the first four seconds are executed very quickly (in less than a second) in an attempt to catch up with the clock. 

Has anyone else noticed anything like this?

Ray

[HornbyRailMasterSupport]

Sending commands to a DCC controller is an interesting area.

Unfortunately, DCC controllers in general, are not as sophisticated as many other devices in being able to cache command requests (or received data packets) and process them.  Due to the real time nature of model railways, i.e. that a loco stop must occur within a fraction of a second of a stop command being sent, there is no way that "parallel processing" can be employed to control a railway.  DCC controllers simply cannot cope with this type or amount of data being received.

RailMaster does a great deal of work internally to ensure that one command does not step over another.  The Chain command brings multiple programs together and must merge them into one sequential master program as, for the reasons mentioned above, multiple programs cannot run at the same time with the risk of sending data to the controller at precisely the same time.  RailMaster does incporporate a command queuing system however we must remember that functions like moving and stopping a loco must essentially work the same in a merged program as they did in the stand-alone program.  Also bear in mind that the more programs that are chained the more likely it is that timings will be slightly out due to power requirements of programmed devices (locos, point motors etc.).  Of course, Loco Detection will ultimately resolve this.

We are always looking at ways to improve RailMaster, especially given some of the limitations of both DCC controllers and the NMRA specification, and we want to squeeze the most out of both of these.  As you will all know, we also want to take the "dark art" out of DCC control, which is why we are doing so much work on pre-profiling locos, accessory decoders and loco decoders so that users don't have to remember lots of numbers or spend hours pouring through very complicated manuals.  We have taken this further in the latest version of RailMaster, to be released imminently.

[RDS]

@HRMS

That is an interesting reply you have posted, especially as the release of the latest version of RailMaster has now moved from being quoted as 'very soon' to imminent.

I am sure it is true to say, we are all looking forward very much to the release.

[96RAF]

I'm replying to hrms without the quote to save paper and would like to say thank you for the 'explanations'.

however despite the limitations of dcc command processing it should be possible to send a command for action, then another, then another. These could be playing a sound or controlling a loco or signal or why without having to wait for each action to complete such as a long sound playing out.

This based on my understanding of a recurring command such as sound on not requiring an end command before another dcc command is issued, so other like commands should run on without conflict unless a double command is issued in the same timeframe.

I trust this makes sense.

[gilbo2]

Some really helpful, constructive and informative posts today HRMS which I applaud, thank you. Are you a different person today :-)

[St1ngr4y]

That makes two posts from HRMS on two different threads in the last 24 hours, where the release of v1.56 has been described as IMMINENT !!

Ray