RM Editing programming

[Jailor]

Hi one and all.

Firstly Merry Xmas to Railmaster for a  great product and support for all users, also Hornby for there hard work and a BIG thanks to all forum user's for always helping out when newbies like me start modelling. Six months into this great hobby and pushing on nicely with my humble layout. 

BTW I look daily at the forum but only comment when I need to so although not on for a while ---- I am watching you !!!!  LOL.

Am I correct with my RM experience? I love the software and have no complaints but seem to struggle writing a programme. I spend hours, days, weeks getting everything as I want in the edditing section of RM. Then when I come to run the programme find the timing is always slightly different. After hours adjusting, things still seem to differ each run. 

I am guessing from my experience that it will always run slightly differently due to my track being spotless, slightly dirty or anywhere in between. This is incredibly frustrating, is this just me or the way things are?

Regards

Ron.

[PJ_model_trains]

Hello Ron

 

When I started to write programs in RM I did the same, started the hard way.  Then Ray came to the rescue!

 

What he suggested works... Put your train exactly where it will start from, then run 'Record' and run your train to the position you want it to stop.  You now have a program and can tweak it, that saves a lot of time.

 

What I now do is put my train exactly where I want it to start, press record. Alter all points from A to B so they are set for your route. Click them even if they are set correctly, this way you do not need to worry if they are right or wrong, they are corrected in your program at the start. Once I got used to this method, I them moved the point setting (and the time) so they changed as my train travels, when a signal changes one block back down the line from the points. This way if I have something else running (merged another program into this one) the points are not changed to soon by another train on another route.

 

Run it, save it, test it and tweak it until you get it where you want it. Just run one program until you get used to it and have it work as you want.

 

It's a lot of work but a lot of fun. It is certainly easier to record then tweak a saved program than program everything from scratch.

 

Ray (and others) have done a lot of programming than me, they will no doubt add what they have learnt also, I too will be watching and learning, that is what is good about this forum, there are a lot of good guys on here, very knowledgeable and always happy to help.

 

PJ

[PJ_model_trains]

Hello Ron

 

When recording your program, try do all the things you need to do in the program, it saves time and adjustment later.

 

For example... points as mentioned, signals if you have them but also...

sound on, guards whistle, any other sounds plus sound off at the end.

 

Adding items later can affect timing, try add them in the recorded program from the start. Even if timing is not quite right, add them. This may be part of what you did, you wrote a program, tested and tweaked, then added other items. I know I did this initially and you end up going over and over things trying to get them right.

 

How you are increasing and decreasing speed may also be another factor.

 

PJ

[St1ngr4y]

Hi Ron,

I agree with everything PJ has said, especially the very last sentence "How you are increasing and decreasing speed may also be another factor." After recording a program I replace all of the Forward to [nn] or Reverse to [nn] commands by accelerate and decelerate commands, which I find are much more accurate in being able to stop a train consistently in the same place.

I'm surprised PJ didn't mention Loco Detection is his posts :-)  I believe that LD will improve even more the accuracy of stopping of trains.

Ray

[Yelrow]

Ray, please dont encourage him, he mentions loco detection, in every other post. I think he has entered a 50 word compilation on it in the christmas competition. Does not want the train set as a prize, just a launch date(sorry PJ). john

[Jailor]

Hello Ron

 

When recording your program, try do all the things you need to do in the program, it saves time and adjustment later.

 

For example... points as mentioned, signals if you have them but also...

sound on, guards whistle, any other sounds plus sound off at the end.

 

Adding items later can affect timing, try add them in the recorded program from the start. Even if timing is not quite right, add them. This may be part of what you did, you wrote a program, tested and tweaked, then added other items. I know I did this initially and you end up going over and over things trying to get them right.

 

How you are increasing and decreasing speed may also be another factor.

 

PJ

Thanks both of you willing and eager to learn. Reference setting speed, I did read a few times in the past your sound advise on increasing/deceasing speed and found this to be a lot more accurate. I also started using the record function and again much better. 

I will now try as you have advised completing everything in one go, this is a new idea and makes good sense, will just have to start again LOL but that's the joy  --- I think! 

Out of curiosity, did my comment about track dirt make sense? I understand totally how it must be clean but can't work out if timings are different depending on how Clean the track is when I record and at later date run programme with a cleaner/dirtier track.

Ron.

 

[PJ_model_trains]

Hi Ron,

