Emerson Exchange 365

• Not Answered

PHV Not Displaying Decimal Points

Is there a limitation or configuration setting for Process History View to display decimal points?  I have several historized tags where the PV is scaled out to the 5th, 6th, and 7th decimal point.  The Y-Axis displays fine, but when I use the cursor to select an instant in time the "Parameter Reference" pane below the graph where the "Value" is indicated only displays a zero (0).

Is this a limitation of PHV or a configuration setting?

Thanks.

CH

Chris Hogan

• 27 May 2021 2:11 PM
• Cancel

4 Replies

• Andre Dicaire

  

  • 27 May 2021 5:00 PM

  The Decimal Point information is part of the Scaling Parameter associated with a parameter. The Historian and workstations use the parameter path to locate an associated Scaling parameter in order to get the range, units and Decimal point data of a float parameter. If the path is MOD/PID1/PV.CV, the default scaling parameter is MOD/PID1/PV_SCALE, which provides EU0, EU100, UNITS and Decimal place (Field name escapes me at the moment).
  
  Does the parameter in question have an associated Scaling parameter in the module? If so and it is configured to 0, than that would explain it.
  
  Note that if the named param_SCALE path does not exist, DeltaV will look for PV_SCALE and OUT_SCALE as alternatives. If there is no Scaling parameter meeting one of these three criteria, a Default EU range of 0-100% would be used.

  Andre Dicaire

  • Cancel
• Chris Hogan

  

  • 27 May 2021 5:27 PM

  In reply to Andre Dicaire:

  Thank you, Andre. I looked at the OUT_SCALE parameter of the AI1 block and found it set to 0 to 100, with no decimal places. After changing the decimal places to 6, and reopening PHV, it now displays the full value.
  
  Thanks again.
  CH

  • Cancel
• Matt Forbis

  

  • 27 May 2021 6:00 PM

  In reply to Chris Hogan:

  I feel like this is the right place to mention this in case others come along. A floating point number is limited to about 6-7 significant figures. So, the 5th,6th, or 7th decimal place is fine if your scale is say 0-1, but if the scale is 0-100, this could be introducing some errors. For example, 12.3456789 if you tried to store it in a FP notation would actually be stored as 12.34567928314208984375 based on the way the math works. DeltaV Charms are more limited in the fact that they have a 16 bit A-D converter, so the smallest resolution you could get would be 0.0015%. Your application might be fine with showing this many decimal points, but definitely something to keep in mind when it comes to what you are seeing vs. what the reality of the internal math is handling.

  • Cancel
• Andre Dicaire

  

  • 27 May 2021 6:21 PM

  In reply to Matt Forbis:

  I'm going to jump to the defense of CHARMS and the use of 16 bit AD and say it is not limiting. The limit of data precision is in the sensing technology. Having a 64 bit floating point number to represent a sensor value that is limited by a 12 Bit A/D, which is then passed into a 4-20mA signal with a 12 bit D/A and pulled out at the CHARM with a 16 bit A/D still gives you an accurate number. Having more precision at the end of the chain does not make the value any more correct.
  
  And Matt is correct that if the scale is 0-100, the value does not become more accurate when the value is between 0 - 1. Showing more digits after the decimal place is the result of how the Floaing point number is comprised of its Log and Mantissa. But the accuracy of the process value is defined by the sensor and transmitter and it can't get any better than that. So if the transmitter says its accuracy is +/- 0.01%, that 16 Bit A/D is more than good enough.
  
  On a 0-100 scale, having two digits after the decimal place is more appropriate, and you avoid a noisy value that represents insignificant change.

  Andre Dicaire

  • Cancel