Help request - accelerate/decelerate commands

[St1ngr4y]

I reported a fault to RM support back in July and they haven't (so far as I know) been able to replicate it. If any RM user could spend 10 minutes on a small experimental program, I would much appreciate it.

Choose any of your locos which are defined

 

on RM and create this 2 line program for that loco:-

10 Decelerate Forward [51] to [0]

70 Stop

Give the program a name and save it. The loco you chose doesn't need to be on the track for this experiment.

Run the program in the main window with

 

the chosen loco's panel on view so that you can watch the speed. After 10 seconds the speed should show 50 and then start decreasing. As soon as the speed reaches 0, make a note of the program clock time.

Go back into the editor and change the times on

 

the commands as follows:

60 Decelerate Forward [51] to [0]

120 Stop

Save the changes, return to the main window and run the program again. You will have to wait, of course, for 60 seconds before the speed starts at 50, but again be ready to make a

 

note of the program clock time when the speed reaches 0.

I won't mention here what the values are that I get, so as not to influence the experiment, but if anyone can spare the time to do this and reply with the results I would be most grateful.

Ray

[RDS]

@St1ngr4y

I am surprised to see that the 1st line in your program is to decelerate.

How can it decelerate without accelerating first?

[St1ngr4y]

Hi RDS,

This program is simply an extract for experimental purposes, but you can have a program which for example, sets a few points and signals first then issues a Decelerate command. It is the same as having:

10 Forward to [50]

11 Forward to

 

[49]

12 Forward to [48]

etc. The first command would cause a fast acceleration to 50 using the speed curve CVs of the loco's decoder.

Will you have time to help me?

Ray

[RDS]

@St1ngr4y

I must apologise for not having done this test for you before but it had slipped my mind completely.

The results I get are:

1st program = 61.8 seconds

2nd program = 115.2 seconds

[St1ngr4y]

RDS said:

@St1ngr4y
I must apologise for not having done this test for you before but it had slipped my mind completely.
The results I get are:
1st program = 61.8 seconds
2nd program = 115.2 seconds

Many thanks

for that. The results I got were 61 and 115. If I use start times of 20, 30, 40, and 50, the elapsed times of the decelerations are 71, 82, 93, and 104. So the further down the program is the command, the slower the deceleration rate becomes. This is really

giving me a hard time producing programs. What I want to do is to produce one low-level program for each train movement, rather like you have done. Then produce high level programs with chain commands, to produce a myriad of different combinations of train

movements. But if I develop a program which has, say, an accelerate command at 10 seconds, followed later by a decelerate command at, say, 40 seconds, when run in isolation this would produce a far different behaviour than if the same program were chained

into another program at, say, 50 seconds, because the accelerate would now start at 60 seconds and the decelerate at 90 seconds!!!

By the way, how did you record the times so accurately? As I mentioned earlier today in the Desirable Features thread,

I have trouble seeing the seconds clock at the top of the main window.
Ray

[RDS]

@St1ngr4y

This is disappointing if we cannot obtain consistent results when running individual programs as opposed to chaining them from within another program because that means I would not be able to do what I was intending, which sounds very similar

 

to your situation.

 

I guess we have got almost identical times on these tests.

I cannot claim to have recorded the times so accurately but the figures are the ones I saw, when switching my eyes from the loco speed indicator to the clock.

 

I

 

noticed your posting in the Desirable Features thread and although I don't have a problem with this particular display, it is a bit of a pet hate of mine, when text is printed on a coloured background. Given the choice, I would go for Black text on a white

 

background.

[St1ngr4y]

What makes things even worse is that the rate of the acceleration/deceleration commands cannot be guaranteed to be the same when a program is run in the program editing window as it is when it is run in the main window. In fact the rate in the editing

 

window varies depending on how deep the window is i.e. the number of program lines you have on display!!!

Ray

[Fishmanoz]

Can I give my standard advice and suggest one or both of you emails RM Support and refers them to this thread for details of the problems. It certainly sounds to me as if you have identified a major flaw in the software which needs their attention.

[RDS]

@Fishmanoz

I took your advice from yesterday and I have emailed RM Support this morning, with my Chaining programs problem.

[St1ngr4y]

@Fishmanoz

 

As I mentioned at the start of this thread, I reported the problems with the accelerate/decelerate commands back in July. The other problem of differences between the editor and main screen timings, I reported even earlier in the year.

 

I believe they are revising the timing methods they use to be incorporated in a future release. I can't remember whether I saw that on this forum somewhere, or whether they mentioned in to me directly by email.

Ray

[Rog RJ]

St1ngr4y said:

@Fishmanoz

As I mentioned at the start of this thread, I reported the problems with the accelerate/decelerate commands back in July. The other problem of differences between the editor and main screen timings, I reported

even earlier in the year. I believe they are revising the timing methods they use to be incorporated in a future release. I can't remember whether I saw that on this forum somewhere, or whether they mentioned in to me directly by email.
Ray

I'm pretty

sure I read your previous post about the timing problem on this forum and the reply from the RM support stating that they would be addressing the problem.

[Fishmanoz]

My apologies, just noticed the start of the thread again. One thing you have shown now is that it is not just a one-off user peculiarity but something that can be replicated by another.

[St1ngr4y]

RDS said:

@St1ngr4y
This is disappointing if we cannot obtain consistent results when running individual programs as opposed to chaining them from within another program because that means I would not be able to do what I was intending,

