v1.48 Accelerate/Decelerate commands

[St1ngr4y]

I've just downloaded v1.48 using www.powerpos.com/rail-master/rm_setup148.exe and I find that some of my programs which use accelerate/decelerate commands are not working as far as timing is concerned. It seems to be most apparent when running a program

 

in design mode. The accelerate/decelerate commands used to adjust a loco's speed by increasing/decreasing by 1 speed step every second. In design mode, it now seems to adjust every 2 seconds or so. Can anyone else confirm this before I raise a fault with Hornby?

Ray

[St1ngr4y]

Since no one has replied to this thread, I am assuming it is because no one has encountered this problem. I raised a fault with Hornby and they have replied to say that changes have been made to the acceleration/deceleration commands in v1.48. They have

 

changed the syntax of these commands to add to the end of each command an additional optional parameter. This is described in the guide .pdf, but they didn't bother to mention it in Release Notes.txt. The new syntax is:

Accelerate/Decelerate Forward/Reverse

 

[a] to , i

 

The new parameter is described thus:-

 

The “i” parameter is optional and specifies the interval to update the speed.

The default is 1mph per second. I can be any value in tenths of a second.

 

I also received this message

 

by email:-

"After looking into this further the default update interval is 1.09 seconds whereas prior to the new feature being added it was 1.01 seconds (on average).

 

You will need to make minor amendments to your programs where you have used acceerate

 

or decelerate commands. You can either issue the accelerate/decelerate command slightly earlier in your program, or add the parameter ", 0.9" to the end of all accelerate/decelerate commands. You may need to play with the number however you can use any number

 

from 0.1 upwards."

 

I have changed a couple of programs to add ,0.9 to the end of accelerate/decelerate commands and they now work as before in the main window, but in design mode, the value being used still seems to be around 2, rather than 0.9 or 1.

 

I

 

am awaiting further news from Hornby CC.

Ray

[St1ngr4y]

I now find that accelerate/decelerate commands operate at different rates in a program when that program is chained i.e. I develop a program which starts and stops a train exactly where I want it to, but then when I incorporate it into another by using

 

the chain command, the train no longer stops where it should. I am surprised that no one else has noticed these problems which I am encountering with RM v1.48.

[Fishmanoz]

Seems you're ahead of the pack on this one. Can I suggest that you try downloading v1.48 again to make sure you have the latest, if you haven't done so recently. To my knowledge, there have been at least 3 iterations of this version - can't remember how

 

old the latest I have is but will check the downloaded file date tomorrow.

[St1ngr4y]

Having had no resolution of this problem, I decided that a computer upgrade might work. So a new Windows 8 machine was bought for my wife, replacing her Acer with Windows 7, which in turn replaced my old XP machine. Having deactivated the software on the

 

XP machine and saved to an external drive my layout file and all my program files and the resource file containing my loco definitions, I installed RM v1.50 from the internet, re-activated it and restored my saved files. I configured the COM port successfully

 

for the Elite. However, the problem described above still exists!!!!!! Yesterday, I allowed Railmaster Support to login remotely to my machine to see for themselves, but without any resolution. However, between us we managed to pinpoint the exact circumstances

 

where I have the problem.

To re-iterate the problem:

The accelerate/decelerate commands when executed in the editor window can use a slower rate than when the program is used in the live window. What I have discovered is this - if the editing window

 

is quite large i.e. displaying 25-30 lines of program, then an accelerate or decelerate command in the program executes at a slower rate than it should. If the window is reduced by dragging the bottom edge up until only, say, 5 or 6 lines are visible, then

 

the program executes as it should. I have been using a parameter of 0.9 on most of my accelerate/decelerate commands so that the speed change should be 1 mph per second. I would be most grateful if someone out there has the time to try experimenting for me,

 

to see if they see similar effects. Railmaster support can't reproduce it. I'm getting paranoid thinking it's only me even though it has happened on 2 different computers!!

[Fishmanoz]

Hi st1ngr4y, that sounds really weird and I don't have an answer for you. And it sounds like a bug for RM Support to fix but you might be lucky with someone else checking it out for you.

