If you are using the Get Date/TIme vi, the timesource is the OS. This clock will drift away from the
hardware clock under CPU load, just like on a PC. Do you have any loops w/o waits or something
else that might be using up a lot of CPU cycles? If you turn off the FP unit for an hour does it power
up thinking it was off for 50 minutes? This might indicate a hardware problem.
After much gnashing of teeth and many discussions with very patient NI people, I have collected the
following suggestions for time on embedded fieldpoint:
1) Use the hardware clock as a source rather than the OS. Create a 500 mS loop to do a FP Read
of one of the dip switches on the controller and write the timestamp to a functional global. Read this
functional global whenever you want the 'real' time. Don't use the Get Date/Time or similar functions.
2) Anywhere that you need only relative time, i.e. 'do x every 500 mS' use the mS timer function.
3) If you are doing a time comparison make sure you consider the case where the clock is significantly
out of whack, either direction. If the clock gets a step change (daylight savings?) you don't want your
1 S loop to wait 3600 +1 S ( or worse, wait until LV time overflows in 2038!). Actually this is more of a
general LV suggestions.
4) Handle the setting of the time on the FP unit within your application. Disable the timeserver. This
way you know when your clock changed plus you can address any potential jitter.
Hope something in here helps.
Matt