which sounds very similar to your situation.

@RDS
This morning I downloaded v1.54 and one of the first things I tried was the test on acceleration/deceleration. This time I added, one second before the decelerate command,
set time:

23:59:59

This then acts like a stopwatch. If you have time, could you repeat the tests and if possible make a note of the stopwatch times as well.
Many thanks
Ray

[RDS]

@St1ngr4y

I was just about to add to this thread that the latest version (1.54) apparently includes some changes to the accel/decel command.

I will try your test out later as you have requested.

[RDS]

@St1ngr4y

Sorry, I did not get chance to run your test yesterday.

I have just done it though with the following results:

Program 1) 61 seconds (Stopwatch 52 seconds)

Program 2) 115 seconds (Stopwatch 55 seconds)

 

I have not tried to read

 

the seconds to the nearest 10th this time!

 

(I like your idea for a stopwatch, I would like to incorporate that in my programs, some of which have repeats in them and I am always wondering how many times the program has repeated)

[St1ngr4y]

@RDS

So to summarise:-

Program Version 1...

9 Set Time: 23:59:59

10 Decelerate Forward [51] to [0]

70 Stop

The elapsed time of the deceleration was 52 seconds

 

Program Version 2...

59 Set Time: 23:59:59

60 Decelerate Forward

 

[51] to [0]

120 Stop

The elapsed time of the deceleration was 55 seconds

 

So the later in the program that the decelerate starts, the slower is the decelerate process, and 3 or 4 seconds can make a difference of a couple of feet in where the loco

 

stops.

 

The conclusion, however, is that the fault still exists in 1.54, despite the statements in the release notes file about improvements to the accelerate/decelerate commands and timers.

 

Ray

[RDS]

@St1ngr4y

Ray, your summary is correct. I can imagine that there may be some slight differences because the computer may be doing something else at the time (Goodness know what!) but 3 seconds is excessive. Having said that, the Laptop I use for running

 

RailMaster is dedicated to my Model Railway.

 

How do these results compare with yours?

[St1ngr4y]

@RDS

By "doing something else at the time" do you mean, for example, downloading Windows updates? If so, it would have to be doing something similar each time you do this experiment. These results are repeatable. Using the 'stopwatch', I get 1:01 and

 

1:05.

 

Ray

[St1ngr4y]

@RDS

Oops - sorry. In my version of the programs, the deceleration is from 61 to 0.

 

Ray

[RDS]

@St1ngr4y

61 to 0!

You have moved the goalposts.

 

I was working on the programs you gave a few weeks ago at the top of this thread. I even have them stored in my programs list as:

Prog Test for St1ngr4y &

Prog Tesy2 for St1ngr4y.

I

 

have just added the stopwatch line to each of them today.

 

When I say other things, I do not mean updates. I do those last thing ata night, with nothing else (as far as I know running) I don't know what it may be doing. My desktop hard disk light just

 

comes on every now and again and I never know why. I must admit, I have not noticed the RailMaster laptop do it.

[St1ngr4y]

I am disappointed to find that this problem still exists in version 1.56. 

HRMS are you still looking into it or shall I report it again through the system?

Ray

[St1ngr4y]

I have been doing some more experimentation with the accelerate command. I created the following program:-

0.00 Program Command Play Sound
9.00 Program Command Set Clock: 23:59:59
10.00 0002 Test Loco Accelerate Forward [0] to [60]
80.00 0002 Test Loco Stop

The reason for the Set Clock command is so that the main RM clock at the bottom right of the main screen can be used as a sort of stop watch to do the timing. The purpose of the program is to measure the time in seconds that it takes for a loco to accelerate from 0 to 60. This is not a real loco we are talking about, it is a measurement of the way RM increases the speed of ANY loco using the accelerate command. My theory is that the RATE of acceleration applied by this RM command varies depending on the POSITION of the command within a program with respect to the start time of the program (in this first example 10 seconds).

When this program is run, all you need to do is to have the loco window visible for this loco, and to keep an eye on the speed as it increases. Then as soon as it reaches 60, make a note of the time shown on the RM clock in the bottom corner of the screen.

This first program behaves more or less as expected, the time taken being about 61 seconds. I then amended the program several times, each time by moving commands 2 3 & 4 forward by ten seconds i.e. highlight the Set Clock command and use the "Insert time/shift program steps" button.

These are the results after 30 edits and program reruns:-

Start Elapsed
10     61
20     61
30     62
40     63
50     64
60     65
70     65
80     66
90     66
100   66
110   65
120   66
130   66
140   65
150   66
160   65
170   65
180   66
190   66
200   65
210   64
220   63
230   62
240   61
250   60
260   60
270   60
280   60
290   60
300   60
310   60

As you can see, the command works fine if it is placed after 240 seconds into the program, or near the start of the program, but between 30 seconds in and 240 seconds in, the acceleration rate is slower than the expected 1 speed step per second.

Ray

[RDS]

Hi Ray

Fascinated to read this as I only deleted the programs I ran last year for you, earlier this week, whilst having a tidy up after defining a new program filename strategy for myself.

[idlemarvel]

I'll try this and get back to you with the results.

[idlemarvel]

My results (I didn't do all the timings)

10 61

20 61

100 68

200 66

250 62

So not dissimilar to your results.  I also tried "100" saved as a program and run from the main window instead of in  the program window, thinking that "tracing" might have an overhead, but it made no difference, still 68 seconds.