Everytime i work with floats or ints, the gateway seems to mess up and add in one extra 0 behind the number!
At first i had it while scripting everytime i tried to read a tag it would add a 0 behind the value.
tag = 12.0
sys.tag.read = 120.0
It also happend when i tried to read it from a dataset.
I managed to work around it by writing a float conversion around every read (float(tag.read()) It is quite bothersome but i figured it was just something weird.
But now i made a custom Programmable Device Simulator with some basic instructions.
But every time i open the device to make a change i notice EVERY number in every instruction gets one extra 0 behind it even if they arent floats! If i remove the “.0” it gets a “.0” behind it next time and from then on an extra 0.
random(1, 10, true) => random(1.0, 10.0, true) => random(10.0, 100.0, true) => …
I suspect the problem lays somewhere with the regional settings. In my country we use the comma for decimal seperator “0,1” and the dot for writing a thousand “1.000”.
Still i change my pc’s settings and it did not change the problem.
This is a known issue with our programmable simulator. You are correct that the simulator page is using the locale of your Gateway. Unfortunately, there isn’t a work around for it at this point other than to set the locale on your Gateway to use decimals for formatting. I am talking with the product owners to have the issue’s priority re-evaluated.
Thanks for the quick response. Sorry i didn’t find the bug already being reported.
I did change the gateways computer settings to use a dot for decimal point but that did not help.
Did i miss something? Changing browser language also does not seem to help
If on a Windows system, the locale is applied based on the user the Ignition service is started as (by default it would be system). You may have to change the service to run as a specific user to inherit the locale.
We are using Windows and it was running on SYSTEM.
We changed the service to run on the admin user where i changed the decimal settings but that did not seem to help.
Seems ill just be simulating with integers and be sure to cast every read/write to the datasets to the right type.
wait if i do system.util.getLocale()
in the script console i get “en” which is not the Windows locale, nor of the gateway?
Is this related or is it just the standard for translations?
So changing the locale (or the date formatting in the current locale) will only change the behavior of being able to make saving the simulator program work in a reliable manner. In the following screen recording, you will see the following:
Initially my Windows system is configured to start an Ignition service as my user tester that is setup for a French locale, with French data formatting.
I display the simulator program in this context on the server itself and on my local system which has English configured for everything. You can see that both the local browser and the server browser aren’t allowing me to change the value and see it properly in the program.
I change the Data formatting for the user the service is set to use to English (American) and then restart the Ignition service.
After a restart of the Ignition service, both browsers (Gateway and remote) will allow the program to be updated properly.
For the Designer/Client, the locale is inherited from the system that starts the application and it won’t inherit it from the Gateway. As the issue you are seeing is the value is not being set correctly by the simulator itself which is only processed on the Gateway, what I showed above should resolve the issue.
That is exactly what i did. However i only changed the number formating and not the whole language format and that did not work. (I double checked it again too)
I tried another time and now changed the whole language to English and now it does work. I guess it didn’t pick up on the advanded settings. Or only changing the decimal point and seperator wasnt enough.
For some reason the designer still not using the . and , consistent however the dataset problem does seem to have resolved too, so this inconsistency is only visual and it does convert correct internally.
