Acquisition timestamping

[Gael_Robin]

I am trying to log data with an acquisition rate of 1 second using a FP-2015. My real time requirement is only to guarantee a sampling period without missing data. I am having trouble with the timestamping of the acquisition : when using the "Dates et heures en secondes" (approximative translation : "Get Date and hour") VI, or the fieldpoint read VI the timestamps sometimes exhibit weird behaviour (two consecutive identical timestamps, or a gap of 2 seconds).
I first thought it was a real time issue, but it appears to come from the lack of synchronization between the real time clock and the tick timer. I have tried several different solution but without result (disabling the time server synchronization, using "wait until next multiple", time
d loops, "get date and hour", FP-Read timestamps,...). Does any one have a solution to this problem ?

Thanks in advance.

Gael.

[Matthew_Williams]

First I would disable (0.0.0.0) the timeserver setting in the FP unit. We have seen strangeness using the built in timeserver; much better to pass your own time setting in via a tcp message.

Next, something like the attached might be useful. We read the current time, convert it to an int to drop off the fractional second then wait for this number to change. When it changes, indicating a new second, we take a reading. This method will have a short first cycle 95% of the time but subsequent cycles should be 1 +/- .05 or so seconds.

If you skip the int conversion and wait for now + 1 second you can avoid the probably short initial cycle but you run the risk of creep, i.e. 1.05, 2.10, 3.15, etc. You could also do a start + loop count for
your test, but don't use the built in loop counter because it will stop instead of overflowing; use a distinct loop counter as shown.

If you have 7.1, take a look at the new timed loop function. Might be a more elegant approach but I haven't looked into it yet. Hope this helps.

Matt

[Aaron_G]

Gael,

What sort of IO module are you using with the FP-2015. Since you desire a 1 second update rate, you need to be aware that not all FieldPoint modules are that fast. The Analog Input modules have a specfication called the All Channel Update Rate which specifies the amount of time it takes for an IO module to read all of the channels and store the data in the shared memory that is used by the Network module. The [c]FP-AI-100 has an All Channel Update Rate of 2.8 ms, but the [c]FP-TC-120 has an All Channel Update Rate of 1.13 seconds. With a 1 second sample period in your code, you will catch approximately every 357th sample of an [c]FP-AI-100 channel but you will frequently read the same sample of a [c]FP-TC-120 channel since it has not been updated y
et. IF you are using one of the slower modules, this may explain your multiple identical timestamps. For a sample period of 1 second, the following modules will be slower and result in periodic duplicated readings; [c]FP-TC-120, [c]FP-RTD-122, [c]FP-RTD-124, [c]FP-AI-110 (depending on filter settings), [c]FP-AI-111 (depending on filter settings), and [c]FP-SG-140 (depending on filter settings). I do not know the specs on some of the most recently released modules, so the above list may be incomplete.

Regards,
Aaron

[Gael_Robin]

I am using the following modules : FP-AI-100, FP-CTR-502, FP-RTD-PT100, FP-AI-V10 and FP-AI-V5B. But I have made simpler tests without any FP-Read by just displaying the time at each loop iteration and it shows a regular drift that can explain missed timestamps.

Is there a specification of the various "clocks" in terms of accuracy, drift (over time and/or temperature which shouldn't be a problem in my case) : especially the "system clock" used in the "wait until next multiple" VI and the real time clock used when calling the "Get Time" VI ?

Regards,

Gael.

[Synap]

I'm starting to get a timestamp drift now too.

I'm doing a serial connection through the cFP 2020 using the attached Sonic.vi.  I left it running on the cFP unit over the weekend, and so far, I have lost 18 minutes between the reported timestamps and the actual time of the local timeserver that I specified in MAX (does it continuously check the time, or just on the initial 'run'?).  The timed loop period is a minute, so I don't think that the All Channel Update rates will have any effect. 

I suspect that my processing of the data is not happening 'within' a loop period of one minute, but instead, running 'in addition to' the one minute period.  I can't determine if this theory is true or not, and was hoping someone could look at the code to help me out.  The logic at the bottom just stimulates the LEDs on the 2020 to tell me the unit is running, and I have not overlooked the possibility that this could also be causing a problem!

Thanks,