Should IsQualityGood propagate the Quality of the tag?

Forum / Questions & Answers

Real-Time Manager at CSE ICON
damon_vinciguerra.1
6 days ago
4replies

We have a use case where we have two flow meters that we want to sum up. If one of them is Bad quality from SCADA, we want Calcs to treat it as zero.

We did If(IsQualityGood('tag1'),'tag1',0) + If(IsQualityGood('tag2'),'tag2',0)

It works, but the output value has a Bad quality if one of the inputs does. Is that expected? I would have thought the output of IsQualityGood always have a Good quality.

The issue is it's making the output trend in Axiom light and people are wondering why.

Calculation Server

- smason
- 2 days ago
- Reported - view
Hi ,

It should output a Good quality. You would want to do if(IsQualityGood(Quality('tag1')),'tag1',0). Notice the Quality() function is embedded within the IsQualityGood() function. Not sure if this is how it is actually configured, but this is how you would want to do it.
- Real-Time Manager at CSE ICON
  
  damon_vinciguerra.1
  
  2 days ago
  
  Reported - view
  didn't we try this? Or was this exact formula chain something we didn't try?
- System Engineer | CSE ICON
  
  davin_ross
  
  2 days ago
  
  Reported - view
  We didn’t attempt this approach initially, but I tried it now and it works (though a bit verbose).
  Good catch, ! Calc documentation agrees and suggests IsQualityGood(Quality([tag])).
  
  That said, this design feels limited. Why require explicit chaining with Quality() instead of allowing IsQualityGood or similar functions to directly validate tag quality? Wouldn’t integrated handling reduce complexity?
  Additionally, as Damon mentioned, passing a tag directly into IsQualityGood achieves the same validation but allows the original quality flag to persist into the resulting value. This means if the data is marked as bad, that status remains attached to the output rather than being stripped away. Why is this the case? Is the intention to preserve downstream quality context, or is it simply a side effect of how the function resolves tag references internally?
- smason
  
  yesterday
  
  Reported - view
  I understand your point. The quality check functions didn't come until we already had the Quality() function. Before then, users were just using a comparison of Quality(tag)=192, but this was limiting because there are obviously many quality codes that are Good. So it just made sense to pass one function into the next.
  
  The other reason, and maybe more importantly, is that you can also pass in variables instead of tag names. In some cases, a variable may be set to the quality of a value instead of the value itself. This would break in the scenario in which the value of the input represents a Bad quality, such as 0 or 32768, but the quality of that input is Good. The IsQualityGood() function would return False, when in fact the quality of the input is Good. If that makes any sense...
  
  In Damon's scenario, I'm not sure how it would've been returning True unless the value itself happened to have the exact bits set. The IsQualityGood() function looks at the 7th and 8th bit. So if, depending on the value, I guess it could return True.
  
  In my testing, it always returned False when I passed in the tag directly.