I'm confused about how the logger deals with this code in a CR800, OS Std.21:
beginprog
Scan (1,Sec,0,0)
WaitDigTrig (4 ,0)
call beep
call doOtherStuff
endscan
endprog
Control port 4 is a momentary pushbutton, and the beep subroutine can be triggered several times per second. I thought the scan() statement would block until the next top-of-second, but apparently not.
I assume that the program is running in sequential mode, but it is not declared to be. Could it perhaps be running in pipeline mode? Would that explain why we can go through the 1-second scan loop faster than once per second?
The WaitDigTrig instruction is used to trigger measurement scans from an external digital input to one of the datalogger's control ports. When the control port is in the state specified by the Option parameter, the scan takes place.
So, the scan is no longer being driven by an internal time based trigger. Instead it is being driven by the external interrupt.
Try the following instead:
BeginProg
Do
WaitDigTrig (4,0)
call beep
call doOtherStuff
Delay (1,1000,mSec)
Loop
EndProg
After some checking I can confirm that is the way it is supposed to work. The Waitdigtrig effectively controls the scan rate, whilst the Scan/Nextscan only affects the timestamps used when storing data - this is explained in the CRBasic help.
Therefore with your push button a scan will be executed everytime you push the button (maybe more with switch bounce). Because the push buttons are not going to be occuring at 1 sec intervals you could expect the timestamps on the data to be completely wrong (see the help).
If this is all you want to do and need good timestamps I suggest removing the scan/next scan and just using a loop structure. This should cause the correct timestamps to be stored in any datatable, albeit using slightly more memory (for the storage of a full time value).
Update - the loop structure being as shown by Sam - our postings coincided!
* Last updated by: aps on 4/12/2012 @ 8:51 AM *
Thank you; that makes sense, I think. Extra memory use storing full timestamps shouldn't be a problem, and the loop structure is much simpler to understand. I'll have to study the crbasic help to better understand the scan statement or block behavior. Thanks for the pointers!
My simplified program example omitted the data tables we're actually using, and with those in place the do-loop fails to allocate memory for the tables. I assume that's probably because it cannot calculate the table sizes. Can we expect it to work if we set the table size explicitly in the DataTable statement? E.g., we currently have:
DataTable(OperatorView, 1, -1)
but would change that to something like:
DataTable(OperatorView, 1, 15000)
My understanding is that the memory will be allocated the first time the program compiled, but then not again unless something changed (e.g., a table size), regardless of the logger being turned on and off. Is that correct?
Having waitDigTrig() in a scan loop definitely does weird things. I had been using a 1 second scan, but others with a similar system used 10 seconds; my guess is that weird things are still happening, just 10 times slower.
Thanks!