• Not Answered

External reference .CST non-zero while .ST is not bad?

Is it actually possible for an external reference parameter's status (.ST) to indicate something other than Bad Communication when its connection status (.CST) is not zero?

In particular, I am interested in whether or not there is any way for the .CST to be non zero and the .ST indicate some form of Good.

I've made several attempts at causing this, but in all the cases I could come up with, the .ST went to Bad Communication if I had a non-zero .CST.

If the .ST always indicates Bad when the .CST is non-zero, is it really necessary to look at the .CST to determine a parameter's status?

Thanks in advance.

• DeltaV #DCS
• external reference

Brian Hrankowsky

• 17 Aug 2021 1:16 PM
• Cancel

3 Replies

• Andre Dicaire

  

  • 17 Aug 2021 3:38 PM

  That is a very good question. the .ST will be BAD if the .CST is not good. The .ST can be BAD even if the CST is GOOD. .CST allows you to take a different action on loss of connection versus a BAD status at the source. If your design is to take the same action in either case, then you can simply rely on .ST as it will go BAD on loss of connection.
  
  When using external references, a dynamic references to remote parameters, you may want to check that these references are successfully bound prior to using them in a sequence or other configuration. Checking the .CST confirms connections are good, and any BAD status will be due to the source parameter status. If connection is not made, you would report this prior to starting what cannot successfully finish.
  
  Connections can go bad temporarily following a controller switchover, or a disruption in both networks, or a total download of the source node, or obviously a power outage. One reason is a change in configuration that removes the referenced parameter. With Dynamic references, the $REF path is not defined in the database and deleting or renaming a parameter would not create any verification issue, and would only become apparent once the $REF is defined. Checking .CST with Dynamic References is I think a best practice and allows for explicit error handling on that issue.

  Andre Dicaire

  • Cancel
• Brian Hrankowsky

  

  • 17 Aug 2021 9:54 PM

  In reply to Andre Dicaire:

  Thanks for the response!
  
  For the use cases I had in mind, the failure handling would be the same for bad ST and communications issues. That was a good point that sometimes different handling may be needed for a communications loss.
  
  Follow-up question:
  I've thought of Dynamic reference statuses and external reference statuses (CST and ST) to behave the same. What you wrote above indicates that too - right?

  • Cancel
• Andre Dicaire

  

  • 18 Aug 2021 6:38 PM

  In reply to Brian Hrankowsky:

  Brian, I had to do some checking to refresh on the details. Things did not behave quite as I thought
  
  Basics, .CST returns an integer value
  -3 means 'external reference not resolved'
  -2 means 'parameter not configured'
  -1 means 'module not configured'
  0 means 'good'
  1 means 'not communicating'
  
  .ST returns a Byte comprised of Status, Sub-Status and Limit status. with numbers ranging from 0 to 256(See BOL table for the various combinations) and GOOD is anything above 128. (not all values in this range are used/defined)
  
  So the format is different.
  
  But I also found that a CALC expression did not return a .ST value when .CST was not 0 (Good), while a Watchit window monitoring .ST returned a value of 60, which is an undefined BAD status.
  
  With the $REF blank, or invalid, the .ST caused an error in the CALC expression with the yellow ? mark and BLOCK_ERROR showing Output Failure. Watchit shows .ST as 128 and .CST is 0.
  
  With $REF is not blank but not valid, .ST reports a value of 60 and CST is -1 in Watchit, but in my CALC expression, .ST causes Output Failure and .CST shows -3.
  
  On a physical loss of connection (CST = 1), I believe the .ST would go to BAD (0), but I wasn't able to test this as I am working remote.
  
  I don't know why WATCHIT is reporting a different value that the CALC block when the reference is invalid.
  
  It seems to me that one has to first confirm $REF is defined. Then use .CST to confirm the reference is successfully bound and ready to be used. at which time, .ST will reflect the status of the source parameter. From this point on, a loss of connection or the module not communicating would set CST to 1 and this should be reflected in .ST. (But at this point, I feel I need to confirm this on a test bed, as I not expecting Watchit to show different .ST value than an Expression).

  Andre Dicaire

  • Cancel