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 AdrianOffield:
Yes, this is also a possible workaround. The SFC is a composite, and I would like to keep these inside.
Currently I solved it with a stored action at the beginning which monitors the CST and sets a flag if it goes bad. Then my transition checks the value OR the flag.
I was just wondering why it does not work simply with a transition.
In reply to István Orbán:
If you don't need the action to be running in your S2 step, change to non-stored so you don't have the extra loading and/or housekeeping to stop the action with logic in S2.
I suggest logging a call with Technical Support on this issue. This way it can be determined if this is working as designed, broken and needs to be fixed, or a decision to leave as it is because of upgrade 'opportunities' and it might work differently for users if changed.
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
In reply to Andre Dicaire:
Thank you all for the analysis.
Andre, our controllers and I/O cards are not redundant so there will be no switchovers. It could still be a good idea to put a delay on communication loss.
I opened a call NC-1400-8554, we reached the same conclusion that this is probably due to the "Abort on read error" being always enabled for SFC transitions.