This section describes controller communication behaviors in order to help you design your system to ensure data transmission between DeltaV nodes.
Reads - Reads are the preferred method for communications. For example, Controller B has an input parameter defined as an external reference to a parameter in Controller A. Controller B initiates unsolicited updates with a one-time request for data from Controller A. From then on, Controller A updates Controller B when the exception criteria are met (a status or data value changes). Any references in Controller B are then reading buffered data that is automatically updated by the system's communications processes. This is called unsolicited sending.
The unsolicited send occurs at the same priority as low priority modules on the source node. When referencing a parameter in another node in an expression, you can verify communications with that parameter or node with the .CST field. The .CST field can be referenced in blocks such as the CALC block or SFC expression.
When verifying the status of a reference in another controller, .CST is recommended instead of .ST. The .ST value is set by the sending node. As such, if communications is lost, the .ST value does not change and holds its last value. The CST value is set by the receiving node. Every time the module executes, the .CST value is updated with the current remote status.
Your configuration should be designed to accommodate occasional, intermittent bad status. It may not be good practice to immediately trip an emergency shutdown on a single instance of bad status. You can configure timeouts on bad status as appropriate to avoid unnecessary shutdowns.
Similarly, it may not be appropriate to design control logic with immediate response to unexpected events. On any interlock or shutdown conditional logic, provide appropriate time delays before the system takes significant action in response to the event. For example, it may be appropriate in some cases to allow a bad status for several seconds before shutting down or taking other serious action. Time delays can prevent unnecessary shutdowns in the event of intermittent events caused by electrical noise, redundant controller switchovers, partial downloads, and so on.
Buffered Asynchronous Writes - When calculation block expressions, action block expressions, and SFC/PLM/Phase Class actions write to a parameter in another node, the output is buffered. This is followed by an asynchronous write request to the destination node with the new data. These occur at a priority lower than low priority modules on the source node. Buffered asynchronous writes are also done for external reference parameters in other nodes.
With these definitions in mind, note the following functionality regarding data exchange between nodes:
Buffered writes are processed every 500 milliseconds.
Reading data is preferable to writing data, both for loading reasons and for communications status reasons. A read operation has the appropriate status, depending on the state of communications. At the destination, a written value holds the last value and last status and does not indicate communications problems if they exist. If there is a communication failure between nodes, a written value does not reflect the current value and status of the source data.
Normal situations occur in which both reads and writes fail. Partial downloads, overload, redundancy switches, and other operations can all cause a read or write operation to fail (possibly without any indication of failure) at some instant.
Unsolicited send operations contain a maximum of 4000 parameters per second for SX/MX controllers and 2000 parameters per second for SD Plus and MD Plus controllers. This total is enforced. If the same parameter is being requested by multiple nodes, that parameter is counted multiple times against this maximum. If there are more than the maximum number of unsolicited parameters to be sent through an unsolicited send operation within a second, the excess parameters are held until the next second. This means that, although the parameter data eventually arrives at the receiving node, the date may be slightly older than expected. Develop configurations using a limit of 2000 parameters per second for SX/MX controllers and 1000 parameters per second for SD Plus and MD Plus controllers. Exceeding these recommended limits may affect system performance. In general, 2000 parameters per second for SD Plus and MD Plus controllers and 4000 parameters per second for SX/MX controllers cannot be sustained to another single node due to receive limitations and overhead and handshaking limitations.
Write operations of either type are recommended to be no more than 40 per second per node for SX/MX controllers and 20 per second per node for SD Plus and MD Plus controllers.
The scan rate of modules configured with asynchronous writes must be greater than 100 ms to allow processing time between write operations.
Reading any or all array elements from one controller to another is supported. Write operations of arrays from node to node are not supported. An error is returned to the caller.
Due to normal system dynamics, a group of buffered asynchronous writes (such as multiple actions in a single SFC step) does not necessarily act on the destination parameters in a predictable order.
Due to the relative priority of the various read and write operations versus other tasks in each node, in cases of overload situations, reads and writes may not occur when expected.
A pulse action that writes to a parameter in another controller will retry the write as necessary while the step is active. With the step active, this continues until the write gets confirmation from the destination node of success. Possible write failures that will set ERROR and RERROR to TRUE include the write being rejected due to a wrong mode or the value being invalid for the data type. In these cases, the write will be retried on the next execution of the module. Between executions of the module, ERROR and RERROR will be TRUE, but will toggle back to FALSE while the action status is PENDING. If the next attempted write again fails, the cycle repeats.
In cases of communications failure, the retry mechanism will continue to attempt the write as long as the step remains active. In a communications failure scenario, feedback is not available from the destination and ERROR and RERROR will remain false. The write continues to be retried as long as the step is active.
If controllers are heavily loaded, the write may be re-buffered if necessary until there is feedback of success or failure.
When a write fails, the action gets an error, which rolls up to the step, composite, and SFC level in parameters called ERROR and RERROR. The phase's failure monitor can examine these parameters at the run logic level and actions can be taken to inform the operator that a write has failed or other actions can be performed as appropriate for the users implementation.
Keep inter-module and inter-controller communications to a minimum. Place I/O references within the control module, not in a separate I/O module. Keep related modules with inter-module references in same controller.