Our full technical support staff does not monitor this forum. If you need assistance from a member of our staff, please submit your question from the Ask a Question page.


Log in or register to post/reply in the forum.

TableFile: OutStat and LastFileName are delayed


Monte Jun 8, 2010 02:17 PM

Hello
I'm using the TableFile instruction to create datafiles. Basically it works, but I've one problem: The OutStat and LastFileName variables are not updated immediately when it creates a new file.
For example:
TableFile Interval=0, NumRecs=3
Scan Interval=1
Every third record a new file is created. Rec3=File1, Rec6=File2, Rec9=File3 and so on. But OutStat and LastFileName don't change after Rec3, 6, or 9. They are updated upon the next scan, e.g. on Rec4, Rec7 and so on.
I'm using a CR1000 with os19.

'CR1000 Series Datalogger
Public PTemp, batt
Public OutStat As Boolean
Public LastFileName As String * 25
DataTable (ABC,1,-1)
TableFile ("USR:ABC",12,1,3,0,Min,OutStat,LastFileName)
Sample (1,PTemp,FP2)
Sample (1,batt,FP2)
EndTable
BeginProg
SetStatus ("USRDriveSize",31744)
Scan (1,Min,0,0)
PanelTemp (PTemp,250)
Battery (batt)
CallTable (ABC)
NextScan
EndProg

You can run the program above and monitor the ABC file using PC400 File Control as well as the public variables OutStat and LastFileName using the Monitor. You will see that the variables are allways one scan/record behind the file.

Knows anybody how to correct this behavior so that the variables are updated immediately after the file is written?

Regards
Monte

* Last updated by: Monte on 6/8/2010 @ 8:19 AM *


Dana Jun 8, 2010 06:42 PM

In my testing, I found that the variables are updated the next time the CallTable is executed. I'd double-checked with the OS development engineer, and I've copied his explanation below. In short, it is done this way so that writing large files will not hold up any other tasks in the scan that issued the CallTable.

The developer's response:

To allow the TableFile to do its job, without tying up the rest of processing, the file creation etc. was moved to a separate operating system task. So the scan that calls the TableFile sends a message to the other task when it is time to "bale" the data. The "baling" task does not set the output variable directly, rather it signals back to the CallTable task that it has completed and it is the EndTable execution that writes the user variable.

This works great to offload the work and allows the calling scan to do other tasks, but as you are learning, it adds complexity in understanding when the output variables are set. The update does not happen until the following execution of EndTable. If the files take longer to write than the CallTable interval, then of course the flag will still not be set.

I hope this helps to clarify the operation of the instruction. Basically, about all you can do to minimize the effects of this delay in writing the variables would be to run your scan at a faster rate. I usually run at 1 second, so I've never noticed this before.


Regards,

Dana


Monte Jun 8, 2010 08:27 PM

Thanks for the fast and intelligible answer.
Since a faster scan rate is not an option for my application, I think I will read datas from the Data table using GetRecord, then write it to a file using FileWrite. That way a have it under my own control when and which file was written.

Log in or register to post/reply in the forum.