[LMSTim]

I've extended my programming screen so that I can see 24 lines of it. The program is about 70 lines long and it works fine for me using 1.50.

 

[Fishmanoz]

Does the program include adjustments to accel/decel occurring in the correct intervals Tim?

[St1ngr4y]

Tim,

If you have time could you try this experiment for me. Take your 70 line program and make a test copy of it. Then insert the following command somewhere in the middle:

Accelerate Forward [0] to [60],0.9

Any of your locos will do, and the

 

0.9 should cause the rate to be 1 speed step per second. If you could make the execution time end with 9, so 19 secs, or 29 secs etc. This way it will be easier to see if the clock is keeping pace with the loco speed. Then disconnect the Elite from the layout,

 

select all program lines for execution, and start the program off. Keep an eye on the loco speed in the main window. When the speed reaches 10, make a note of the time, then again at 20, 30, 40, 50 and 60. If it is behaving, then the times at these speeds

 

should be very close to start time + speed.

Many thanks, Ray

[St1ngr4y]

After months of to-ing & fro-ing with RM support, they have finally been able to replicate the problems I have been having with the accelerate/decelerate commands operating at different rates in the editing window to what they do in the main window. They

 

have tweaked the software so that, although there are still small differences depending on the number of editing lines which are on display, these differences are a lot smaller than those I had previously. After some timing testing, I can now run a program

 

in the editing window with 18 program lines on display, which causes the accelerate/decelerate commands to work as they do in the main window. RM's explanation:- "It seems that your computer/OS combination is not allowing the multiple timers used when running

 

programs in editing mode to run simultaneously correctly. This is what we changed in order for the software to run on your PC.". Personally, I don't accept this explanation, since I experienced the same problem on two different computers, one using Windows

 

XP, the other Windows 7. Anyway, if anyone installs v1.51 or later, they will get these changes. I hope the changes don't adversely affect anyone's existing programs!!

[LMSTim]

It is possible for programs with timers built in to run at different speeds on different PCs. I have seen this plenty of times myself over the years. The cause is usually software running on the PC that causes this to happen, not necessarily the hardware.

 

I have seen software actually slow down the built in clock, which you would think cannot happen, but it does.

 

RailMaster must use a variety of timers to track all sorts of things from running programs to sending commands to the controller and processing

 

returns. If you see this happening on two completely different PCs running two versions of Windows then I would look at the possibility of a common piece of software running on both PCs influencing the clock.

 

I know when I set up a new PC I always tend

 

to put a bunch of standard packages on it before even thinking about anything else, e.g. the same antivirus/firewall software, MS Office, CS5 and so on. Could it be a common piece of software that is causing this ... just thinking aloud here.

 

[St1ngr4y]

Tim,

I couldn't agree more with your statement "It is possible for programs with timers built in to run at different speeds on different PCs.". However, this wasn't the problem I was having. These are timers which behave differently in different parts

 

of Railmaster. You can't have a system which allows programs to be developed and tested in an editor until they execute satisfactorily, but then they execute differently when run in a 'live' environment. It defeats the object of having a development environment.

 

Ok, I accept that other software such as Antivirus may be executing in the background and may affect timers, but they should affect the timers in exactly the same way. It is the inconsistency between two different parts of Railmaster which is the problem.

[LMSTim]

With respect, you do not understand exactly how programs interact with the operating system. The program editor is a separate window which could well be loaded as an additional module and hence the timers within the program editing window (after all there

 

is a clock running when a test program runs) can therefore be affected.

 

We do not know how the software has been developed and so cannot hypothesise about what could be going wrong on your particular PCs. If the support guys say there is a timers issue

 

and they managed to recreate your problem and also provide a fix for you then why should they say that and why should you disagree? What possible reason would they have for giving you the wrong information if they a) identified the problem and b) fixed it.

 

I

 

think we ought to assume that the developers know a little more about how RailMaster works than we do.

 

[St1ngr4y]

