Hi,
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!
Regards,
Svein
PS: Using Labview 2009, cFP-1804 firmware 6.08, Win7-64bit, FP 6.0.11, time server configured and working