Export to Excel.
;D
----- Original Message -----
From: John Whitton
To: Model 100 Discussion
Sent: Saturday, April 02, 2016 1:24 AM
Subject: Re: [M100] BASIC interval timing
1. No interval will exceed 24 hours.
2. One-second resolution is adequate.
To be a little more explicit, the object is to record the time of "ON"/"OFF"
events and their duration occurring over the course of several days with
several events occurring each day. The real-time sequence will be:
"ON" - Record current time
"OFF" - Record current time and elapsed time since previous "ON"
"ON" Record current time and elapsed time since last "OFF"
.
.
.
etc.
The only real issue is the conversion of the character-stringed TIME$ to
usable numbers, and dealing with the crossing from 23:59:59 to 00:00:00
John W.
----- Original Message -----
From: David Boyd
To: Model 100 Discussion
Sent: Friday, April 01, 2016 11:06 PM
Subject: Re: [M100] BASIC interval timing
Well, he wants to subtract one time value from another. Presumably we'd
want to serialize both times, store them in a double, dblTime = (if HH=0 then
HH=24) HH*3600+MM*60,+SS, do the subtraction, then build another time string to
display. Lots of expensive string ops, VAL()s... surely peeks would be quicker,
if messier, though I suppose the different models might put the time in
different memory locations...
On Fri, Apr 1, 2016 at 22:58 David Boyd <[email protected]> wrote:
Well
On Fri, Apr 1, 2016 at 22:52 Kenneth Pettit <[email protected]> wrote:
The other question is if 1 second is fine enough resolution.
Presumably it is if string time is adequate.
And yes, the current clock values are maintained in RAM somewhere. The
question becomes the time for a single string = operation vs. multiple RAM
address reads from BASIC.
Ken
Sent from my iPhone
On Apr 1, 2016, at 7:13 PM, David Boyd <[email protected]> wrote:
Clarify some things please:
What is the max interval?
Is the max interval longer than 24 hours? If so, we need date also.
Do you want shortest, or fastest, or best compromise?
Questions for the more experienced among us:
Is there some memory location where the system time is available as a
number? If so, we would prefer that. Even a tick count would be handy.
On Fri, Apr 1, 2016 at 21:59 John Whitton <[email protected]>
wrote:
I suppose I could lamely offer this as a challenge, but the fact is
that I am just lazy, and am wondering how others would go about it.
The issue is the shortest code that will collect (as a character
string, H:M:S) the difference between two clock readings, in hours, minutes and
seconds. The crux of the matter is the capture of interval between randomly
occurring events.
Assume
A$=TIME$ 'First event
B$=TIME$ 'Second event