Let me repeat what the developers said: "It seems that your computer/OS combination is not allowing the multiple timers used when running programs in editing mode to run simultaneously correctly. This is what we changed in order for the software to run

 

on your PC.". If it is down to either of my computers, then how can they provide a fix without knowing what make/model of computers they are or what other software is running in them? With regard to the 2 OS's Windows XP and 7, there must be hundreds of RM

 

users who use these.

The particular problem I had was with the behaviour of the accelerate/decelerate commands. Months ago I was told by RM support that when one of these commands is actioned then a separate process is started which then runs independently

 

of the initiating process until the range of its parameters is fulfilled. Such a process must have its own built-in timer and you would think that the code of such a process would be identical whether initiated by the editor or the main window.

[LMSTim]

There's no need to repeat yourself. I can read.

 

The bottom line is that you cannot know how the software works. You make several assumptions about how the software works without knowing. There is no point in speculating. If there is still an issue

 

just get in touch with RailMaster support.

 

[Fishmanoz]

I thought st1ngr4y said the difference is now much less and runs the same with only 18 lines of code showing?

[St1ngr4y]

I did say that, Fish, and I'm highly delighted that I can now get on and develop programs which won't need a lot of tweaking when I start to use them in the main window. However, I also said that I disagreed with the explanation the developers gave me

 

for the problem, and that is when LMSTim jumped to their defence.

OK here's another one which I've passed on to the developers - if no one else recognises the symptoms, I guess it must be my computer/OS again. This one doesn't involve the editing window,

 

but it does involve the accelerate/decelerate commands and the new chain command. I have 2 programs A & B. Program A takes a train from hidden sidings and DECELERATEs it into a station platform. Program B ACCELERATEs the train from the station, then DECELERATEs

 

it back to its starting position in the hidden sidings. Both programs work perfectly when run as individual programs in the main window. The finishing position back in the hidden sidings is never more than an inch away from where it should be. Program A lasts

 

70 seconds. When the chain command was introduced, I created a program, C, which contained only 2 commands - Chain A followed by, at 75 secs, Chain B. When program C is run, the first phase (A) works ok and the train stops in the station perfectly. However,

 

when the second phase starts, the acceleration rate of the train is different. Colour light signals change to red before the train has reached them, rather than just after, and the train stops a good 3 feet short of where it should in the hidden sidings.

Has

 

anyone noticed this symptom?

[LMSTim]

It is not about "jumping to their defence". It is about using and stating the facts and wondering why you would question the developers comments when surely they know better than you how the software works.

 

 

[St1ngr4y]

You just can't see my point of view can you? They say the problem was caused by my combination of Computer/OS. All I'm saying is, how can this be when I've had the same fault on two different computers each with a different OS. Surely you can see how unlikely

 

this is? If they had said "It is probably caused by another piece of software running on both computers" then I may have been persuaded.

Anyway, let's not continue this pointless argument.

[LMSTim]

I can see your point of view. There is no need to be patronising. I simply do not agree with it. You also disregarded what I said about having the same software on both PCs that might, unwittingly, be affecting RailMaster. I have been in I.T. for 30 years

 

so please give me some credit.

 

The argument RailMaster support gave you is plausible AND they fixed your problem. Surely that is an end to it. Just be grateful that they are clearly helping you with this issue that nobody else seems to be having (therefore

 

highly likely that it is linked to YOUR computers).

 

 

[St1ngr4y]

I most certainly did not disagree with your comment about having the same software on both pcs - read again my last post. Don't accuse me of being patronising. I was a computer programmer for 39 years before retirement, with experience of mainframes down

 

to pcs, and high-level languages down to assembler. You sound like you are one of the RM developers in disguise!!

[Fishmanoz]

Tim, you are clearly very knowledgable in this area and you have made a lot of great contributions to the forums as a result. But when you get in this mood and appear to defend Hornby and their developers just for the sake of it, it can be very tedious.

 

The differing points of view here have been stated and rebutted, we can all see what they are. Getting personal doesn't add to the argument. Surely enough has been said.

[St1ngr4y]

I couldn't agree more - life's too short.