Rollover on Msec function

Ewon Support Ewon Flexy
#1

I added the following code in my cyclic section on one of my flexy 205’s:
// Check the scan time of the cyclic section
LatestMsec% = GetSys Prg, “Msec”
ClockSec@ = LatestMsec% / 1000
If(LatestMsec% < PrevMsec%) Then
// Rollover Occured
LastScanSec@ = ((134217728 - PrevMsec%) + LatestMsec%) / 1000
RolloverApprox@ = PrevMsec% / 1000 // Rollover just after value in “PrevMsec%” so check that value
Else
LastScanSec@ = (LatestMsec% - PrevMsec%) / 1000
Endif
PrevMsec% = LatestMsec%
If(LastScanSec@ > MaxScanSec@) Then MaxScanSec@ = LastScanSec@
//

However, it appears the spec for rollover at 134,217,727 milliseconds does not occur ?
Has there been a change to the this spec (taken from RG-0006-01 manual, page 50)

Send email at startup?
#2

Hi Tom,

What value are you seeing it roll over at? Does it happen to be 268,435,455Msec?
May I ask what is the purpose of this experiment?

Deryck

#4

I have yet to see it roll over.

#5
#6

I am thinking the manual is wrong. 134,217,727 would only be about a day and a half and we keep the up time for longer then this. I will see if I can get more info regarding this value.

What are you looking to accomplish by looking at this value I might be able to suggest another option.

Deryck

#7

Rollover, if not detected and dealt with, would mess up my use of
the result of the Msec return value. I plan to use the
differential values from calls to Msec at each scan for the most
accurate calculations I can get on pulse to pulse time from a
digital input. Normally this is easy, but if two input pulses land
on opposite sides of rollover, I want to know and “fix” the result
as I am doing in the code snippet I sent to you.

#8
#9

We are looking into when this will roll over, in the mean time though we can try to calculate it with this script.

Tset 1,1
ONTIMER 1, “GOTO test”
test:
Now% = GetSys Prg, “Msec”
If Now% > LatestMsec% THEN
LatestMsec% = Now%
print LatestMsec%
ENDIF

Also careful the Di could be read at max 10hz only, means 100ms.

With your method I we are not sure that would be accurate as the script doesn’t have a fixed cycle time.

Deryck

#10

The timers are likely not as accurate as this “millisecond” counter - it
says as much in literature I have read regarding the timers. A timer has
a minimum resolution of 1 second, but I can use these results to get
resolution usually much better than that. I can initialize a variable at
any point in my program, then come along and check it at will, then
react when it reaches or exceeds my setpoint.

The rollover has to occur at some point in time.

The snippet I sent is just a way to do two things:

  1. To test for and correct for rollover.
  2. To be the basis for code (to be added) that accrues the elapsed time
    of each subsequent pass. This way, the actual time of each pass becomes
    almost unimportant, but as each pass is accrued, I get an update as to
    how much time has passed since I have initialized my time counter.
#11

Thanks for the warning on the Di input response time, I am aware of
that. I will not be exceeding 5 per second.

The whole point of the code is to avoid the need for accurate repetition
rate of execution of this routine. The snippet might accrue 500
repetitions in one second; the more the better.
However sometimes, like if the flexy is servicing an SMS request, it
might execute once in 2 seconds, that’s OK. Other code elsewhere will be
looking at the accrued value of subsequent cycles as the scans add up.
That is where the total time is important. This allows me to resolve
elapsed time of some event much better than a timer can. Besides there
are only a few timers.

Thanks for backing me up on all this.

#12

Regarding rollover, I have made my tag for capture of the rollover value
as a non-volatile tag, and when it finally decides to roll over it will
get stored to within the last cycle. close enough for me.