Identical timestamps from FP-1601

[Graybeard]

I'm running LW/CVI under Measurement Studio 6.0, and using FP-1601/FP-AI-100 modules to acquire and timestamp data on a win2k workstation. I'm doing synchronous reads every 50 msec using the FP_Read function and a timer callback. I also call the windows API GetSystemTime immediately after the call to FP_read.
When I compare the two timestamps, I see much greater variability in the Fieldpoint timestamps. The system timestamps are nicely clustered around 50 msec, but the Fieldpoint timestamps range over several hundred msec. In addition, there are many instances where a Fieldpoint timestamp is identical to the preceding one, but the system timestamp clearly shows 50 msec has elapsed.
I want to stamp the data at the origen to avoid l
atency issues, but the accuracy of the imestamp returned by the Fieldpoint module is too course to allow this.
The Lookout Time Sync service is running on the workstation. The firmware on the FP-1601 is at 4.17. Does anyone have any suggestions?. TIA.

[Aaron_G]

First of all, let me describe a little bit about how the FieldPoint ethernet communications work. This information can be found in more detail in various KnowledgeBase articles.

When the FieldPoint Server (including the FieldPoint OPC Server) is launched or a DataSocket connection is made to a FieldPoint Ethernet module, the FieldPoint ethernet module uses a subscription-based message on-change communcation protocol. The first subscriptions between the module (server) and client (PC or RT Controller) will contain timestamp information and the current value of any/all data points that are subscribed to. After that, the FieldPoint ethernet module will continuously poll any channels (on its attached IO modules) that have active subscriptions. As it polls each channel, it compares the current value to the last value for the channel and places it is a queue for transmitting if it has changed. At the end of the cycle, it transmits all changes to the client machine with timestamp data included. For boolean type data, any change is considered enough to cause a transmission. For analog data, you can configure a percent guardband on a channel per channel basis. Only changes greater than the guardband setting are transmitted.

On the client machine (PC), the FieldPoint Server acts as a client to the FieldPoint ethernet module and as a server to your application (LW/CVI, LabVIEW, or OPC Server). When your program performs a read into the server (in your case at 50 ms intervals), you are actually reading the data that is cached locally on not sending a read request directly to the module. Thus, your program may be reading the server at 50 ms intervals, but th ethernet module may not be sending data at the same 50 ms intervals.

Remembering that data is sent on change only (which minimizes network traffic), the All Channel Update Rate of a module must be taken into account. A module such as the FP-TC-120 has an All Channel Update rate of 1.13 seconds, so the data for an FP-TC-120 channel will never have the timestamp update in fewer than 1.13 second intervals. However, the FP-AI-100 has an All Channel Update Rate of 2.8 ms, which is pretty quick compared to the 50 ms read rate. This brings us to the question of how fast your input signal is changing and what guardband that you have configured for the channel. A 1% guardband on the +/- 36 Volt range for a FP-AI-100 channel would require the reading to change by 0.36 Volts before it was transmitted. A slowly varying signal would thus be seen by your program as having the FieldPoint timestamp only change over longer periods of time even though your system timestamp is changing at 50 ms intervals.

Finally, the number of clients, subscriptions, channel types and signal changes effect how quickly a FieldPoint Ethernet module is able to poll the desired channels and transmit the data. Generally speaking, to improve performance, you should delete any unused channels out of the FieldPoint configuration file (ethernet only, they do not have an effect on serial performance). Channels that need to be read at a lesser rate can have higher guardbands applied.

Regards,
Aaron

[Graybeard]

Thanks for your detailed response Aaron. The guardband on my input was set to 0 - I assume that means any change on the input signal will cause the data to be transmitted. However the input signal was a constant voltage with a bit of noise. With a time varying signal, the timestamps from the FP-1601 look much better. The fieldpoint modules are on a dedicated sub-net, so net traffic is not a concern.
You mention that this information can be found in other KB articles. I've searched and have not been able to find anything this detailed. Can you point to a specific area or articles? Thanks again.
Leo B

[Graybeard]

I have a second question: As I mentioned above, the FP1601 and FP-AI-100 are on a dedicated subnet with no other devices, and I'm only using a single channel on the AI-100. During an acquisition cycle, I've noticed that the timestamps are sensitive to events on the client machine - such as mouse movement. Why should anything that happens on the client affect how time is assigned to a measurement on the FP modules? I've read some of the other posts here and in the KB on mouse movement and real time processes in a windows environment, but I fail to see how it applies here. Appreciate any help.
Leo B

[Aaron_G]

Leo,

There are activities on host PC's that may affect FieldPoint timestamps due to the nature of the time synchronization. A FieldPoint ethernet module synchronizes it's time clock with the specified Time Server at 10 second intervals. The process is very similiar to a PID loop for the time on the ethernet module. However, if the Time Server responds to the synchronization request with a "substantial" delay, the time stamps on the FieldPoint module may get a little off. I have only seen this when a PC processor is running at 100% utilitization or when there were network slowdowns (taking a 10BaseT network through a 56K converter than back to 10BaseT).

Regards,
Aaron