Emerson Exchange 365

• Not Answered

DeltaV Control Studio Condition Expression

Hi,

I am stuck here with an expression.

I have an input from a RIO which I want to check if the status is GOOD or BAD so I am using a CND with the expression

'//TE_1/IO1/C07/P01/PUF/SLOT004/SIGNAL001/STATUS'  != Good.

I tried also IF Then but it wouldn't work. 

I good condition I get 

An wit the RIO offline I get a Device error

But the Output of the CND does not change.

May be some can give me an idea were to look for. 

Best Regards, Juergen

Juergen Wetzel

• 28 Apr 2022 12:57 PM
• Cancel

10 Replies

• ShaneG

  

  • 28 Apr 2022 6:48 PM

  Would a semicolon (;) at the end of '//TE_1/IO1/C07/P01/PUF/SLOT004/SIGNAL001/STATUS' != Good;

  • Cancel
• SBPosey

  

  • 28 Apr 2022 8:31 PM

  In reply to ShaneG:

  I don't have familiarity with RIO. Is STATUS a string? I'm used to see numerical values when looking at an online CND expression. If it is a string, you would need: != "Good"

  • Cancel
• Juergen Wetzel

  

  • 29 Apr 2022 4:34 AM

  Hi,
  
  Thank's for your replies.
  
  I tested it right a way and with "Good" it works.
  
  Thank you.

  • Cancel
• Andre Dicaire

  

  • 29 Apr 2022 9:54 PM

  In reply to Juergen Wetzel:

  Good is a keyword, along with BAD and UNCERTAIN that can be used for comparing status. They equate to GOOD = 128, Bad = 0 and UNCERTAIN being 64. But more accurately, they are bitwise masks so that the Substatus and limit status values are masked. Look up the Status values in BOL to understand how the Status bits, sub Status Bits and limit status bits come together to form the status integer values.
  
  So .ST = GOOD will be TRUE for status values ranging from 128 to 255.
  .ST = UNCERTAIN will be TRUE for Status values ranging from 64 to 127
  .ST = BAD will be TRUE for status values ranging from 0 to 63.
  
  In your expression, you are looking at .../SIGNAL001/STATUS. This does not look like a DeltaV Status field, but rather a parameter value under the "SIGNAL001" object. The Expression view returns a value as a string "Good". If this were a status field, this would return an integer.
  
  Since it also returns "Pic Device Error" it further confirms you are dealing with a string value, and not a status field. So, the keyword Good, will not work, and as SBPosey suggested, you must use the string format, "Good", and therefore it worked.
  
  If you were to compare a path.ST != "Good"; that would always be true because a status field will never be a string value, let along a string of "Good". But path.ST != Good; will false when status is =>128, and True when <128. You have to know what the data type is in order to get a successful logical equation.

  Andre Dicaire

  • Cancel
• Brian Hrankowsky

  

  • 2 May 2022 5:26 PM

  In reply to Andre Dicaire:

  Andre Dicaire
  
  I had tested how good was used in the expression interpretation and found that it did not work like a mask unless using the bitwise operators. Do you have some working code handy that shows it working as a mask when used with a comparison operator?
  
  Apparently i can't paste an image today, so the text below will need to suffice:
  
  put this in a calc block and got:
  out1 := good = 128; (* out1 will be 1 *)
  out2 := good = 192; (* out2 will be 0 *)
  out3 := good & 192; (* out3 will be 128 *)
  
  if you set the input statuses of the calc block to align with 128, 192, 192, you'll get the same thing when you do this:
  out1 := good = 'IN1.ST';
  out2 := good = 'IN2.ST';
  out3 := good & 'IN3.ST';
  
  so the "=" operator does not appear to cause the behavior of "good" to act like a mask in the comparison.
  
  is there a trick i'm missing?

  • Cancel
• SBPosey

  

  • 2 May 2022 8:41 PM

  In reply to Brian Hrankowsky:

  Yes, GOOD has a numerical value of 128 (you can see this with: 'OUT1' := GOOD;) There is no special logic for status comparisons like there is for modes (e.g., '/MODE.TARGET' := CAS; will actually set the AUTO and CAS bits). Caveat: There is special logic for "Limited" checking. The status byte uses 2 bits (upper 2 bits) for status (00=bad, 01=uncertain, 10=GoodNoCas, 11=GoodCas), 4 bit (middle 4 bits) for substatus (bit values mean different things based on mode), and 2 bits for limits (00=not limited, 01=Low Limited, 10=High Limited, 11=Constant [Low and High Limited] -- I may have the Low Limited and High Limited bits reversed).
  
  The existence of additional bits on the status is why we use "< GOOD" for status checking.

  • Cancel
• Andre Dicaire

  

  • 2 May 2022 11:27 PM

  In reply to Brian Hrankowsky:

  Apologize for that. GOOD constant is equal to 128, and a bitwise compare is required to cover the range of possible comparisons. Or a range compare such as >=. .ST >= GOOD covers all GoodNonCascade and GoodCascade values. Doing a Bitwise operator .ST & Uncertain avoids doing a double range check of >= Uncertain and < GOOD.
  
  In this original problem, the referenced value was a string, so the reserved Constant of GOOD was not working.

  Andre Dicaire

  • Cancel
• Brian Hrankowsky

  

  • 3 May 2022 12:02 PM

  In reply to Andre Dicaire:

  you had my hopes up. i had hoped my testing all those years ago had missed something since we use the >=, <, etc. approaches mostly, but it seemed like it would have been nifty if comparing to good automatically took care of masking. of course it'd been nice if Emerson had provided functions IsGood, IsNotGood, etc.

  • Cancel
• Hans Grinwis

  

  • 12 May 2022 12:47 PM

  In reply to SBPosey:

  Not to worry about "less than" or "greater than or equal to", use 'IN1.ST' & GOOD = GOOD

  • Cancel
• Brian Hrankowsky

  

  • 12 May 2022 1:52 PM

  In reply to Hans Grinwis:

  most of the time you really just need this:
  'IN1.ST' & GOOD.
  
  or this:
  
  not ( 'IN1.ST' & GOOD)
  
  there is a nice description in BOL on how type casting is handled that lets that work :)

  • Cancel