Foregn language letters in system.gui.confirm

This might be the same result as this post:

The Norwegian letters Æ,Ø Å, are working everywhere in ingition, except in the messagebox and confirm dialogs.

Anyone know how to workaround this so that the native letters are shown.

To be precise… This code:

if system.gui.confirm("Ønsker du virkerlig å laste ned denne resepten til PLS?","Er du sikker?"):

Gives this result:
2019-10-29%2013_44_23-Window

Have you tried prefixing those strings with u?

if system.gui.confirm(u"Ønsker du virkerlig å laste ned denne resepten til PLS?", u"Er du sikker?"):

Yes, you might want to make sure the strings are in unicode.

Like Kevin and RadicalRumin said, python’s handling of anything outside of a-z0-9 is not intuitive – you need to prefix your string with a u to indicate that it’s a unicode string.

The other post is different, in that it’s referring to the Yes / No boxes. Those are not translatable for reasons beyond our control, so you you need those to be in Norwegian you will need to make your own popup window and deal with the button presses yourself.

That did it :blush:

1 Like

Hi again,
Do you have any tips if the native letters are stored in the PLC? See my screenshots below:

I am trying to show these in a normal label in Vision:

Do you know what symbol that is? It could be an issue with the font not having that character. But it is more likely a side effect of different encodings for PLC and Ignition. Not sure if that is adjustable.

It is the character ø.

This is the Rockwell PlantPax library in the PLC, and due to the Norwegian law (machine directive). All machines must have the native (norwegian) language for all operational purposes.

So I really need these letters converted/translated correctly… Hope someone have some solution for this. The application is kind of heavy allready, and the PlantPAx library has strings everywhere (fetched from the PLC). So I really dont want to run a script everytime I am to display a string.

But if thats the only way, then I dont really have a choice… :thinking:

if you put repr() or hex() around the value you get from the plc what does it get?
if its contains fffd on the location of the � you probably cant turn to back from the gateway side…

Since 8.1.1 the Logix driver will use UTF-8 encoding when reading and writing String tags. You still have to manage to actually get the string bytes encoded with UTF-8 in the PLC program somehow if you aren’t writing the Strings from Ignition.

2 Likes

Is it too hard to do the strings in Ignition, get away from the PLC strings?

That’s one reason I don’t use PlantPax, it’s way too bloated. We started with PlantPax, but stripped out all of the unnecessary items. Just a thought.

1 Like

For us we need to keep PlantPAx as-is. But it might be a better fit for some people I guess…

Some customers allready have a plantpax system before we come into the picture. And its nice to have a HMI library that works on all plants on a general basis. Also I think there are some other valuable aspects for end customers, like having rockwell supported PLC code at your plant.

Its also the documentation part. One can use the Rockwell documentation if you make them 1-1.

Out of curiosity, what PlantPAx version are you running?

Thanks to you and everyone in this thread.

Like you said, if I set the values from Ignition then the native letters appear normal. Kind of sloppy of me not trying that first.

Then the key is not to use Studio 5000 while setting strings in the PLC.

1 Like

I’m not technically using a specific version, since what I have just uses bits and pieces. But, the latest version I have that I reference is 4.10.01.

I do agree that a 1:1 setup is nice, but we typically do clean installs, so no need. One example, PlantPax has around 12 AOIs related to a motor. They get very specific to drives, for example. We have 1 and it will work for everything, including drives. I like your point on 1:1, but I also like easy to maintain and implement.

I actually haven’t used 4.1 myself, but I get your point. I mean 12 AOI’s for motor variants sound strange. I wish the programmers would have collapsed some objects using configuration parameters instead.

So what, 95% of it is gone? :joy:

1 Like