I'm implementing a CRBasic script for a CR850 datalogger connected to a TDR100.
The idea is to collect TDR data every 2 hours and send them via FTP to a server.
In other contexts, i prepared FTP files through TableFile and DataInterval.
In those cases, I had a scan (e.g. every 60 seconds) that ended with a CallTable, and something like this in the table definition:
TableFile ("CPU:data", 13, 1, 0, 5, Min, data_flag_15m, last_filename_15m)
DataInterval (0, 15, Min, 3)
Minimum (1, VBatt, FP2, FALSE, FALSE)
to get the minimum VBatt every 15 minutes: this leads to a new file every 15 minute, the OutStat flag (in my case data_flag_15m) becomes -1 on next scan and everything goes fine.
If I take https://s.campbellsci.com/documents/au/manuals/tdr100.pdf example (page B-2), I can't find a way to make the same principle work.
What I want to achieve is that every time code block executed when Flag(2)=High is terminated, TableFile is written and OutStat flag is -1.
When your program is compiled in the datalogger (or CRBasic Editor), if the compile results indicate that the program compiled in PipelineMode, what you may be seeing is an issue of timing. In PipelineMode, the datalogger has multiple tasks running -- a task sequencer for handling the measurements and a task sequencer for handling the processing. Because multiple tasks in the program are being carried out at once rather than sequentially, this can lead to a variable such as a flag getting set back to a different state that is not timed correctly for the rest of your program.
Also note that the change to the Outstat variable lags by one scan interval. This information is from the help: "The value of the OutStat variable can be monitored to determine when a new file has been written, and thus control the transfer of the file via email or FTP. If this functionality is used, the value should be checked after the CallTable instruction that refers to the data table containing the TableFile instruction. Because the file write operation is executed by a separate task within the datalogger, the OutStat and LastFileName variables will not be updated until the next execution of the EndTable instruction after the scan in which the file was written. This results in a one-scan lag of when the file is written and the variables are updated. The effect of this lag can be lessened with a faster scan rate. Note, however, that if the table is called rapidly (for example, 1 second interval), when viewing the variable on a numeric display, you may never see the value update to -1."
One solution, if the program is running in PipelineMode, is to force the program to run in SequentialMode (there is an instruction to do this), but this will likely increase your minimium scan rate. That may not, however, be a problem in a TDR application.
I hope this gives you some ideas on how you may be able to improve your program.
thank you for your help!
In the end, I decided to write the TDR data to a file with some custom CRBasic code rather than through a table.
I wish I tought about this since the beginning, it has been extremely easy.
Have a nice day,