The answer to your question doesn't involve any programming and hence I'll be moving your question to All Things PI -> PI Visualization.
The behavior is controlled through the Displaydigits PI Point attribute which is initialized with -5 when you create a new PI point. If you don't change the default, you will see the scientific notation. For your purpose, please try setting Displaydigits to 0 or 2.
Thanks for your comment, this works.
Bien So please allow me marking my answer as the [Correct Answer].
Does this apply to "Value" symbol as well?
For example, the values of attribute in PI AF, say Attribute 1, is 123.45677. PI Coresight displays it has 123.45. There is another attribute, say Attribute 2, has value 12.4567609, PI Coresight displays it has 12.45676. These attributes are mapped to PI Point and "DisplayDigits" attribute is set to default, -5. So what controls the decimal places in PI AF and PI Coresight, if it is not "DisplayDigit" PI Point attribute?
I have tested the behavior once more and found that
a) DisplayDigits is used, no matter if looking at a PI Point directly or at an Attribute with a reference to the PI Point
b) The scientific notation, which is what you usually get with (-5), is not used. You need to specify DisplayDigits with a positive number indicating the decimal places that you would like to see.
I'm running into a similar problem with scientific notation.....however my data is coming from a Table lookup not a PI tag the data type is Double shows up correctly in AF correctly as 118100.61 yet in PIVision is displayed as 1.181E+05.
Please accept my apologies for the late reply. There's nothing similar to DisplayDigits with the Table Lookup data reference because you just have the data itself and not any attributes which you could use to define a preferred data format. You could try to CAST to a certain string format within the SQL Query you have in the Attribute definition but this will likely cause that the trend cannot be rendered properly anymore.
The Trend symbol in PI Vision (PI Coresight) doesn't offer to set a format string or similar which would allow you to define how a value is represented. You could try creating a custom Trend which a) applies another default format or b) allows to configure the data format.
Hello Jason do you have any other suggestion to adjust the display format of a table lookup, type double for a Trend symbol.
I took a look at this and I am seeing the same behavior. Unfortunately, table lookups are do not have any settings for formatting how the value should be displayed. In PI Vision 2017 R2, we are adding a feature that will allow you to override the default number formatting on the visualization side. Here is the feedback request we have tracked this under, Number Formatting. I have tried this with the table look up and it works in our current development builds.
I have an AF Attribute, which is a formula, getting it's data from a PI tag, plus a known number. Sounds a bit funny, but basically I am tracking machine cycles using analysis, which outputs the an increment number every time the machine cycles. I then add the increment number to the AF attribute, to give me a total. Now, the AF attribute value shows today for example a value of '2197099' however in PI Vision, it is displayed as hex 3.9728E+06
How do I get this to display as an integer like it is in the AF Attribute in PIVision (CoreSight)? The Attribute is currently set as an Int32 data type.
Unfortunately, as Jason mentioned above, the default displaydigits value is -5, which means to show only 5 significant digits. When your integer has more than 5 digits, it will display with 5 significant digits using scientific notation. Currently AF does not allow the number of display digits to be specified for anything other than a PI tag data reference, where it comes from the PI tag.
Fortunately, we are adding number formatting options in the next release of PI Vision. When that is released you can either say that you want to use the "General" format or specify that you want to see 0 decimal places. In both cases, the number will not switch to scientific notation for the values you are using.
I find that sometimes I don't remember to set display digits when building new attributes or using existing tags. When I then incorporate those attributes into a PV display, it seems to want to "remember" the -5 decimals for a long time after I change them in PSE.
In what cache or database are these display digits shown, and how can I force PV to be more current on updating them when they are changed? It kind of makes tables look ugly if I can't individually control the decimals. I realize that this can probably largely be mitigated by more careful initial configuration before creating displays, but nonetheless, it would be good to know strategies for improving control over display digits in tables.
I actually see now that when I am trying to configure the templates, the display digits for table lookups and formulas are reverting to -5 after I change them. Any idea what is causing this?
I don't see how to change the displaydigits of an Attribute using the PI Point Data Reference in PSE. I find it grayed out which makes perfect sense to me. If I change the setting in PI-SMT, PI Vision immediately uses the new setting.
Am I overlooking something? Can you please describe how to reproduce the issue you are experiencing?
I should be more clear, this is with table lookup and formula data references. PI Points themselves don't show this behavior. It may be more of a limitation than anything else.
If I change the display digits of these attributes in the template, they appear to change, but then revert to -5 when refreshed.
For example, here I've configured the table lookup attribute template for 2 display digits. It shows this way until I refresh, at which point it reverts to -5.
After I refresh, it's back at -5.
Am I missing something simple?
When testing, I realized that my environment wasn't up to date and I also had the impression the behavior may have just recently been updated.
Updating my environment took me longer than expected but I finished this today and were able to test. According to your latest reply, I changed definitions in the Attributes Template.
Please make sure you have the latest bits installed and to check-in Template changes.
Retrieving data ...