Failing backfill of analyses. pirecalcualtionprocessor-log gives floats for int values. This messes up the analyses. Preview has the desired outcome.

if hot = 1  then 
1
else if  luke = 1  then
2
else if cold = 1  then 
3
else 
Nooutput()

Hi , i'm trying to do the above analyses.

When checking pirecalcualtionprocessor-log i find the following issue:

  Attribute:'SW21031.PV' Value:0,001027522 Timestamp:27-Aug-23 19:56:00.005 UOM:

  Attribute:'SW21032.PV' Value:0,9991463 Timestamp:27-Aug-23 19:56:00.005 UOM:

  Attribute:'SW21033.PV' Value:0,4998802 Timestamp:27-Aug-23 19:56:00.005 UOM:

The .PV values are floats instead of ints.

The analyses does not have the desired solution.

I assume this is because the values are not being calculated as 1's.

I tried the following for all points:

  • Changed pointtype to Int32
  • Changed Step to 1
  • Used Floor() and int() in the analyses.

All these did not change the outcome of the analysis.

I searched Google but can't find any solutions.

Any help would be appreciated.

 

Kind regards,

 

 

Parents
  • Do the tags 'SW21031.PV', 'SW21032.PV', and 'SW21033.PV' represent hot, luke, and cold respectively?

     

    I would urge you to honor i.e. mirror the data type of the PV's as they are defined in the field. I am guessing they may be coming from a DCS or some controller, so find the right support person to get the right point definition.

     

    Once you understand the precise data type and what the value means in the field, you should change your Analysis to conform to the inputs, not the other way around. This means you may not make an exact comparision to 1's but rather need to find you are close enough given some tolerance. E.g. with a tolerance of 0,1, then a value of 0,9991463 is greater than or equal to 1.

     

    Note for analytics: internally numeric values are all treated as double precision floating point values regardless of the input type. While you can set to Int or Round to consider it to be whole, internally it is still a Double/Float64. Granted, you may later push that rounded Double value into an Int32 on the data archive.

     

  • Hi Rick,

     

    First of all thanks for taking the time to respond.

    The tags are switches which represent that cold, luke and hot are either on or off.

    They are generated by a Yokogawa DCS-system. The values send from there are 0 or 1.

    I tried making these digital as you suggested so they could either be 1 or 0 which are the only states they can be. This unfortunately did not fix the issue.

    I agree with what you say for analog signals (for example temperature) that tolerance should be used. Since the switch can only be 0 or 1 i hope this will not be needed because i assume this will create other issues down the line.

    I still don't understand where the floats come from. I understand for the calculation doubles are used. But this should be 0.0 or 1.0 in my opinion. Other values are just not send from our DCS-system.

     

    Kind regards,

Reply
  • Hi Rick,

     

    First of all thanks for taking the time to respond.

    The tags are switches which represent that cold, luke and hot are either on or off.

    They are generated by a Yokogawa DCS-system. The values send from there are 0 or 1.

    I tried making these digital as you suggested so they could either be 1 or 0 which are the only states they can be. This unfortunately did not fix the issue.

    I agree with what you say for analog signals (for example temperature) that tolerance should be used. Since the switch can only be 0 or 1 i hope this will not be needed because i assume this will create other issues down the line.

    I still don't understand where the floats come from. I understand for the calculation doubles are used. But this should be 0.0 or 1.0 in my opinion. Other values are just not send from our DCS-system.

     

    Kind regards,

Children
No Data