FieldPoint Family

Showing results for 
Search instead for 
Did you mean: 

cFP-1804 get current time


I'm trying to squeeze the last bit of control loop speed out of the cFP-1804, and to do that I need to synchronize the control loop (running on PC) to the sampling of the slowest module in the system, the AI-111. I'm trying to do this based on timestamps returned from AI read operations. It would work if cFP-1804 and PC time tracked prefectly. However, that is not the case. So I need to somehow read the time from the cFP-1804 and establish the difference to PC time. I'll need accuracy in the <100 ms range to be successful. I found documentation that cFP-1804 time is synched with PC time on whole second basis which is not good enough.


It does not seem straightforward to read the cFP-1804 time. Using some creativity (too much?) I thought that if I could make some immediate event happen and read the appropriate timestamp I would get the current time.  I'm partly successful, but discovered some strange behaviour when I ran the following operations in a timed loop:

1. I write a new value to the USER LED, different from the previous. I get a timestamp back, let's call it A. I was hoping that A would be the current time of the cFP-1804...

2. I read the USER LED status, repeatedly at 1 ms intervals, collecting the values and timestamps.

3. Looking at the values and timestamps from the read operations, I notice that the write operation is reflected in the readback value and timestamp up to 30 ms after the write operation (timed on PC). Until then, the value/timestamp of the previous USER LED write is read. I don't know if this delay corresponds to the real delay until the LED is actually updated, or if only the readback status is delayed. The documentation is lacking information. Anyhow, the delay is within what I can accept. But let's call the first timestamp received from the read operations B and the last timestamp value C.


I notice that A < C. The difference is quite constant at about 1100 ms. (C-B) is equal to the timing of the loop, which makes sense. Timestamp A may be larger or smaller than B, depending on loop timing.


The big question is whether A or C can be trusted as the correct timestamp, or are they both unreliable? In my opinion they should be the same. Can anyone explain why they are different?


I suppose USER LED may have been intended for other purpose than reading current time, but is there another way? Of course I could write/read a dummy AO channel or dummy DO channel, but I doubt it will yield more accurate time than USER LED?


Any help will be appreciated!



PS: Using Labview 2009, cFP-1804 firmware 6.08, Win7-64bit, FP 6.0.11, time server configured and working

0 Kudos
Message 1 of 5

Follow-up with some more information:

I've tracked timestamps from FP Read VI and FP Write VI during some manual changes to the PC time and after command "w32tm /resync" to have Windows gradually correct the PC time. I plot all timestamps vs. Tick Count to see how the offset evolves during time.


-> Timestamps from FP Read VI get offset when changing the PC time, and within minutes that offset is adjusted away by the cFP-1804 time server update. This is as expected. The "whole second" adjustment limit of time I've read about does not appear in my measurements.

-> Timestamps from FP Write VI does NOT change with changes in PC time or with changes in cFP-1804 time. The timestamps slowly drift away from any sensible time reference. In my setup the rate is about 300 ms per hour.



- The cFP-1804 time reference for FP Read is periodically updated from the time server. In general it can be trusted.

- The values and timestamps from FP Read VI are slightly delayed, current maximum delay measured on PC is 49 ms, but this may be inaccurate.

- One way to get current time from cFP-1804 is to read one or more AI or DI, and finding the maximum timestamp value. Only accurate if an AI or DI input has actually changed.

- Another way to get current time from cFP-1804 is to write a new/different value to USER LED, AO or DO, and using FP Read VI to read back the timestamp (after a delay) when the read back output value matches the written value.

- The FP Write VI returns a timestamp that cannot be trusted.


Question to NI:

What time sorce is actually used for the FP Write VI timestamp? If this is a known bug, is it corrected in a newer version of Labview or Fieldpoint driver? Otherwise, please correct this odd behaviour.




0 Kudos
Message 2 of 5

Hi Svein,


From my understanding of the initial situation you have described you have a current read function timestamp (A), and a current write timestamp (C), the first of which you've labelled (B). I would imagine you are seeing a shift between B<A and B>A when the timing of the loop is changed such that the read operation is executed before the write has actioned. If this is the case both timestamps are correct and given at the time the specific operation executes. Highlight execution maybe able to shed some light onto this. 


I've done a little research around the area to see if there are any known issues with this, and found the following which I hope will be of use: 


Let me know if either of these help!


0 Kudos
Message 3 of 5
0 Kudos
Message 4 of 5

Hi, thanks for following up.The links didn't work, but the link from Armen did. It did not help me any further though.


Still, I'm quite sure that I have figured out how it works now. I'm trying to attach a VI to show how. The VI writes and reads the USER LED. After changing the led value the Fieldpoint Read VI gets what I think is the correct timestamp (after up to 50ms). This part works fine.


However, the Fieldpoint Write VI returns a timestamp that is very strange. After starting Labview the value is correct, but the value drifts off with time. Changing PC time, watching Logos update Fieldpoint time (through Read timestamps) or restaring the Fieldpoint unit does not change/correct the offset. I've seen the timestamps returned from Read vi and Write vi reach 15 seconds difference during about a week of continuous Labview running. Quitting and restaring Labview and the VI does however reset the offset. So my conclusion is that the timestamps returned from the Fieldpoint Write VI are unreliable, and probably generated by some buggy method on the PC and not on the Fieldpoint unit!?


The attached VI may be used to:

1. Get the current time from the Fieldpoint unit. You may use some other output than the USER LED if you prefer that.

2. Demonstrate the buggy timestamp from the Fieldpoint Write VI. Start Labview, open the VI and modify to get it running with you Fieldpoint unit. Then leave Labview running for a long time (hours to days) and observe the timestamps from the Fieldpoint Write VI get more and more different from the timestamps from the Fieldpoint Read VI and the correct PC time. Your timestamp drift may of course be different from what I've seen on my hardware.



Now on Labivew 2010 and FieldPoint 13.1.

0 Kudos
Message 5 of 5