Can the For To Step Next structure serve as a timer? Does the program scan rate control the speed with which the program moves through this structure? Does it operate separately from the rest of the program?
Well, the title should be Timers in CR9000X programming.
Most code in a CRBasic program is processed "as fast as the datalogger can go". This is also true of a For-Next loop.
If you want to control the timing of something inside of a Scan, use the Delay instruction instead of using a For-Next loop (whose purpose is only to perform unneeded processing in order to create a time delay). While it is theoretically possible to create a delay with a For loop, I think you will find that you won't get the kind of control you expect.
It is possible to run a For-Next loop outside of a Scan.
That is a very advanced technique, since you don't get the
benefits that are commonly desired from using a Scan loop (i.e. timestamps and other timing/clock related features).
Outside of a scan, the For-Next loop becomes sort of a replacement for the Scan loop. However, what you will find is that each iteration of the loop may not take the exact same length of time in each iteration. Since the logger goes as fast as it can, and other activities may get involved (like communications or storage), you don't get the kind of control over timing that you might expect.
I find it helpful to review the Scan instruction with CRBasic programmers from time to time. What a Scan really does is to execute the code (between Scan and NextScan) as fast as the datalogger can get it done, and then it waits for the datalogger clock to tell it to start the scan again. For slow scan rates (such as 15 minutes or 1 hour) this operation is apparent -- the datalogger can usually get done what it needs to do within its scan in a minute or two, and then it just waits for the next 15 minute interval or 1 hour interval etc. So the datalogger may sit inactive for 12 or 13 minutes out of every 15 minute scan. That is a great thing when power consumption needs to be minimized.
With faster scan rates (and faster dataloggers like the CR9000X) the scan works the same way. If you have a 20 millisecond scan, the datalogger is trying to do everything you told it to do between Scan/NextScan in something like 18 milliseconds or less (the system does require a bit of overhead). I usually tell people that they should not schedule work within a scan that takes up more than 60% or 70% of the scan interval -- just to leave some headroom. There are metrics in the Status table that tell you how much of the scan you are using up. And if you try to do more work inside of a scan than can be done in that time frame, your program will develop skipped scans. The datalogger will stop whatever it is doing within a scan (when the time is up) and start at the beginning of the scan again (and increment the Skipped scan counter in the
status table).
The bottom line is that the Scan instruction is designed to give you control of timing in the datalogger. Finer grained control (internal to scan) of timing is harder to obtain. You basically tell the logger what you want it to do and how often, and then let it go.
SequentialMode vs. PipelineMode muddies the water a bit on timing. In Pipeline mode the datalogger may be slicing in multiple activities at the same time. That is why the Delay instruction gives you options to delay "Measurement tasks" or "Processing" or "Digital readings"
Any discussion about controlling timing within a Scan has to consider Measurements, Processing and Digital readings. It isn't an "exact science".
My recommendation is that you explore the use of the Delay instruction. If you are trying to accomplish something where the Delay instruction doesn't help,it would be nice to know more about your program and what work you are trying to accomplish in your For-next loop.
The quickest path to resolution may be to contact your Campbell Support rep/AE since this is a pretty advanced topic.
Thank you for the comments, my program performs the measurements and processes properly now. The present problem is that the processes happen 8 minutes after the hour and the portset instruction should activate at the top of the hour. The signal to the satellite datalogger presently runs for an hour, turns off for 1 minute, then turns on for 1 minute, then finally turns off. Not sure why, but will try the delay unstruction to delay processing by amount of time in the MeasureTime field of the Status Table (?).
The planned delay in my last post would mean total execution time <40% of scan interval.
As mentioned before, I think it is time to call your local Campbell support folks. We aren't going to see what is really happening without having a look at the program.
The TimeIntoInterval instruction may help, but I can't
understand the behavior with only a general description.
Possibly this is an effect of processing operations for the scan operations being pipeline mode buffered behind the measurements and port set operations. What is the scan interval and what is the number of scans to buffer set at in your program?