I agree with everything PJ has said, especially the very last sentence "How you are increasing and decreasing speed may also be another factor." After recording a program I replace all of the Forward to [nn] or Reverse to [nn] commands by accelerate and decelerate commands, which I find are much more accurate in being able to stop a train consistently in the same place.

I'm surprised PJ didn't mention Loco Detection is his posts :-)  I believe that LD will improve even more the accuracy of stopping of trains.

Ray

 

Hello Ray

 

I left you to add the increase and decrease speed as I know what you feel about it. You have probably more experience with programming than anyone on here.

 

I didn't want to mention LD, although I was 'so tempted to'  ;o)  I always mention LD (had you noticed) I am getting worried some one may think it is my real name.  

But you are SO RIGHT Ray, Loco Detection will improve the accuracy (providing the sensors are clean and the strip under the train or carriages don't come off). It will revolutionise the way we drive our trains. Programming is a taster of what is to come but, it is only a tea spoon of taste compared to the cup full LD will give us.

 

You watch Ray, Graskie will be interested now he thinks there is a free cup of tea  ;o)

 

We now plan our  journey, change points, change signals, drive our trains, make a noise (sorry play sounds), with LD we can plan the journey and automate points but, signals will change automatically. We will be engine drivers not signal people. We will be able to run more trains, on more routes, and know (if we set them right) all occupied blocks will change signals automatically and stop other trains from entering those occupied blocks. All we will probably need to do is restart our trains when the signals change.

 

Real engine drivers Ray  ;o)

 

Is LD going to be that good?    NO!

It is going to be Better as we really get to know how to use it.

 

PJ

[PJ_model_trains]

Ray, please dont encourage him, he mentions loco detection, in every other post. I think he has entered a 50 word compilation on it in the christmas competition. Does not want the train set as a prize, just a launch date(sorry PJ). john

 

See what I mean... John thinks Loco Detection is my real name  ;o)

 

Hello John, fancy seeing you here!

 

You keep saying you are not interest in... what's it called...  Oh yes... Loco Detection, but you keep coming alone for the ride. I reckon you will have the starter kit at least in the first twelve months, once you know what it will do, you will want it John. Did I tell you the starter kit will cost less than one loco?

 

PJ

[PJ_model_trains]

Hello Ron

 

When recording your program, try do all the things you need to do in the program, it saves time and adjustment later.

 

For example... points as mentioned, signals if you have them but also...

sound on, guards whistle, any other sounds plus sound off at the end.

 

Adding items later can affect timing, try add them in the recorded program from the start. Even if timing is not quite right, add them. This may be part of what you did, you wrote a program, tested and tweaked, then added other items. I know I did this initially and you end up going over and over things trying to get them right.

 

How you are increasing and decreasing speed may also be another factor.

 

PJ

Thanks both of you willing and eager to learn. Reference setting speed, I did read a few times in the past your sound advise on increasing/deceasing speed and found this to be a lot more accurate. I also started using the record function and again much better. 

I will now try as you have advised completing everything in one go, this is a new idea and makes good sense, will just have to start again LOL but that's the joy  --- I think! 

Out of curiosity, did my comment about track dirt make sense? I understand totally how it must be clean but can't work out if timings are different depending on how Clean the track is when I record and at later date run programme with a cleaner/dirtier track.

Ron.

 

 

Hello Ron

 

When adding messages, add them as low as possible to get under  the yellow boxes. If you don't we sometimes think they are just a repeat of the original message.

 

Regarding acceleration and de-acceleration, all credit must go to our dear friend, he is a 'Ray' of sunshine 

 

We are all learning together Ron, and this forum is brilliant when it comes to getting help. Some very knowledgeable guys on here.

Did we tell you HRMS are pretty good too LOL

 

Keeping the track clean is important and as we plan and install the much awaited, Loco Detection,   Shut up John  ;o)    it will be even more important as the small sensors will be facing upwards out of a railway sleeper.

 

Keep ya muck in ya truck not on ya track!   Saying for today ;o)

 

Good luck with your programming, you will find it easier and although starting again, quicker to do so and the final program more accurate.

 

PJ

[Jailor]

Hello Ron

 

When recording your program, try do all the things you need to do in the program, it saves time and adjustment later.

 

For example... points as mentioned, signals if you have them but also...

sound on, guards whistle, any other sounds plus sound off at the end.

 

Adding items later can affect timing, try add them in the recorded program from the start. Even if timing is not quite right, add them. This may be part of what you did, you wrote a program, tested and tweaked, then added other items. I know I did this initially and you end up going over and over things trying to get them right.

 

