Need help with tag scaling

Hello,

I have some question about Raw/Eng scaling for variables.

First of all, I'm using OPC protocol and all the variables are already scaled in the RTU. I want to use the automatic scaling for process analyst, bargraph, etc. So I need to indicate the Eng scaling for all my variables.

First thing I notice is if for example I read a value from a variable who is between 0 and 100 and I configure a raw scale from 0 to 120 then the value will not be good and that's make sense. If I configure the raw value from 0 to 80, then I will have a good reading even if the scaling is not accurate...

Second, If I configure only the eng scaling but I let the raw scaling empty then the value will not be scale properly as it seems to using a default scaling of 0 to 32000 or something like that.

Third and this is my biggest problem, we use OFSOPC protocol for local variable to use as memory. For some value that we received from the RTU we copy them in a local variable to keep a memory of the value in case that the RTU have some trouble. If I have an OPC variable with a raw scale from 0 to 100 and I actually read -2.0 and I try wo write with a cicode this value to my memory OFSOPC variable (wich have no raw/eng scale configure) then it didn't write.

I tought that using the parameters [Code]ScaleCheck to value 0 will resolved this but it does not.

Can you help me with this please ?

Parents
  • According to the help (System Model > Variable Tags > Configure Variable Tags > Add a Variable Tag | Scale Properties), the eng scales default to the same as you enter for the raw scales. I believe the raw scales default to 0-32000 as you said, so you need to set the raw scales. I normally set both raw and eng to the same range to make it clear that no scaling is occurring (just min/max limits for operator input and trend charts).

    It will still display values that are out of range. However, it will not allow the operator to write an out of range value. Process Analyst will use the eng scales, but will still show values that are out of range if you zoom out. Make sure to use the 8-byte trend storage method. If you use 2-byte trends, out of range values are not recorded/displayed. If you change the scales for a tag recorded by a 2-byte trend, you also need to delete the existing trend data files or it may record/display data with the wrong scale. Note that you can also set the zero/full scale in the trend tag properties if you want to override the tag scale in Process Analyst.

  • Thanks for the precision about the eng scales default to the same as the raw scale.

    But my real problem here is that a tag value that is out of range cannot be copy to a tag with no scaling. 

    TAG1 have a scaling of 0 to 100 and TAG2 have no scaling defined. The value of the TAG1 is out of range (let's say -5.0) and I want to write is value to TAG2.

    TAG2 = TAG1;

    Then nothing will be write. I understand that I cannot write an out of range value to the TAG1 but I'm trying to write into a tag that has no scaling.

    Maybe you can help me with that ! Thanks.

Reply
  • Thanks for the precision about the eng scales default to the same as the raw scale.

    But my real problem here is that a tag value that is out of range cannot be copy to a tag with no scaling. 

    TAG1 have a scaling of 0 to 100 and TAG2 have no scaling defined. The value of the TAG1 is out of range (let's say -5.0) and I want to write is value to TAG2.

    TAG2 = TAG1;

    Then nothing will be write. I understand that I cannot write an out of range value to the TAG1 but I'm trying to write into a tag that has no scaling.

    Maybe you can help me with that ! Thanks.

Children
  • I tried it and found that the command Tag2=Tag1 (when Tag1 is out of range) fails with Cicode error 257 (value is out of range). An out of range tag has Uncertain quality. I didn't realize that Citect would not use Uncertain  quality values in a statement, like it does for Bad quality values.

    It would be best to set the scale of the tag to the actual range of expected values. If you want a smaller range for trend charts, set that scale in the trend tag definition.

    A work-around is to use the command Tag2=Tag1.v   The v extension gets the value of the tag without any quality information so the command still executes.

    Oh, and I was mistaken in saying the scale defaults to 0-32000. I checked in v8.30, and the scale defaults to the range for the data type. For example, an INT tag defaults to -32768 to 32767, and an UINT defaults to 0-65535

  • Very interesting about the change in default raw range.  I hope it doesn't break too many people's projects!

  • We have always set the scaling on every numeric and digital variable tag, along with every trend tag. So far, no effect on us. Even when there is no "scaling" to be performed, we just set the engineering and raw to the same values. And yes, even the digitals are scaled 0-1 with an EU of T/F. We did that due to the lack of actual digital trend tags and needed a way to identify them in the historian.

  • I doubt it will break many projects at all.  From what Eric said, i don'e think the default reanges have changed for a while, if at all.  The main point here is that they have to be ranged the same or the same proportions.  A 1:1 scaling is a 1:1 scaling. 

  • What actually append is that we have analog input 4-20mA and if we lost signal the amp. will be probably be 0 so we can read a negative value as in the exemple (-2.0).

    If the last value stored in TAG2 was 10.0 and then we lost signal on the TAG1 so it's value is -2.0 then we will not write -2.0 or not even 0.0 in TAG2. So it will stay at 10.0 and this is problem. For information, all of our tag have a raw and eng configure.

    So I think I will go for the hot fix, using the tag extension ".v".

    Thanks

  • You should use the tag extension ".Valid" that stores the last good known value. The ".V" stores the same value as the default tag.

  • The question is whether you want to know the current out-of-range value (-2 indicating failed sensor) or the last good reading, which wouldn't tell you if the sensor has failed.