Emerson Exchange 365

• Not Answered

Diagnostic parameter as interlock for motor

Hi, 

I would like to add a interlock to a motor so it turns off if the DeltaV controller loses connection to the rest of the system. 

Does anyone know a good way of doing this? 

Best regards, 

Simon

Simon Ahr

• 1 Nov 2023 12:01 PM
• Cancel

1 Reply

• Andre Dicaire

  

  • 1 Nov 2023 2:34 PM

  We could debate whether you should use an interlock or create a shutdown module that can take the process to a safe state in an orderly fashion.
  
  As the title suggests, diagnostic parameters exist that reflect the loss of communications. Since DeltaV has redundant networks, they exist for both, so you would be looking for CNTRL_NAME/COMM/PRI/CONGOOD= 0 on both primary and secondary networks. If there is one good connection, then the controller is communicating on the network. Once a controller establishes a connection to another device, either a console to send data to, or another controller to read data from, that device is added to the connection list and monitored by diagnostics. You should weigh the information from ConGood and ConBad carefully to avoid a spurious trip. Rebooting a console will result in a Bad connection until it is returned to service. Monitoring ConGood = 0 says no one is talking. I don't have access to my system at the moment so you will have to check if these parameters are available at run time to a control module. If you can browse to them in Control Studio, they are. Some are available but not browseable and some are not available to the controller, only consoles.
  
  What is the reason you need to shut down this particular motor on loss of communications? Is that condition met with 1 good connection? That is, if a total loss of Operator Visibility (all consoles offline) is the reason to shut down this motor, that could occur and there still be a good connection keeping the parameter above 0. If the main issue is loss of connection to another controller for process reasons, the console connections would still be good.
  
  Another approach is to create some "critical" connections to the nodes that need to be connected and monitor those explicitly. The connection status of an external referenced (,CST) will indicate if the remote parameter is communicating. Losing all connections is detected with the diagnostic value. More specific conditions are monitored explicitly through Connection status of references. For example, if you read the WKSTN/HORN parameter, and it goes to CST <> 0, (and place a timer on this so you are not tripping spuriously, you know that particular station is not communicating at the moment.
  
  If you create a separate module for detecting the various conditions that lead to the need to shut down this motor, you can reference this module in your interlock, or you can shut the motor down programmatically from this module, allowing you to do an orderly shutdown and set the control settings of multiple modules. You can also add some condition traps that record the reason for the trip and log events to that effect. Even if the Event Chronical is not communicating at the time, an event record will be buffered in the controller and get recorded when the chronical is back online, provided you don't trigger multiple events, as the buffer is only one event deep. If you lose events, then the chronicle will record a "One or more events have been lost" along with the latest event generated. Time stamp is from the controller.
  
  Anyway, this looks like a good case for spurious trips that could cause you more pain than good. Make sure you have an appropriate delay in activating the shutdown so that transient conditions don't trigger unnecessarily.

  Andre Dicaire

  • Cancel