Controlling data Transmission/Atomicity
This page describes how to control the publication of DPE values through the
DIP API manager.
The first thing to understand is that no data from DPE's will be published
- Until the API manager has received at least one value for each of the
DPE's making up the publication. Until this time the data quality is set to bad and
the reason for quality string indicates how many DPE's have not yet supplied
initial values.
- When any of the DPE's making up the publication have their invalid
bit set (see above).
The time at which the data from DPE's making up a publication are sent
is partially determined by the buffer time (mSec) which is provided in the
client configuration panels of the JCOP framework. When
- Buffer time = 0. All DPE's making up a Publication are expected to
be updated within WinCC OA atomically. Thus the DPE values received by the API
manager will be published immediately (assuming one of the 2 conditions above
do NOT hold).
- Buffer time > 0. The first DPE making up a publication triggers a timer.
All changes to DPE values making the Publication are recorded, when the timer
expires (BufferTime is reached) the most recent value of each DPE making up
the publication is published (again, assuming one of the 2 conditions above
do NOT hold).
This policy is motivated by the philosophy of DIP which requires that all
fields making up a DIP complex publication are consistent. It is recognized
that DPEs making up a publication may be updated from different (most likely
unsynchronized) sources and at different rates, so the buffer time mechanism
is used to provide a means for 'ensuring' all updates to DPE's
are received before the publication is made. Whilst this mechanism is
far from perfect, it is relatively simple and given the indeterminate date
of the DPE updates, the best we can currently think of (any better suggestions
will be greeted with interest).