While configuring SFCs I detected a strange issue. If I have a transition which monitors the value and the status of a dynamic reference, it does not become TRUE if the connection is lost.
To better evaluate: I build a dynamic reference to a string parameter of a module which is running in another controller. My SFC monitors in a transition the respective parameter for both value and status, like this: ('LINK.CST' != 0) OR ('LINK.CV' != "text"). If I disconnect the controller from the network, CST is -1, but the transition does not progress. It evaluates to TRUE OR ????. This should be TRUE I believe like in most other programming languages but in DeltaV it is FALSE. The system should detect that one of my conditions is true, so my OR expression has to be true.
The workaround I thought of is to create two separate transitions, one for the CST, one for the value.
But anyway, I want to ask whether this is the correct, intended behavior. And if yes, why?
I have a scenario with two SFCs running in different controllers, synchornized. I want them to reset if they lose the dynamic reference to the other or if the other says "error".
In reply to Matt Stoner:
It appears to behave as though Abort on Read Error is enabled on the expression. I don't see an option to turn this on or off, but Emerson recommendation would be to have this turned on to avoid, as recommended for CND, CALC and ACT blocks that read data from remote sources.
I don't consider a loss of communication to be an immediate call for action. Checking the CST is absolutely the right thing to do, but the response to a loss of communication shouldn't be the same as a confirmed "error". There should at least be a delay in the response. If the status was good and the value did not indicate an Error, what are the odds that at the moment communications are lost, the value would also go to Error?
I'd probably have two transitions, one for the explicit value and the second for a loss of Communications. I'd add a timer to the CST transition and take that path after a few scans, giving time for the comm issue to clear, incase it is a transient condition. How long to Wait? that depends on the application. Maybe no delay.
I could not find any references to this behavior on SFC transitions in BOL, or trolling CTS calls. BOL recommends the use of .CST, suggesting it be placed in a confirm statement. Pending confirms would never get to 0 and a transition could move forward based on the step time. Not sure I'd do it that way, but the point is BOL seems to indicate you should be checking status separately from where you read the parameter. (I maybe stretching that interpretation).
When using CND block to do interlock, I used Abort on Read Error in the CND reading the value(s), and used a separate CND to handle loss of COMM, and used the delay time to avoid a hair trigger on loss of communication. Latest revs of DeltaV do a better job of holding value and status on a switchover, which means a loss of communication is likely not due to a transient condition like a switchover. However, I still like to delay a response to loss of comms...
Andre Dicaire