How you are increasing and decreasing speed may also be another factor.

 

PJ

Thanks both of you willing and eager to learn. Reference setting speed, I did read a few times in the past your sound advise on increasing/deceasing speed and found this to be a lot more accurate. I also started using the record function and again much better. 

I will now try as you have advised completing everything in one go, this is a new idea and makes good sense, will just have to start again LOL but that's the joy  --- I think! 

Out of curiosity, did my comment about track dirt make sense? I understand totally how it must be clean but can't work out if timings are different depending on how Clean the track is when I record and at later date run programme with a cleaner/dirtier track.

Ron.

 

 

Hello Ron

 

When adding messages, add them as low as possible to get under  the yellow boxes. If you don't we sometimes think they are just a repeat of the original message.

 

Regarding acceleration and de-acceleration, all credit must go to our dear friend, he is a 'Ray' of sunshine 

 

We are all learning together Ron, and this forum is brilliant when it comes to getting help. Some very knowledgeable guys on here.

Did we tell you HRMS are pretty good too LOL

 

Keeping the track clean is important and as we plan and install the much awaited, Loco Detection,   Shut up John  ;o)    it will be even more important as the small sensors will be facing upwards out of a railway sleeper.

 

Keep ya muck in ya truck not on ya track!   Saying for today ;o)

 

Good luck with your programming, you will find it easier and although starting again, quicker to do so and the final program more accurate.

 

PJ

 

 

 

Wrist slapped text lower down.

Think after reading your well hidden, very silent, unmentioned hint about Loco Detection ( oops sorry John) will have to rob a bank and box up set until it arrives LOL

Thanks again guys. Ron.

 

 

 

 

[RDS]

Hi Ron

I totally agree with the method mentioned for creating a program.  I always start off by recording the steps by operating the Loco's manually using my Elite and then modifying the program that has been created, to suit.  The programming feature is extremely powerful and can save a lot of time.

Since the early versions of RailMaster, I have found that the Chain command seems much more reliable and again that is a feature I use regularly.  I just create individual programs and then (in general) just run them from an overall program containing a number of Chain commands.  It is not as easy to determine actual timings using this method but with my layout design, that is not important. 

[PJ_model_trains]

Hi Ron

I totally agree with the method mentioned for creating a program.  I always start off by recording the steps by operating the Loco's manually using my Elite and then modifying the program that has been created, to suit.  The programming feature is extremely powerful and can save a lot of time.

Since the early versions of RailMaster, I have found that the Chain command seems much more reliable and again that is a feature I use regularly.  I just create individual programs and then (in general) just run them from an overall program containing a number of Chain commands.  It is not as easy to determine actual timings using this method but with my layout design, that is not important. 

Hi RDS

Do you find variations in stopping position using the Chain command compared to merging as one program?

Trouble is with merging numerous programs there is quite a lot of tweaking and the program can get very big.

Just interested what you found.

PJ

[RDS]

Hi PJ

Sorry but I cannot comment on stopping positions because my layout has 4 ovals and a number of sidings in the middle.  For the trains on the ovals, it does not matter where they stop or start but with the sidings I have the trains running from one end to the other, running very slowly into buffers and then returning, before running slowly into the other buffer.  I then just have them moving forward away from the buffer a few inches, ready for the next time the program is run.

I cannot bring myself to mention a future upgrade to the RailMaster system that may change all that!

[St1ngr4y]

Hi PJ,

I reported a fault ages ago which has yet to be resolved which involves the accelerate/decelerate commands. The fault became apparent when I started to use the chain command. For example, I have a set of programs which moves a loco from the engine shed to some coaches waiting at the station platform at the other side of the layout. This involved a sequence of four movements as follows:

a) Rotate turntable to the correct road to the engine shed and drive the loco onto the turntable.

b) Rotate the turntable to the exit road to the main layout and drive the loco onto the main line.

c) Reverse the loco around the layout to the station

I created one program for each of these movements, each of which incorporated an accelerate and a decelerate command to start and stop the loco. Each program started at time 0.00. I was able to test each program individually and have the loco stop consistently at the same place. The third program starts with points and signals being changed, and then the accelerate command is actioned at around 15 seconds into this third program.

