'Time' Command question
- Thread starter jay4708
- Start date
Thanks Hippy,
If I have a bit of simple code such as:
let w0 = time + 10
if time > w0 then
' Do something
What would happen if the above bit of code came into play when the time was at 65525, 10 would be added to it to make w0 65535 but then when time rolls over to 0, time would then be less than w0 and my code would not be true!!!
John
If I have a bit of simple code such as:
let w0 = time + 10
if time > w0 then
' Do something
What would happen if the above bit of code came into play when the time was at 65525, 10 would be added to it to make w0 65535 but then when time rolls over to 0, time would then be less than w0 and my code would not be true!!!
John
John,
You can get this code to work if you change to checking the elapsed time since you last did it instead of calculating ahead of time the next time you need to do it.
With the picaxe integer math the result "wraps around" at 65536
So for addition this means that 65535 + 1 = 0, 65535 + 2 = 1, etc
and for subtraction it means that 0 - 65535 = 1, 1 - 65535 = 2, etc
For example,if the last time we ran was at 65525 then:
- At time = 65535 the elapsed time would be 10
- One second later the time = 0 (because we have wrapped around) and the elapsed time would calculate as 11 because 0 - 65525 = 11
- One second later the time = 1 and the elapsed time would calculate as 12 because 1 - 65525 = 12
This only works so long as your elapsed time is less than 65536 of course. You can't let the timer wrap around once between doing something.
e.g if the last run time was 55 then you need to do something before the timer gets back around to 55 again.
- time=54 - last run time=55 equals an elapsed time of 65535 and the code works
- time=55 - last run time=55 equals an elapsed time of 0 and the code doesn't work.
Code:
symbol ElapsedTime=w0
symbol LastTime=w1
' do it the first time
LastTime = Time ' Record the time we did it
...
' some time later on
ElapsedTime = Time - LastTime
if ElapsedTime >= 10 then
LastTime = Time ' update the time we did it
' Do something
Last edited:
It's worth remembering that TIME on the M2 is not a 'command' as such, it is just another variable - albeit with the magical property of incrementing each second.
Your program can set it to zero, later check to see when it becomes > N ..... then set it to zero again. No overflow to worry about.
Your program can set it to zero, later check to see when it becomes > N ..... then set it to zero again. No overflow to worry about.
I do not think that it is a good idea if accuracy is concerned : when the time variable is reset to zero, remaining fractions of second are also reseted (and you cannot know how many are lost). So it is not possible to keep the time variable accuracy.
Jay4708 code can deal with more that one timer... In that case, reseting Time will not work...
Clever...
Making an appointment is the only way to deal with pause and delay when writing a collaborative multitasking program. In that case, if main loop can last more than one second, the "elapsed time" idea is the soluce !
Last edited:
In order to use TIME for a delay, the time variable must be polled. How often it is polled will determine the accuracy of the delay. Best "accuracy" will be obtained if it is polled in a very tight loop. Given the processor overhead of the loop, it still will not be very accurate. So I don't get the concern with "accuracy", especially since we do not know the accuracy requirement of the OP's application
Clearing the time variable to zero and starting over is simple and likely to work just fine.
If extreme accuracy is required I don't think polling the Time variable is the way to go, no matter how "clever" the code is.
Clearing the time variable to zero and starting over is simple and likely to work just fine.
If extreme accuracy is required I don't think polling the Time variable is the way to go, no matter how "clever" the code is.
Jeremy Harris
Senior Member
There's also the slight problem that a few instructions delay the time variable incrementing, causing inaccuracy. I found this out when receiving serial data, in that time stops incrementing for the duration of the serin blocking instruction. I'd assume that any other blocking instruction would similarly stop time incrementing.
inglewoodpete
Senior Member
I have been pleasantly surprised with the accuracy of the internal timer in an 08M2 in a recent project. With the PICAXE running at 32MHz ('Time' ticks twice per second), I was resetting the Time variable every 10 ticks or 5 seconds.
The timer was within +/- 4 minutes per day or less than +/- 0.3% (a day is 1440 minutes long). I used an LDR to determine sunset each day, recording then resetting the minute count (in internal EEPROM) at sunset.
That's about the same accuracy that I have seen. A .3 percent error means a 30ms error in 10 seconds. Not clock accuracy, but should be good enough for many simple applications requiring a 10 second delay.
Accuracy is relative. If the OP is looking for sub millisecond accuracy with a 10 seconds delay, another method will be required.
lbenson
Senior Member
Using "time" variable on M2 parts to implement muliple timers
My preference in using the "time" variable is to wrap it every half day, after 43200 seconds (60 seconds times 60 minutes times 12 hours), and use a bit variable as an am/pm indicator (understanding that you don't have real-world accuracy).
When you decide that an action must occur in the future, you set a word variable to "time" plus how many seconds in the future you want the action to be taken. When "time" is greater than that variable, you perform the action. If "time" becomes > 43199, you adjust the variables and reset "time" to 0.
so as a structure for timing two actions:
This assumes that the main loop cycles without being blocked--several times a second or at least often enough that you don't encounter timing problems. Also, your "time + n" is never going to overflow (be > 65535).
My preference in using the "time" variable is to wrap it every half day, after 43200 seconds (60 seconds times 60 minutes times 12 hours), and use a bit variable as an am/pm indicator (understanding that you don't have real-world accuracy).
When you decide that an action must occur in the future, you set a word variable to "time" plus how many seconds in the future you want the action to be taken. When "time" is greater than that variable, you perform the action. If "time" becomes > 43199, you adjust the variables and reset "time" to 0.
so as a structure for timing two actions:
Code:
#picaxe 14M2 ' or other M2 picaxe
symbol wEventTime1 = s_w1 ' 0 when off, otherwise number > 'time'
symbol wEventTime2 = s_w2 ' 0 when off
symbol bAMPM = bit0
main:
do
if time > 43199 then
if wEventTime1 > 43199 then
wEventTime1 = wEventTime1 - 43199 min 1 ' don't allow 0--OFF indicator
endif
if wEventTime2 > 43199 then
wEventTime2 = wEventTime2 - 43199 min 1 ' don't allow 0--OFF indicator
endif
endif
time = 0
if bAMPM = 0 then : bAMPM = 1 : else bAMPM = 0 : endif ' toggle bit
' your code testing to see if timer has expired
if wEventTime1 > 0 and timer > wEventTime1 then
' do something
wEventTime1 = 0 ' reset event timer
endif
if wEventTime2 > 0 and timer > wEventTime2 then
' do something
wEventTime2 = 0 ' reset event timer
endif
' your code determining that something should be done later
if [someevent] then
wEventTime1 = 60 * 2 + time ' do something in 2 minutes
endif
if [anotherevent] then
wEventTime2 = 60 * 60 + time ' do something in an hour
endif
' the rest of your code
loop
Last edited:
Hi,
However, the time is never going to be particularly accurate, perhaps within 0.1% at the very best (a few seconds an hour) but certain instructions can block the interrupts and make the time accuracy almost useless (50% or more slow).
Cheers, Alan.
No, that is not correct for the time variable in M2 devices. Resetting "time" does NOT reset the (20ms interrupt-driven) pre-scaler.
However, the time is never going to be particularly accurate, perhaps within 0.1% at the very best (a few seconds an hour) but certain instructions can block the interrupts and make the time accuracy almost useless (50% or more slow).
Cheers, Alan.
Jeremy Leach
Senior Member
Fantastic - I'd thought of this trick a while ago but never got round to trying it. This was my graph of Lux which made me think it was a sharp enough cut-off to be a way of resetting a timer.
Last edited:
YES it is :
If real time is 123.980 s
reseting Time will lost the 980 ms elapsed even if pre-scaler is not stopped.
If often use more than one apointment : how do you do that ?
Flenser #5 seems to me more simple.
Hi,
"... when re-enabling the time variable incrementing function with enabletime (after a disabletime command has previously been used) the first tick could happen any time during that initial one second time period. When the time function is disabled the time variable may be altered safely with a command such as 'let time = 0'. - See more at: http://www.picaxe.com/BASIC-Commands/Time-Delays/time/#sthash.XmvlTy6K.dpuf".
Therefore, resetting "time" after a minute, hour, or half-day is often the easiest way to use the variable in simple programs.
Cheers, Alan.
The "prescaler" is a pure software counter (not accessible to the user) which counts 50 x (20ms) interrupts and then increments the "time" variable. So if it is currently 49 (980+ ms) then "time" will (still) increment on the next interrupt, whatever you do with the (1 second) time value. From the description of the time variable:
"... when re-enabling the time variable incrementing function with enabletime (after a disabletime command has previously been used) the first tick could happen any time during that initial one second time period. When the time function is disabled the time variable may be altered safely with a command such as 'let time = 0'. - See more at: http://www.picaxe.com/BASIC-Commands/Time-Delays/time/#sthash.XmvlTy6K.dpuf".
Therefore, resetting "time" after a minute, hour, or half-day is often the easiest way to use the variable in simple programs.
Cheers, Alan.