Why is the data sometimes out of order?

Prior to version 2.6.3.5 of the interface, if the OPC server sent the interface a new value just as ExcMax elapsed, it was possible that the interface would send the exception value with a timestamp slightly after the new value's timestamp. Version 2.6.3.5 fixed this problem in the case that timestamps were provided by the interface (i.e., /TS=N), but it was still possible for exception values to appear out of order when the OPC server supplies the timestamp. This bug has been fixed in subsequent versions of the interface using a slightly more complicated mechanism than previous versions used.

Figure 1 shows how this mechanism works. The interface now holds on to each exception value for a short time, thold, before sending it to the Data Archive. If a new value arrives during this short time with a timestamp from before ExcMax elapsed, the interface sends the new value but discards the exception value. In version 2.6.4.x, thold is set to either 2 seconds or 90% of ExcMax, whichever is smaller.

Figure 1 - Mechanism of handling ExcMax in version 2.6.4 and later

A new value that arrives within ExcMax of the previous value (e.g., at time A) does not trigger an exception value to be sent. On the other hand, if both ExcMax and the extra holding time elapse before a new value is received (e.g., at time C), the interface sends the exception value at tExcMax + thold with a timestamp equal to the previous timestamp plus ExcMax. Finally, if a new value arrives after ExcMax has elapsed but before the extra holding time has elapsed (e.g., at time B), the interface will only send the exception value if its timestamp would occur before the timestamp on the new value. This way, the exception value never appears with a timestamp later than the new value, provided that the new value arrives within tExcMax + thold of the previous value.