I would like to report a potential bug of unwanted rounding.
I created a Datatype with internal floating variables (float 4). These variables are used to set a threshold in order to fire an alarm. On the attached file (1), we can see that the thresholds are set to a float value. This works perfectly.
But, when i modify the parent object (the datatype), all the thresholds that have been set are reset to a rounded integer value. See Capture 2.
I don’t understand why the values are rounded. The only clue I have is that we use a comma ( , ) as decimal separator.
Displaying the value in a windows shows the rounded value.
And if i use a dot instead of a comma, only the integer part of the value is saved in the Tag.
For example, if i type :
13.70 --> 13,00 is saved in the Tag (dot)
13,70 --> 13,70 is saved in the Tag (comma)
I tried replicating this issue but didn’t have success. When you say you modified the parent object, which specific setting did you modify? Also, which version of Ignition are you using?
In the parent object, I only modify the display path of a tag (in Alerting) but i think that I can modify any of the Datatype property, the “rounding” occurs when i press “Apply”.
This really seems to be a locale specific issue. I am using german language and can reproduce the problem in 7.5.2. For example a SQLTag with the value 1.8 has to be entered as “1,8” and is converted to 1.79999996E16 when i modify the parent datatype. Maybe this is related to another issue i posted before here.
My best guess is that numeric values are converted to and from String somewhere, using incosistent local settings. As 2Gi Technologie already wrote, values must be entered using a comma and are displayed with a dot instead.
We are definitely looking into the locale. Being able to work with the gateway backups will help us narrow down the problem much faster. Once something is figured out we will post to this thread letting you know what the cause and solution is to this dilemma.
I just wanted to post back here saying that this wasn’t forgotten, it’s just that we cannot reproduce this with the information given.
I have a computer in a locale that uses comma for the decimal separator. I made a UDT type with a Float4 memory tag. Then I made an instance of that UDT type. As far as I understand this issue, edits I make to the UDT type should cause the instance’s float values to round. This is not the case for me.
Can someone give me a step-by-step process to follow to reproduce this issue?
Maybe it’s better to forget the rounding problem for the nonce and start with the basic issue, that seems to be the same in many parts of the system.
The easiest way to reproduce should be a simple float tag:
With a data type it becomes a bit more interesting:
Another nice one (Using the ‘tag’ function in UDT’s is real fun ):
This screenshots where taken from 7.5.4-beta for with locale de_DE. I did not change any tag properties. Maybe the rounding problem will come up when the number format is changed in addition.
Hi,
I still have the problem of the early post.
I tag memory in a data type, when I write 12.5 (with the decimal) value is ok. When I change my data type and the tag Ignition refreshed, my values become 12 I lose the decimal.
I’am in french.
version : 7.5.3 (b1163) | 32-bit
Thank for your help.
Hi,
this is a really strange bug. When i do the same (write 12,5 to the tag and change the type) the value changes to 125,00. Maybe you can export one of your tags and i can test it on my system. I really want to solve this, because currently i need to triple check everything that deals with floats.
When i change my gateway’s locale to ‘fr_FR’ i can reproduce what 2Gi describes. Instead of modifying the value it is rounded. I think the clue to this is that the default french number format uses a space for grouping:
en_US: 123,456.00
de_DE: 123.456,00
fr_FR: 123 456,00
I think that Ignition uses some kind of string format for internal data storage and communication between gateway and designer. Somewhere in the process of parsing those strings, the gateway locale kicks in.
The only solution so far seems to be forcing java on the gateway to use ‘en’ number format.
As changing the the java locale via windows settings seems to be unpredictable (depends on java version), i added the locale to ignition.conf: wrapper.java.additional.xx=-Duser.language=en
With java seven, there is this separation between dispaly locale and format locale, so the additional parameter wrapper.java.additional.12=-Duser.language.format=en
may be necessary.
IA-Team: With the setting 'wrapper.java.additional.12=-Duser.language.format=fr (or =de) this is perfectly reproducable with java 7 on my system. If you are using java 7 and only change the locale, that may explain why you could not reproduce this.
The problem with the ‘tag(…)’ expressions above seem to be unrelated. It looks like the result of tag() is a string, so the addition is a string concatenation internally with the result parsed to a float.
When using ‘toFloat(tag(…))’, it works as expected. Is this the intended behaviour?
One additional remark: The gateway status shows a locale, but that is not the gateways locale but the locale of the client browser. This caused a lot of confusion to me. It would be a very good idea to display the locale used by the gateway in addition.
):