Emerson Exchange 365

This issue appears to be identical to the known issue detailed in KBA NK-2300-0009. It has been hot fixed in certain DeltaV versions.

In reply to frederg:

Matt Stoner has good info about this topic.
if you read Books Online about "Using Profibus DP, DeviceNet, and AS-Interface with DeltaV Function Blocks", you will see this issue is similar. it likely requires the same work around.

I'm not sure the previous replies are answering your question.

If you simply want the PV_D to indicate Undefined when communications is lost, then you could configure a CND block to detect bad status in the running feedback and connect the output of the CND block to the second input of the DC block. Then set the state masks as in the picture below, which assumes that input 2 is 1 when status is good. However you would still need to consider what you want the output of the DC block to do on communications failure. Presumably go to the passive state as you say the VSD will have done this itself. Otherwise there is a chance that the DC block will restart the VSD when the status becomes good.

In reply to Cedric Dawnhawk:

yep. sorry i jumped the gun on what issue was being mentioned. for soft inputs we also do something similar to what Cedric Dawnhawk mentioned. It would be much nicer if the DC and EDC blocks indicated undefined and also coudl set the PV status (no status on named set parameters).

In reply to chrisslattery:

some additional notes: BOL discusses use of External References for use with DeviceNet, Profibus, and other signals like P01 LDT's. Basically, the IO value remains unchanged when Communication is interrupted. This includes Outputs. If you use IO blocks to write to the signals, these will stop writing if the status is BAD. This is why External References are recommended as the control module can change the value of the Signal in the IO map.

In this case, the pump is tripped on a loss of communication. I would suggest that this trip should be delayed so that you don't disrupt the process due to a transient condition on the network. Assuming that is all working as desired, what happens when communications is restored? The Pump is now stopped. Will it see a command to start when communications return? The signal value will be sent before the module can execute and clear it. While communication is down, the module doesn't know if it is running or stopped.

BOL instructs us to use External references and to use logic in the module to clear the commands to a passive state. Use a timer to avoid spurious trips on a transient bad status. In general, if the outage lasts more than the timer, you have also set the device to trip on its own and the Module will set the output passive. I think you would want to set the device trip time to be a second or two longer than the DeltaV time, which, if it expires the motor is stopped either by DeltaV or the device time out, in the case where comms are restored after DeltaV timer expires but before the motor trip on loss of comms expires.

Having a momentary start with Latched Stop bits ensures that DeltaV will neither start or stop the motor when communications are restored. The module will have to drive the start bit explicitly to restart the motor if it stopped and if it is still running, will leave it running.

Some devices have a single start/stop bit, but a second reset bit that after a communication loss, the motor will ignore the Start/Stop bit until it sees the reset bit. This gives DeltaV time to align the Start Stop bit with the PV so that on reset, the motor remains in its current state.

If you are not using a two bit explicitly commanded output to the motor when communications is restored, and need to align the output to the expected value while communications are down, you have to use external references to effect the value of the signals.

Andre Dicaire