I am using Perspective, Ignition 8.1.23. In some of our PLC programs (Rockwell), our AOIs come with very large and very small numbers for some defaults (to make it abundantly clear when the defaults haven't been modified, mostly for alarm setpoints so if they aren't needed they don't unintentionally alarm). For example, one of these default values is 3.39999995e+038. When I try to use a numeric input field to adjust this, the number is not displaying correctly.
The tag is indirectly bound, and my issue exists regardless of which number format I use. The numeric input field seems to truncate the number to the first decimal (when looking at it in scientific notation), and then concatenate the exponent to this number. 3.39999995e+038 becomes 3.438 in numeric format and 3.4380e+0 in scientific notation.
I tried adjusting the exponent down until this issue went away - once i get below 3.39999995e+015, the number then begins to represent correctly again.
One interesting thing I found is that the number displays correctly in LED and Label fields, and also shows up correctly in the numeric entry field properties. Another interesting thing is that I can change the value in the props, and it will change in the PLC (for example if I change the exponent from 38 to 36, the number changes correctly in the PLC) - same for entering the e038 number in the field. Is there a limitation to how large or small of a number can be shown on a numeric input field?
Can anyone indicate if there is a way to have the number represented correctly in the numeric entry field?
Pictures below.
Properties:
Result (first is the numeric input, second is the LED obviously, and third is a label):
No apology necessary. This forum is peer support. Though IA folks do participate (some quite a bit), it's mostly us users and integrators sharing our knowledge. Once a real bug is identified, IA's formal process needs to know.
There were some known issues with sending values with scientific notation to and from the frontend, but they should be resolved as of 8.1.23. This looks like a different manifestation, so a support ticket would be good so we can investigate further.
Support ticket submitted and it is being checked internally. Apparently the issue only manifests when a binding is configured. Here's something interesting that popped up - if i apply a format (number) transform to the binding, then the numeric entry field displays the number correctly, but i lose the ability to make it bidirectional, which is less than ideal. I am playing around with a tag write script (maybe on a popup triggered from a click on a Label with an unbound entry field and an "update" button or something) as a workaround. I could go and set all my AOI values to more reasonable values, but now it's a challenge.
If anyone is interested, I can post the workaround when/if I have one, although I may be the only person that ever needs to deal with this until there is a permanent fix.
Well if anyone ever runs into the issue, then I have a workaround.
First, some background - I have an overview screen with objects, in this case, tanks and valves. Clicking on a tank brings up a popup (WIT) with details and setpoints, and I pass the UDT path and label (tag name) as parameters. I have embedded objects with the numeric entry field (Obj_NumInp) and a label for units. This embedded object has parameters for numberFormat, units, value (inout parameter), Type (this is used to indirect in the embedded object), and UDT path.
Working from lowest level to highest:
The Obj_NumInp object has a numeric entry (Inp_Value) and a Label (Lbl_Units). On Inp_Value, the value property is bound to the value input parameter (bidirectional). The format is bound to the numberFormat parameter. Now to enable
Now, on each instance of Obj_NumInp in the WIT popup, I have an expression on the numberFormat parameter that switches between numeric and scientific notation based on the value, in my case 100,000 and -100,000, otherwise very large numbers in either direction show NaN. The instance value is indirectly bound to the tag at the UDT path.
Hope no one will ever need this info, but here it is.
