Logging Vs Export Sets - Both work well.

[dmdodd]

So I have a global variable for a "Syngas Mass Flow Rate" (calculated from many channel data inputs:- a gas composition analyzer, temperatures, pressures and differential pressure across a pitot tube).

Anyway, it calculates perfectly and I've been able to log it successully to both Logging sets and Export Sets.

For the Logging Sets, I used the "manual" entry and then wrote a sequence to "addvalue" to this manual column whenever the logging set is running.

For the Export Sets, I merely added it as a variable with "[0]" after it, then made a sequence to loop the export file every few seconds and update (append) the export file.

Anyway, both methods seem to work perfectly... so:

(a) I'm wondering what is the benefit of either/or? I'd prefer the less processor-intense way, as the amount of things I have this old PC doing now it may start pushing it.

I also will be running (and loggin) for 100hrs continuously, logging all process variables and channels every 5 seconds (= ~17,000 lines of data per 24 hrs).

(b ) Is there a max amount of data one can store to a *.csv file?

(c ) I wanted to get the logging and export files to update at midnight (with new day's date and therefore start a separate file), can I do this with both logging sets and exports sets?

Thanks in advance,

Daniel D.

[AzeoTech]

a) logging sets log every data point they receive as they get them. Export sets log only when run, typically after the data is received. That said, logging sets are usually used for basic apps and apps where every data point is sacred (no Monty Python reference intended...) Export sets are typically used where conditional logging is desired and where one has data at different rates and wants to easily just generate a file with data at a constant interval for each row.

No, as long as your hard drive can hold it, but do realize that Excel can only handle 65535 rows. Yet another reason to use something other than Excel for data analysis, but I've largely given up on that battle...

c) yes you can do it with both and its easy to do. In one of your loops, simply change the file name for the logging set or export set every iteration. Use formatDateTime() function to incorporate the date into the file name. Since most of the time, the date isn't actually changing, the file name is actually not getting changed, but come midnight, it will turn over and DAQFactory will automatically close the old file and start another. You do not need to stop the logging set.

[dmdodd]

I got the following code from either a previous forum post, or possibly the DAQFactory Manual, I can't remember. I'd been trying to use it, and was testing it by moving the computer's time a few minutes before midnight and then watching to see if it started a new logging file and it didn't, any ideas?

In your previous message, I can see it working if and only if you don't also display the time in the file name when logging, if you do display the time also, then wouldn't it make a new file every iteration correct rather than updating the previous file?

We still need the ability to

// loop forever:

//while (1)

// wait until 11:59pm

waituntil(23h59m)

// wait another minute to move us into tomorrow

delay(60)

// set logging file name:

Logging.SE_Mk4_continuous.strFileName = "c:\DAQFactory\DAQFactory_Data_Logs\SE_Mk4_data_continuous" + formatdatetime("%y%m%d_%H%M%S",systime()) + ".csv"
Logging.SE_Mk4_intermittant.strFileName = "c:\DAQFactory\DAQFactory_Data_Logs\SE_Mk4_data_intermittant" + formatdatetime("%y%m%d_%H%M%S",systime()) + ".csv"
// and repeat

endwhile

p.s. love the Monty Python Irish-Catholic 'sp*rm song' reference! Hilarious

[AzeoTech]

First, the sequence isn't valid because you commented out the while() but not the endwhile. Second, you don't need the waituntil() or delay(60). Just put the logging... lines inside one of your other loops, or in the Event of your fastest channel.

Also, unless you are using the userTime.dll, DAQFactory only reads the system clock on start and then uses its own internal clock, so changes in the Windows system clock won't affect DAQFactory until you restart.

[dmdodd]

Indeed that fact that I needed to restart my DF after making a change to the system time would probably explain why trying to test the "next day" switching of the log file would explain it.

(haven't got a clue why the "while" was hashed-out "//", but nice observation all the same)

[AzeoTech]

Yeah, the other thing is that waituntil() doesn't work well with time changes (another reason why we don't like customers using userTime.dll and DST). Anyhow, waituntil() internally doesn't immediately recognize the time change. WaitUntil will actually cause the thread to sleep for 1/2 the difference between the time the command was executed and the time we're waiting for. So, if you change the clock in that time frame, nothing will happen until that original 1/2 time has elapsed. I'll save you the boring details of why it works that way.