Problems with TimeSecond()

[Zenerdiode]

Hello,

Still using Basic4PPC to write some desktop applications. My problem with this one; is I am creating a log file for feeding into a commercial app. The file format is a new log file created every hour (or part thereof) with sequential number, a small header, minute markers and five second markers. The file will get filled with other events as they occur - not to be worried about now.

So, I have a 5000ms timer control, but we all know the number of Ticks is at the whim of the OS and my calibration code does a good job of keeping the 5 second timer within a couple of hundredths of a second, well within the accuracy I need.

My problem is if the timer ticks too early when it is on a whole minute; say 09:59:59.98 seconds. It was then not placing a minute marker as the If statement 'If TimeSecond(T)=0' would return False. As a crude workaround, I preceded it with 'If TimeSecond(T)=59 Then T=T+cTicksPerSecond' so it would hopefully resolve that it was at a minute and place the minute marker.

Sometimes it still fails to place the minute marker. I have included some code to dump what the ticks value was at the time it failed; and each time the Timer ticked just before the minute as above.

Please let the code run for a few hours and you'll (hopefully) see a couple of files that have 23 five-second markers between minute markers - instead of 11. The debug file will show the tick value that was used at the time.

Is it because I'm using the wrong variable type for T? Please change the file extension from .txt to .sbp.

 

[agraham]

I’m afraid that I haven’t the patience to try out your code but assuming that your assertion that the calibration is accurate over time I would change the detection of the minute point to one that cannot fail as I am a bit suspicious of trying to hit a small window of time with a large interval.

I would still look at the TimeMinute value but I would keep a record of the last minute value written to the file and change the test to compare the present TimeMinute value to the last minute value written to the file, and if different use that detection as a new minute marker. This assumes that your recalibration is keeping the 5 second timer to the long term accuracy that you require.

For debugging to check this is working I would save the actual value of system time at the minute marker and the difference from the ideal to see what variance I was getting in practice.

 

[agraham]

Oops! Didn't think the above through thoroughly enough . For it to work would need to keep your own count of minutes and use that instead of TimeMinute. So you would write a minute marker every 12 timer ticks and assume that your timer recalibration was keeping each twelfth tick close enough to the actual minute. You would need an initial synchronisation of your minute to the system minute which you could do with a short interval timer or even a loop.

 

[Zenerdiode]

Hi Andrew,

Very good indeed to hear from you again - I hope you're well. I added a little bit more debug code and I find that when the time ticks early; say 21:59:59.99 sometimes (and only sometimes) when I add 1*cTicksPerSecond to that Ticks value, TimeSecond() goes from 59 to 1! It must be occasionally rounding the Ticks value somehow. Anyway, my calibration code keeps the Timer ticking within five seconds ± 0.02 seconds, so instead of adding 1 * cTicksPerSecond I add cTicksPerSecond/2. On the XP Embedded system that this is running on, I would get, say, 6 instances per 24 hour period, now I get none. Thanks very much for your help.

Christopher

 

[agraham]

Aging but fit(tish)

Ah! I get it now. The reason for the rounding is that Basic4ppc does all numeric operations as Double operations, even ones that are apparently integers. Most of the time you get the expected results as a Double can represent most integers exactly. However in this case there is a division by 60 to get the minutes value and I guess that some values that should be 0.99999999xxx cannot be accurately represented by a Double and instead result in 1.000000xxx causing the problem.

I too am still using Basic4ppc for desktop development, although it is my own version that only produces desktop applications, so it still lives on with at least two of us.