DFExpress Exit with Onshutdown sequence problems

[ekanderson]

DFExpress 5.80.

OnShutdown code

*****

// shutdown code Last modified 30 Apr 09

// 30 Apr 09 eka Implement

function onshutdown()

Note1 ="Shutdown"

Note2 =""

beginexport(aHistory)

delay(4) // added this after 1st instance of DF remaining in memory

return()

*****

Vars are global:

aHistory fields from memory, all 0 length are:

Formatdatetime of a channel's time as month/day/YY time as HHMM:SS

Formatdatetime of a systime() time as ditto

Formatdatetime of a systime() time as YY ordinal day (%j)

Note1

Note1

For this last instance of DF*.exe "retention" in memory, aHistory.csv correctly updated by 3 prior sequences, but Onshutdown's update failed (after waiting 15 minutes, before killing DF*.exe in T M).

Since implementing sequence , have "exited" DF about 10 times, and twice it has remained in memory and

aHistory.csv has NOT updated. WinXP HE Taskmanager does NOT show it as an active Application, but it remains a process. Have had to use T M to end the process (usually after waiting 10 to 20 minutes to see if it would clear).

Over about an 8 month period (probably 300+ DF exits), have only had this problem twice with DF 5.79 and 5.80 prior to the implementation of the OnShutdown sequence code.

*.ctl file usually saved as history just prior to DF exit.

Histories at 240, persistence of "real" channels at 240.

12 real channels, and 11 virtuals

Machine a 500Mhz AMD K6-2 with 512Mbytes of memory.

WinXP SP3

!##*^% McAfee AT&T security suite

[AzeoTech]

The OnShutDown event is designed to allow you to shut things down, not start things up (like an export set). It also should be pretty fast. Starting an export set starts a secondary thread, all the while the rest of DAQFactory is shutting down. It is probable that this is the problem. If you want to write something to disk, you probably have to use the File. functions since these don't start any more threads.

[ekanderson]

OK:

The interesting thing was that DF was running and was putting data points into the Persist files until I killed it with T M.

No output to logging or export files however.

On next restart, after save as with history. Channel time[0] was 1500 (time of last reading before shutdown), but after my startup code which fills the channels with NaN to fill the calculated missing data points, the channel histories had data points evidently pulled from the persist files up to time I killed DF with T M.

So histories contained duplicate entries for times up to time I killed with T M. One with valid data and one with NaN.

How do I ensure that I have the latest history/persist time??????, i.e. when in the file load and execution of DF's code does DF update channel.time[0] when there is a mismatch between a *.ctl's history data and persist data.

Currently I'm pulling the channel.time[0] in the 2nd sequence following the AutoStart seq. with about 1 second from DF load of the *.ctl file to reading of channel.time[0].

ek

[AzeoTech]

I know you aren't going to like it, but bottom line is that you shouldn't use Save With History or the Auto-Persist timer with Channel Persist. Save with History is largely deprecated, though is occassionally used when you want to send a document with all the data to someone else. Its not really designed for use on a machine with persist data for the same channels. I have no idea how the time will line up. If I remember correctly, it uses the history if its available, but as soon as you request data past what is available in the history it goes to persist for the entire thing, which basically means that depending on how much data you request, you may get slightly different data sets.

[BeeHay]

Would using System.SaveDocument() in a button or in a sequence help in "saving" the latest persist data/time in the .ctl file?

[AzeoTech]

Channel persist is not saved with the document. Also the savedocument function doesn't save history.

[BeeHay]

Are V.Channels data saved with System.SaveDocument()?

[AzeoTech]

Yes, but you really have to careful using SaveDocument() or the autopersist timer to persist your data. If you have a power failure during the save your document will be corrupted and unusable, and as your document gets bigger (often because the data set gets longer), the amount of time to save goes up along with the risk of corruption. This is why the autopersist is deprecated. The Channel Persist, on the other hand, writes a total of 24 bytes each time a data point is updated which takes a nanosecond, and if the system were to shut off in that nanosecond, your document would not be corrupt, and actually you persist file would likely only have one data point of corruption.

[ekanderson]

power outages. Use a UPS.

[AzeoTech]

Alas, many DF customers put their systems in remote areas where they are unattended for long periods of time and so UPS'es often can't cover it. However, you are right. Even if the UPS runs out of juice, if its connected to the PC, Windows will shut down gracefully and take DAQFactory down gracefully as well.

Still, using Channel Persist is the preferred method.