I am looking for a way to communicate the status of one controller to another. There is a valve that belongs to a specific controller and it is used in different controller. If the communication in between the controllers is lost, I would like to designate the failure position. Any idea how I could get the status from the other controller and use it in the module?
Rather than the status of the controller, it is a good idea to evaluate the status of the value itself being referenced. You can use .ST >= 128 to ensure quality. Next, you should make use of the ALGO_OPTS and ERROR_OPT parameters in varius function blocks to determine what to do with information when a read error occurs.
The parameters ALGO_OPTS and ERROR_OPT available in many calculation and logic blocks allow you to respond to read errors (e.g. caused by communication loss).
ALGO_OPTS-->AbortOnReadErrors stops execution if a value cannot be read.
ERROR_OPT - Specifies how the block behaves when a read error occurs. The value of PRE_OUT_D will be False (default), True, or the last value prior to the read error as defined in ERROR_OPT (unless 'Abort on Read Errors' is set in ALGO_OPTS, in which case ERROR_OPT does not apply). The status of PRE_OUT_D is BadNoComm when a read error occurs.
I prefer to use ERROR_OPT to define that when comm error occurs, the worst case condition is calculated (either true or false) and never use the 'use last value'. However, this may lead to erroneous trips due to momentary comm loss, so I would temper this evaluation with a time limit, like comm loss for > 5 seconds.
In reply to Youssef.El-Bahtimy:
I prefer Youssef's suggestion of the use of ERROR_OPT and condition block in situations like this but I'm not sure how the implementation of "designate the failure position" will be done but another option would be to use .CST field in the logic.
One possible issue with using the .ST field (according to BOL) is that it is set by the sending controller and will remain at the last value if communications are lost. Use of the .CST is set by the receiving node which if BOL is correct would be the best field to use in your implementation. I don't have two controllers running to verify the statements in BOL.
Possible Values of CST field:
-3 = external reference not resolved
-2 = parameter not configured
-1 = module not configured
0 = good
1 = not communicating
Regards,
Matt
In reply to Matt Stoner:
You should definitely use the status of the parameter and not the "health" of the controller. You should read the parameter value with an external reference, which will also have the .CST (Connection Status) as described by Matt. I believe the .ST will go BAD if the CST goes bad when using an external reference to read the value.
- NoCommLUV – No Communication, with last usable value (LUV). This substatus is set if this value was set by a communication that has failed.
- NoCommNUV – No Communication, with no usable value (NUV). This substatus is set when there has never been any communication with this value since it was last Out of Service.
If you write the value from the source node, the destination parameter will not be an external reference and the parameter and ST will hold the last written value if the source stops talking.
If a change to the source module somehow deleted the parameter or renamed it, the controller would still be "good" but the value's CST would reflect this. The concept of Status and Connection Status is not present in many systems, especially PLC's, where the health of the processor may be monitored, but the health of a register is not available. With DeltaV, each module is an independent "program" with its own Input and output blocks/parameters and order of execution, as well as a defined execution schedule. Having a good understanding of status is key to creating a robust configuration.
I like to explain the DeltaV comm layer as a dynamic Publisher Consume mechanism. You don't have to manually define these publishers or consumers, as DeltaV will do that for you dynamically at run time. You simply reference a remote parameter in a module and DeltaV will create the publisher in the source controller (Proxy Server) and the consumer in the destination node (Proxy Client), and your module will get its remote reference data as well as status. The health of the connection is held in the .CST attribute for each and every parameter.
also note that every parameter has the .st and .cst attributes, even if the parameter is a local parameter. In a local parameter, the .CST is always 0 because you read the value directly from memory, and not via the Proxy Server/clients above. So if you add a check for .CST it will work the same whether the parameter is local or remote.
As Youssef mentions, a loss in communication should have a time delay to avoid spurious trips. I think 5 seconds is too short. At the time a communication loss occurs, and the value was good, what is the likely hood that the value goes to a trip condition in the next 5 seconds or say 30 seconds. What is the impact of tripping when there is no real need to? Can the operator make an informed decision to trip the interlock rather than doing so automatically? In many cases, tripping unnecessarily can be more dangerous and disruptive. The point is you should consider how long that delay timer should be on a case by case basis. If you alert the operator that the interlock is not active, and he is able to operate safely without it, you can give your maintenance personnel maximum time to restore the communications without tripping the plant.
Andre Dicaire