Then I created a fourth program which consists of a chain command for each of the first three programs, the timing of each chain command being calculated from the elapsed time of the previous program(s). This means that the accelerate command contained in program 3 is no longer being actioned after 15 seconds, but nearer 200 seconds into the fourth program. And this is where the fault becomes apparent. The accelerate/decelerate commands operate at different rates the further into the program they are actioned. This means that the loco finishes nowhere near where it should when the fourth program is run, compared with where it stops when program 3 is run in isolation.

Ray

[PJ_model_trains]

Hello Ray

Have you tried three moves of a train or moving threee trains, each as separate programs, instead of the mixture of turntable and train. I know it shouldn't make any difference but you would not have a mixture of turntable and train movement. If it happened for me I would try rule out the different items and just have commands to move three trains. I always think checking things this way is a second example, at present Hornby only have your one example with turn table and train movement.

PJ

[PJ_model_trains]

Hi PJ

Sorry but I cannot comment on stopping positions because my layout has 4 ovals and a number of sidings in the middle.  For the trains on the ovals, it does not matter where they stop or start but with the sidings I have the trains running from one end to the other, running very slowly into buffers and then returning, before running slowly into the other buffer.  I then just have them moving forward away from the buffer a few inches, ready for the next time the program is run.

I cannot bring myself to mention a future upgrade to the RailMaster system that may change all that!

Hello RDS

 

You have 4 ovals with sidngs in the middle, I have three ovals with sidings in the middle?  Thinking from pprevious discussions and an image I think you put on the forum you have no stations in your ovals, am I correct?

 

I have stations on my ovals so stopping is important and is something I am playing with at present. Just thinking about your ovals, yo would no doubt want to go from one oval to another, if you don't have signals you could have imaginary signals, or even imaginary blocks. You would then need to stop at certain positions. Especially signals or branches off your main line.  If you are thinking LD you must be thinking about your blocks. (No worries I mentioned it)

 

I am going to test 3 programs chained together. The first is the outer loop to stop in a station, before a signal. The second is some shunting and signal changes. The third I am finalising is a DMU coming from a siding in the middle, on to the by-pass loop, stopping at a red signal, the moving to the inner loop and round to a station. Then back again, keeping it reasonably simple at this stage. The first train on the outeer loop is programmed and signals change red as the train passes the signal (moving in the next block) and changes previous signals Y, YY, G as the last carriage passes the first signal. This happens to all signals in turn, 4 times in a loop before it stops at the station signal at the end of that journey.

 

PJ

[PJ_model_trains]

How much easier that would be with LD!

[St1ngr4y]

Hi PJ,

I have created a series of small programs containing not much more than a single decelerate command 60 to 0 mph. Each program obeys the decelerate command at different start times. The loco involved doesn't even exist. It is simply a case of watching the speed and when it reaches 0 make a note of the elapsed time. The default accelerate/decelerate rate is, as near as makes no difference, 1 mph per second, so the loco should reach 0 mph at around 60 seconds. It does do this if the decelerate command starts at, say, 10 seconds into the program. But if I change it so that the decelerate command starts at, say, 70 seconds, the loco doesn't reach 0 mph until about 65 seconds of deceleration. This extra 5 seconds equates to quite a distance away from the intended stopping point.

Ray

[PJ_model_trains]

Hi PJ,

I have created a series of small programs containing not much more than a single decelerate command 60 to 0 mph. Each program obeys the decelerate command at different start times. The loco involved doesn't even exist. It is simply a case of watching the speed and when it reaches 0 make a note of the elapsed time. The default accelerate/decelerate rate is, as near as makes no difference, 1 mph per second, so the loco should reach 0 mph at around 60 seconds. It does do this if the decelerate command starts at, say, 10 seconds into the program. But if I change it so that the decelerate command starts at, say, 70 seconds, the loco doesn't reach 0 mph until about 65 seconds of deceleration. This extra 5 seconds equates to quite a distance away from the intended stopping point.

Ray

Hello Ray

 

Have you tried acceleration 0-60 as well as deacceleration 60-0 to see if there is a difference?

 

5 scale seconds is a lot, a train could kill a lot of model track workmen or even pass a branch and have a major accident that would hit the national news on TV. That would be terrible!  Imagine.... New Flash... Hornby train fails to stop and runs into a Virgin.

 

I have to use those words again Ray, Loco Detection would prevent this but, it would be STOP at the requested position.

 

