granularity/rounding of program times

[idlemarvel]

The RM guide implies that program time are accurate to 1/10th of a second. In the program window they are displayed in 100/ths of a second. However my trials imply that at run time the times are rounded to the nearest second. I wrote a program like this:

0 message[text,5]

5 forward to 3

10 forward to 30

25 forward to 3

30 stop

The loco stopped at the same place every time within +/- 0.5 inches. So far so good. Call this stopping place position A.

I wanted it to stop a little earlier so I changed 25 to 24. It stopped earlier in the track, consistently, call this postion B. This was a bit too far back, so I tried 24.5. Stopped at position B, same as for 24.0. Same for 24.1, 24.2, 24.3, 24.4, 24.5, 24.6, 24.7, 24.8, 24.9 and every other 24.something except 24.99, which stopped at position A.

It seems like some curious rounding and/or truncation is going on, the result of which is that effectively only whole seconds are used. This is kind of confirmed in the logs which only shows whole seconds (with decimal points .00). Is this the way it works or is it just me?

I haven't reported it through the online help yet, I wanted some feedback from others first.

[St1ngr4y]

What happens if you adjust the Stop command also e.g. 

24.5 Forward to 3

29.5 Stop

I still say the decelerate command would be more accurate. :-)

Ray

[idlemarvel]

Thanks, Ray, I know you have a penchant for accellerate/decelerate, (:-))  and thanks for suggesting a workaround, which I will try tonight, but I don't think it alters the conclusions from my testing, does it?

[Augustus Caesar]

Unless programmed otherwise the software or code hard-coded into the chips will only use rounded numbers and will ignore decimal places. If you use, say, 23.5 as a starting sum in a calcluation and take another figure with a fraction the software will look at both and round the two so it gives a mean number to work with.

I admit I haven't looked into this with RM at all but simple computing and logic tells me that this is how the program works... with whole or mean numbers and ignores fractions unless a calculation is done between two but the difference would be the number to round up or down which is then passed to the unit for operaton.

This is a curiosity I may end up playing with when testing very shortly... I would be surprised if numbers were dealt with in fractions especially if a database is used to store your submitted data.

[MetmanUK]

Is this something you know for sure AC ?  As someone who has spent more than my working life writing code/programs using databases I find it very surprising.

[idlemarvel]

I know that ulitmately everything comes down to ones and zeros, but AFAIK programs have been able to manipulate and databases have been able to store real numbers not just integers for decades, so I don't think that is the issue.

But at the moment I am more interested in whether this is something others have noticed or can replicate.

[St1ngr4y]

I completely agree with MetmanUK. When you record a program 'macro' through RM, more than half of the instructions will have times expressed as integer+tenths of a second. I can't believe any rounding to integers takes place. Also the accelerate/decelerate commands by default adjust the speed by 1 speed step per second, but they have an extra optional parameter which can be used to fine tune the rate which is expressed as n.nn e.g. 0.75 would cause the speed to be altered at 1 speed step per 0.75 of second.

Ray

[idlemarvel]

I've done some more experimentation, and found that RM does respond to intervals of 1/10 second and does not round or truncate (except in the log entries).  There must have been some funny combination of decoder, speed curves, program and loco which caused the first set of results.  Topic closed!  :-)