HMI design software that expects a period decimal separator rejects floating point entries typed under comma-decimal regional formats such as Serbian, German or Belgian. Confirm the trigger with a before-and-after test on a project copy: repeat the same edit after switching only the workstation's regional format to the US convention. Finish the edit under that format, restore your original format, and verify every changed value.
When HMI design software throws a floating point exception every time you touch a numeric field, look at the workstation's regional format before you suspect the project. Formats such as Serbian, German and Belgian write 12.5 as 12,5, with the comma and the period swapped against the US convention, and design software that expects US separators rejects the comma form outright. The fix that works today is a controlled locale swap on one machine: prove the decimal comma is the trigger on a project copy, switch the regional format to the US convention, finish the edit, restore your own format and verify every value before download. This article gives you the test, the arithmetic to check values against, and the reproduction package that pushes the vendor toward a permanent fix.
Why does HMI design software throw a floating point exception on European regional settings?
The design software converts each typed value into a binary floating point number with fixed separators, a period for decimals and a comma for thousands, so an entry that arrives with those two characters swapped fails the conversion and the parser raises the floating point exception.
The software expects those separators no matter which format the workstation uses. Serbian, German, Belgian and similar comma-decimal formats put the two characters in the opposite places, and the parser treats the comma form as malformed. The exception is how that failure reaches you. Integer entries such as 125 carry no separator, which is why the fault stays on floating point fields.
| Regional format | Decimal separator | Thousands separator | Twelve and a half |
|---|---|---|---|
| Serbian, German, Belgian and similar comma-decimal formats | , | . | 12,5 |
| US convention | . | , | 12.5 |
Both rows describe the same number. Only the characters differ, and the parser accepts one row only. That single mismatch is the whole fault, and it explains why a workstation change fixes it while a project rebuild fixes nothing.
Which symptoms point to regional settings and which point elsewhere?
An exception that hits only floating point entries, only on workstations using comma-decimal formats, tracks the regional setting; exceptions that persist under the US convention, or display faults that appear on the panel itself, point to other causes with their own tests.
Sort the fault by where it appears:
- An exception on every floating point edit, on a workstation set to a comma-decimal format, with the identical operation succeeding under the US convention, points at the regional format. Confirm it with the test in the next section.
- An exception that keeps appearing under the US convention points somewhere else: capture the value, the operation and the software version, and use the reproduction package in the last section.
- Huge positive numbers on the panel where a moderate value belongs point at a signed data format mismatch between panel and controller; set the signed decimal data format and the numbers come back to scale.
- Correct digits with the decimal point in the wrong place on the panel point at decimal placement from the controller tag, which moving an HMI numeric entry decimal point from a PLC tag fixes at the tag.
- A project that fails to restore after a reboot belongs to a different fault family with its own article.
How do I confirm the decimal comma is the trigger before touching the real project?
Run the before-and-after test on a copy of the project: record the current regional format, repeat one harmless floating point edit, switch only the workstation's regional format to the US convention, repeat the identical edit and compare the two results.
Work on a copy so the production project is never the test bench.
- Copy the project file and open only the copy. If the master lives on the panel, read an HMI project from the panel before editing and archive it before anything else.
- Note the workstation's current regional format in the region settings before you change anything, so you can restore it later.
- Pick one floating point edit that caused the exception and note the intended value with its unit.
- Repeat that edit under the current format. Record the result and the exact exception text.
- Close the software, switch only the regional format to the US convention in the operating system's region settings, and reopen.
- Repeat the identical edit on the identical copy, typing the value with a period. Record the result.
- Restore the original format, reopen, and repeat the edit once more.
The decision falls out of the three results. Failure under the comma format, success under the US convention and failure again after restoring means the decimal comma is the trigger and the workaround is safe to apply. The same edit failing under the US convention means the regional format is cleared, and the reproduction package in the last section is the next step.
What does the before-and-after example look like with real numbers?
Enter a 96.5 °C oven setpoint on a workstation set to the German format: typing 96,5 raises the floating point exception, typing 96.5 after the regional format switches to the US convention succeeds, and the exception returns when the German format is restored, which confirms the decimal comma.
Walk the scenario end to end:
- Pass 1, German format: you type 96,5 into the setpoint field. The conversion expects a period, the comma is rejected, and the field raises the floating point exception. Nothing is saved.
- Pass 2, US convention: same copy, same field, value typed as 96.5. The field accepts the entry and reads back 96.5 °C.
- Pass 3, German format restored: the exception returns on the next floating point edit.
The fault tracked the regional format in both directions, so the decimal comma is confirmed as the trigger.
Carry the same arithmetic into every edit you make under the workaround. The intended value is 96.5 °C. A readback of 965 °C means the conversion swallowed the comma as a grouping symbol and slid the digits one place: 96.5 x 10 = 965, ten times the setpoint. A readback of 96 °C means the digits after the separator were cut: 96.5 - 96 = 0.5 °C low. Both errors cost seconds to catch in the editor and can cost a shift on a running oven.
How do I switch the regional format and get back to normal afterwards?
Change the format on the one workstation that needs the edit: record the current regional format and its two separator symbols, close the design software, set the US convention in the operating system's region settings, reopen, finish the work, then restore the recorded format and reopen once more.
- Write down the current regional format: name, decimal separator, thousands separator. That note is what you restore.
- Save and close the design software before you touch any setting.
- In the operating system's region settings, choose the format that uses a period as the decimal separator and a comma as the thousands separator.
- Reopen the software, open the project copy, and finish the edits, typing every floating point value with periods.
- Save, close the software, and set the regional format back to the entry you wrote down.
- Reopen once more and read the project back under your normal format before anyone downloads it.
Recommendation: Confirm the trigger on a project copy with the before-and-after test, then finish the edit on one workstation under the US convention, restore the recorded regional format in the same session, and read back every changed value before download. If the exception still appears under the US convention, drop the locale theory and send the vendor the reproduction package instead.
How do I verify every value I edited under the temporary format?
Reopen the project after restoring your regional format and read back every value you touched: compare each against the engineering value with its unit, because a separator eaten in conversion shows up as a factor of 10 and dropped fractional digits show up as the whole part only.
Check three things before the project leaves the workstation.
Re-enter or re-read every value you touched, and give special attention to values you copied and pasted during the session. Storage precision sets a second limit: a 32-bit float carries about 7 significant decimal digits under IEEE 754 single precision, so 0.1234567 stores cleanly while 0.123456789 comes back shortened, and you should decide which digits matter before the edit. After download, look at the value on the panel and confirm the digits and the decimal position match the engineering value; if the position is wrong, that is decimal placement from the tag, covered in the symptom list above.
Keep the project off the download until the readback matches: a setpoint ten times high on a machine that heats, presses or moves is a safety problem, not a display quirk.
What do I send the vendor when I need a permanent fix?
Send the software vendor a one-page reproduction: the design software's version, the operating system's regional format, the exact value with its unit, the operation, and the full exception text, plus the one fact that matters, that the same edit succeeds after changing only the regional format.
That single comparison removes the project, the panel and the network from the equation and leaves one variable, which is what makes the report actionable for a developer.
Take the software version from the software itself, the same habit as checking the HMI firmware revision before a project transfer.
The same decimal comma mismatch is documented across plant software, and a walkthrough of decimal point and comma locale errors in a web dashboard applies the same before-and-after logic to another product class.
Shops that build screens for several countries keep one bench machine on a comma-decimal format permanently, so a separator-sensitive fault shows up at the bench, before a project reaches a panel.
Questions
Does the floating point exception damage the project file?
The exception fires while an entry is being converted, during editing, so the project file itself is usually untouched. Close the software without saving if the exception interrupted an entry, reopen the project, and compare the last values you touched against your engineering records. If the saved file reopens and every value reads back correct, the project is intact and only the workstation's regional format needs managing.
Can I replace every decimal comma in the project with a period using find and replace?
No. A global replacement rewrites every comma in the file, alarm messages and label text included, and it runs on commas that are not decimal separators at all. Edit numeric fields inside the design software one value at a time and read each one back. If the list is long, sort by screen or tag so you can show every floating point field was checked.
Why does the same number work in a text field but fail in a floating point field?
Text fields store characters, so a comma stays a comma. A floating point field converts the characters to a binary number before storing, and that conversion applies the software's expected separators. When it expects a period and meets a comma, the conversion fails and the software raises the exception, which is why labels and text entries keep working while numeric edits fail.
Should every workstation in the office stay on the US format?
No. Change the format only on the workstation that has to finish the edit, and restore each user's own format when the session ends. Teams that build screens for several countries often keep one bench machine on a comma-decimal format for good, so a separator-sensitive fault shows up at the bench before it reaches a project download.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.