Hey Ignition Community,
Got a weird issue. When reading REALs from AB PLC, I have loads of extra numerals coming along with it. here's some screenshots. I have no issues with memory tags, only OPC.
Hey Ignition Community,
Got a weird issue. When reading REALs from AB PLC, I have loads of extra numerals coming along with it. here's some screenshots. I have no issues with memory tags, only OPC.
It's not extra, see IEEE-754 Floating Point Converter and plug in 20.1
.
makes sense. Any small scripts we can run to format the value?
Use the FormatString
property on the tag.
If displaying in a regular label, use numberFormat()
in an expression and point it at that property on the tag.
For numeric labels, bind the label's numberFormatPattern
to that tag property.
If this is actually an issue for you outside the tag browser you should use a number/format string at the point of display.
I'm not displaying the value. Its a sequence number that I'm trying to use as a key for a DB query in a transaction group.
so on value changed I run the stored procedure and get all info for seq 20.1. However, the stored procedure is not running because my 20.1 is actually 20.100000381.
Trying yo format in the Value changes script, but im getting a "TypeError: 'float' object is not callable" now
Using a real/float for that is kind of insane...
You can make an expression tag that uses the numberFormat
expression to and then reference the expression tag.
If it's a sequence number, then it really should be a string, even if it contains only digits.
Assuming the two things are incrementing counts, what are you going to do if you get to run 10 of sequence 20? 20.10
is exactly numerically equivalent to 20.1
.
blame AB for not giving me better data types.
not sure how to do sequence numbers without decimals
Maybe what you're calling a sequence number is different than what I think a sequence number is... never seen a "sequence number" be a decimal type. It's always a sequentially incrementing integer type.
great question. I inherited this project. We currently dont have a seq that goes past xx.9
so its currently 10.0, 10.1, 10.2, then 11.0 so on and so forth.
it depends on what's being build. the whole number is for a specific part that's going on the product, the decimal places are individual actions for the one part.
I very well may just make these all INTs and start at 100. Minor takes would be 101 or something.
in the mean time, I made the data type on the Ignition tag a string. Seems to be working. Going forward, im going to scrap this idea these guys had about using reals for sequence, back to ints.
I am actually intrigued, do they check the currently running sequence value with LIMIT
blocks? Surely the EQU
and NEQ
would cause issues if you specified static comparisons with a direct decimal value: 20.1 != 20.100000381
not sure how AB does it, but all that is filtered out. Just shows as 20.1 in the PLC.
AB just rounds to 6 or 7 significant digits for 32-bit REAL. That hides trailing non-significant digits. For 64-bit LREAL (double in java), there can be ~16 significant digits, so rounding to to 6 or 7 actually throws away possibly valid decimal places.
AB isn't magically eliminating the fundamental inaccuracy of floating point fractions that have any denominator other than powers of two.