I have earlier today put another post in a thread regarding LD, which we cannot get away from. It is one we have discussed before Ray, what will happen to a train, running in  a program to a time scale in a program when it has to stop at a Red signal? Is time held in the program until a signal changes and we restart the train, or will timing continue in the program and every ending up a total mess?  The other consideration is will we use programs as much? I think we will use programs and chain them as these seem so important in HRMS initial programming, so how are they getting round this issue? It would be nice to know, is time frozen in the program if a train stops at a red signal or not. But then I see another concern, what if the train is running to 'real time' not 'program time'?

 

PJ

[St1ngr4y]

Hi PJ,

I had a thought about LD recently, but I then quickly dismissed it....

Wouldn't it be good if, while waiting for the LD hardware, they were to provide a facility in RM for us to try things out. What I was thinking was perhaps the ability to click on a sensor icon on your track diagram, which you click when a traim passed the spot on your actual layout where you intend to place the sensor. 

I dismissed the idea because I think it would be too complicated a piece of code to insert into RM. The user would have to provide other information such as the loco id, its speed and direction, before clicking the icon.

:-)

Ray

[PJ_model_trains]

Good thought Ray but, I have to agree, I think they would dismiss it.

 

The request is not what the sotware will do so may cause other problems.

 

I have managed to simulate it in a program, running a train and carriages through 5 blocks, each signal changing red as a train passes it and 'every signal' prior to the initial one changing to Y, YY and G as the carriages pass. 

 

It is strange at first, seeing signals on my left changing, when a train is on the other side of the layout but, easy to adapt as the mind knows what is happening. It is also strange at first seeing ovals of track on the RM screen and watching signals change in seqence based on the trains position. You see more on the screen as you see all signals, on the layout some have their back to us subject to the direction of travel.

 

PJ

[PJ_model_trains]

Hello Ray

 

Just thinking a little more about Loco Detection and train speeds, I think there will be quite a bit of tweaking to do but, slowing down and stopping, I think, will be so important.

 

e.g. You start a train and accelerate until it gets to 60mph, having reached 60mph, it may be alright if all signals are green but, one changes to yellow which means we may have to stop at the next signal. A sensor should say either, do x speed, or deaccelerate to x speed. But the latter may not slow it down enough before the stop signal.

 

The next consideration may be only run at 50mph, and when a yellow signal shows you may just about stop in time if the next signal is red. So although we would love to use accelerate and deaccelerate for a nice gradual flow we may have to say reduce to x speed. This may be for example, deaccelerate at this signal but then the one before the station set to speed 15 or 20mph. So that at the other end of the station, if the signal is red the sensor stops the train or if changed to yellow or green gives a command to continue and start to increase speed again, Real engine driving ;-)

 

I like the accelerate and deaccelerate for smooth flow between speeds but do wonder if it will work as well in LD. This is where we are trying to play a game but don't really have the dice to do so.

It is exciting to consider what we can do but Frustrating because we can't do so or do not have enough information.

 

What do you think?  Not about the waiting or frustrations (before we get a flood of comments for those) but the actual workings as shared for discussion above.

 

PJ

[Fishmanoz]

Great idea Ray, and not so sure it is silly or hard. You would need to setup your virtual detectors with their ID numbers on your layout, even though they aren't there. Then you would need to put your LD tags into your loco setups, even though they aren't there either.   Now your layout is fully virtually LD equipped. 

 

Now surely all all you need is the ability to make a short program saying tag ID No detected at detector ID No and you are virtually up and running. 

 

What do you think HRMS?

[PJ_model_trains]

Great idea Ray, and not so sure it is silly or hard. You would need to setup your virtual detectors with their ID numbers on your layout, even though they aren't there. Then you would need to put your LD tags into your loco setups, even though they aren't there either.   Now your layout is fully virtually LD equipped. 

 

Now surely all all you need is the ability to make a short program saying tag ID No detected at detector ID No and you are virtually up and running. 

 

What do you think HRMS?

 

Hi fishy

 

It was the last bit that bothered me as to it working. I agree a click could act as a sensor pass. What concerned me was how they or we would define the click as either train A B C or D for example and how another click would know it was the last carriage on which train

 

PJ

[St1ngr4y]

Great idea Ray, and not so sure it is silly or hard. You would need to setup your virtual detectors with their ID numbers on your layout, even though they aren't there. Then you would need to put your LD tags into your loco setups, even though they aren't there either.   Now your layout is fully virtually LD equipped. 

 

Now surely all all you need is the ability to make a short program saying tag ID No detected at detector ID No and you are virtually up and running. 

 

What do you think HRMS?

I suppose it could be used by users who need to understand how LD will integrate into the existing system. It may help them decide whether to buy into it or not :-)

Ray