I have a general question about the DeltaV OPC server. What is the deadband for scanning logic modules or I/O? Is this configurable? Is this matched it to the module scan time or I/O scan time/scan priority? I could not find mention of this in the DV documentation.
I do not have or notice any issue with this, currently, but we are transitioning a large Provox system to Deltav and don't want to cause any issues in the future with our external PI-OPC client and data transfer which is the plant wide historian for management/corporate folks. We are familiar with how this is handled on the PI point side but are wondering about the DV controller execution to DV OPC server loading.
thank you
Sean, DeltaV uses a 0 deadband in it's communication exception algorithm. This mechanism is unlike that of PROVOX, where an exception deadband is used to determine when a point needs to report to a remote node.
When a DeltaV module executes, it determines if a parameter has changed based on whether the value has been written to. Only parameters that are explicitely requested by a node are sent, rather than all the variables in a module. The communication layer consists of a proxy server in the host node (Controller) and a proxy client at the destination. The data requested by the historian node will be sent by exception and resides in the local proxy client at the historian node. The PI OPC DA scanner will get its data from this proxy client via the DeltaV OPC Server.
If you use the DeltaV Continuous historian, it will pull the data from the Proxy client directly. PI OPC HDA scanner can be used to pull data from the DeltaV historian to push this to PI enterprise server. The DeltaV Historian has similar compression capabilities. The time stamp of the data is set by the historian. With the OPC DA scanner, I believe you can set the time stamp in the scanner for the data sent to PI.
Andre Dicaire
In reply to Andre Dicaire:
Hi,
I have a related question about OPC timestamping. Let's presume we have a control module with one input and one output. Its input is written through OPC and its output is read by another OPC client. It does some calculation. Let's say that the calculation's result can be the same for some inputs.
For example, it gets "3" as input and gives "10" as output. After that, it gets "4" as input but the result of the calculation is still "10". The OPC client which reads the output of the control module still sees "10" with the initial timestamp which was generated when the result for "3" was calculated.
Is there an easy way to see that it is in fact a new value? Where is this update "blocked"?
Thank you,
Istvan