Daylight Savings Time

[rbhollabaugh]

Is there any way in DAQ Factory Express to get the DST flag from windows?

[AzeoTech]

No. DAQFactory uses its own internal clock that it bases on the windows clock on startup. After startup it does not check the windows clock or DST flag. For this reason, DF will not adjust for DST. This is done to avoid getting duplicate data with the same time, or a large gap in data. These sort of things can mess up data analysis, or worse cause alarms and other events that you may have coded for acquisition failure to trigger inadvertently as most people only think about DST and its effects when the change occurs.

That all said, we will probably provide a way to get the DST state in Release 6. At least then you, as a DAQFactory developer, would be forced to consider DST in your event coding and hopefully avoid the issues mentioned above.

[Gammatech]

Following on from the previous question, is there a method of getting the windows flag that it has updated daylight saving? If there is then would simply using SysTime -3600 if DST is set or straight SysTime when DST is reset allow the display of time in say BST in the UK whilst DAQFactory can run in GMT?

[AzeoTech]

We'll look to see what is involved in this and perhaps include it in the upcoming 5.78 release.

[AzeoTech]

OK, we have added a function to 5.78 that returns the current DST status of the current time. The function is:

system.IsDST()

it will return 1 if in DST, and 0 if not.

Its important to remember that DAQFactory only uses the system clock when it first starts. After that it uses a high precision timer. This means that any changes to the system clock while DAQFactory is running will not have an effect on the DAQFactory clock. The DST status is based on the DAQFactory time and your region. If you try and test this flag by changing the system time, you will need to restart DAQFactory to capture this time change.

More importantly, if you start DAQFactory while DST is in effect, it will use the DST time. So, your correction of 3600 seconds needs to look at DST when DF starts as well. Basically you want to do this:

1) store the result of System.IsDST() in a global variable at startup. Lets call it InitialDST

2) instead of Systime() - 3600, you would do:

systime() + (System.IsDST() - InitialDST) * 3600

that way, if the system starts in DST and switches to non-DST it will subtract 3600 because DAQFactory will be using the DST time.

Let me also restate why we don't do DST correction for you: at the moment of DST there is either 1 hour of duplicate time or 1 hour of no time at all. Unless you have programmed your scripts to take this into account, this can result in alarms mistriggering, acquisition hangs, or worse total catastrophic failure. Since DST only happens twice a year and is rarely on ones mind, it is very easy to forget to take this into consideration when coding. To protect you from this, DAQFactory does not correct for DST.

[Ken]

On the topic of system time and DF only looking at the time prior to starting, would it be possible to provide the option, if the coder so decides to use the system time ?

The reason for this request is because a client is looking for a means of using NTP

(http://en.wikipedia.org/wiki/Network_Time_Protocol)

so that they can sync all computers/ethernet enabled devices on the network for fault condition analysis.

This way they can find out what first caused the fault based on synchronized timing.

[AzeoTech]

Yes. Copy the attached UserTime.dll (located inside the zip file) into your DAQFactory directory and restart DAQFactory. It will then use the system time instead of the high precision timer. This means any change to the system time will change in DAQFactory which has a number of issues that I've already talked about. Also, the precision of your time measurements will be much lower, something on the order of 15milliseconds instead of 1 microsecond.

usertime.zip

[Ken]

Thank you for such a quick response, resolution, and also taking the time to reiterate the pit falls and other issues.

I will discuss this with our engineering department again to inform them of what we are giving up to do this.

Obviously our preferred method is to just use DF as intended, but to provide the customer their request we will have to do some hard testing to ensure there are no issues.

Again thank you for the amazing support.

[AzeoTech]

I think the answer is for DAQFactory to use UTC instead of local time for all its timing and then the pitfalls for shifting local time for daylights savings would, I believe, go away, except for time stamps on data. I've added it to the request list for 6.0. We'll see how it works.

I should also mention, for those that are interested, that you can create a DLL similar to the one I attached that gets its time from anywhere and DAQFactory will use that time. So if you have a GPS or IRIG time stamp, you could write a simple DLL to use that time instead of the PC time or DAQFactory clock. This is great when you need to syncronize multiple computers to a single time source.

[ekanderson]

am using Daqexpress for a weather station with LJ U3 that stays up for one to two months. DaqExpress'es clock can loose up to a minute plus in that time.

will usertime.dll work with express?????

thanks

eka

[AzeoTech]

Yes, I believe so.