Using a numeric text field component, it requires the tag to be bound to the correct prop based on the tag datatype.
For float vs double, does it really matter which is used? Has anybody mixed them and run into issues?
The manual says Make sure you use the value property that corresponds to your Number Type setting. but does not give any insight as to why or what will happen if you mix them.
Along the same lines... I've always added REAL tags (Allen Bradley processor) as type Double. However, it seems when I add REAL tags from the device browser into a UDT definition it brings them in as Floats by default. I've not had any issues using the Double type everywhere.
Makes me think if I always used the Double type for a numeric text input that it would be just fine and would convert as needed - no?
Well, a double is strictly superior (in terms of resolution) than a float, because a float is 32 bits of information and a double is 64. So it's (basically) always safe to treat a float as a double, but not the inverse, because you potentially lose precision moving from double to float, either at low resolutions or with particularly large values, since float's max value is way, way less than double's max value (3.40*1038 vs 1.79*10308).
On all (basically) hardware you'll be running Ignition on, there's no speed/memory/storage advantage to using float over double, so there's not really any advantage there. It is good to keep the same binary representation if you're expecting to manipulate values in Ignition and then send them back to a PLC that's limited to float, though, to avoid confusing rounding/loss of precision errors.
Like I said, I've been using almost exclusively doubles for my tag types as REALs from PLCs. This includes values that I'm reading and writing. I've not run in to any issues with it.
Seems like you're saying I'd only run into issues at low resolution, or with those extremely large numbers? (what do you mean by low resolution?)
For instance, 0.1 cannot be exactly represented by either float or double.
So if you have a double that's as close to 0.1 as possible:
And then you convert it to a float:
And then take that back to double:
You've lost information. It's way down in the decimals, but it's still lost specificity. The whole point if IEEE-754 is a pragmatic tradeoff that's mostly suitable for "human-scale" values, so as long as you don't particularly care about that precision, and you're not dealing with values way out at the boundaries, it's probably fine. Just something to be aware of.
Thanks for the info. Since everything in the PLC is a float anyway, I'll probably start using that from now on, but it's definitely not worth it to make all those changes retroactively. Like you said before
That's why I had been basically exclusively using Double in the past.
All that said, back to the original question. In most human-scale cases, binding a float to the double value of the numeric text input will not matter, and going forward I'll just use float so that point is moot.
However, the question remains for binding integer values to the float value prop. Obviously, you'll lose everything beyond the decimal to truncation, but since we have the number format string prop, I can usually strictly show only whole values for integer tags anyway, and truncating the decimal if a user tries to enter it is probably the behavior I want as well.
For human scale, yes, almost certainly.
Things get extra confusing in Perspective in particular, because Javascript doesn't have an integer type (pedants: don't bring up BigInt) - every number in JS is a double-precision floating point: Number - JavaScript | MDN
So an "integer" on the Java side/in the tag system/on the gateway will always end up "rounding" when it's displayed in Perspective, and rounding back when it makes it into the backend. In practice this isn't really a problem, because, again, human-scale numbers, but it's also something to be aware of as a potential source of problems.