8.1.9 Synchronizing Measurements
Related Topics:
• Synchronizing Measurements — Overview (p. 74)
• Synchronizing Measurements — Details
(p. 365)
Timing of a measurement is usually controlled relative to the CR1000 clock.
When sensors in a sensor network are measured by a single CR1000,
measurement times are synchronized, often within a few milliseconds, depending
on sensor number and measurement type. Large numbers of sensors, cable length
restrictions, or long distances between measurement sites may require use of
multiple CR1000s. Techniques outlined below enable network administrators to
synchronize CR1000 clocks and measurements in a CR1000 network.
Care should be taken when a clock-change operation is planned. Any time the
CR1000 clock is changed, the deviation of the new time from the old time may be
sufficient to cause a skipped record in data tables. Any command used to
synchronize clocks should be executed after any CallTable() instructions and
timed so as to execute well clear of data-output intervals.
Techniques to synchronize measurements across a network include:
1. LoggerNet
(p. 95) – when reliable telecommunications are common to all
CR1000s in a network, the LoggerNet automated clock check provides a
simple time synchronization function. Accuracy is limited by the system
clock on the PC running the LoggerNet server. Precision is limited by
network transmission latencies. LoggerNet compensates for latencies in many
telecommunication systems and can achieve synchronies of <100 ms
deviation. Errors of 2 to 3 second may be seen on very busy RF connections
or long distance internet connections.
Note Common PC clocks are notoriously inaccurate. Information available at
http://www.nist.gov/pml/div688/grp40/its.cfm gives some good pointers on
keeping PC clocks accurate.
2. Digital trigger — a digital trigger, rather than a clock, can provide the
synchronization signal. When cabling can be run from CR1000 to CR1000,
each CR1000 can catch the rising edge of a digital pulse from the master
CR1000 and synchronize measurements or other functions, using the
WaitDigTrig() instructions, independent of CR1000 clocks or data time
stamps. When programs are running in pipeline mode, measurements can be
synchronized to within a few microseconds (see WaitDigTrig Scans
(p. 157) ).
3. PakBus
(p. 88) commands — the CR1000 is a PakBus device, so it is capable of
being a node in a PakBus network. Node clocks in a PakBus network are
synchronized using the SendGetVariable(), ClockReport(), or
PakBusClock() commands. The CR1000 clock has a resolution of 10 ms,
which is the resolution used by PakBus clock-sync functions. In networks
without routers, repeaters, or retries, the communication time will cause an
additional error (typically a few 10s of milliseconds). PakBus clock
commands set the time at the end of a scan to minimize the chance of skipping
a record to a data table. This is not the same clock check process used by
LoggerNet as it does not use average round trip calculations to try to account
for network connection latency.
365
To Next Page
Loading...
Need help?
General
