Edition of text system (tmx file) during runtime?

Ask Questions
,
1

Hi community,

I’m wondering if it’s possible to edit a tmx file at runtime.
For example, I want to change the English translation of a text displayed in my mappView HMI at runtime?

Regards,
Florent

2

Hi Florent,

I cannot say for sure, but I can’t find any information on this so my guess would be that there is not an easy way to modify these files at runtime.

However, I’d like to understand why you want to modify the tmx file. There are two scenarios I can think of:

  1. You want to change the text of an item to another, predefined text. In this case, you can use text snippets (See: B&R Online Help (br-automation.com))
  2. You want to create a string at runtime and use that on your HMI. You can do this by binding a string to a widget instead of a localized text.

Can you please elaborate on what you want to do? Perhaps we can find a good solution for you.

2 Likes
3

Hi Marcus,

Thanks for your reply, yes I know that my question isn’t precise.

To give you more details about what I want to do and why I want do it:

In our mappView HMI we have an explorer of every recipe parameters. Recipe parameters are categorized :

  • by equipement type (Axis, Robots, Electrovalves…), thoses parameters have a Name using localized text unmodified by the automation engineer, they are part of a programming standard. In the image below in mappView this is a textOutput for rendering tmx localized.

    image
    image616×502 43.1 KB

  • by some custom predefined parameters (DINT, REAL, BOOL, STRING), thoses parameters are custom depending on the machine, Automation Engineer can enable and use them directly using HMI. They all have predefined String Name("To define {DATATYPE} {INDEX}) not defined as localized text. This Name can be edited directly on HMI, but it will not be localizable.

    image
    image649×584 54 KB

My problem is on custom predefined parameters, how we can localized this Name without any action on the Tmx file itself. Our recipe management is based on the HMI and during runtime.

One of the solution I’ve found but in my point of view it’s not efficient, is to predefined in specific tmx file all those parameters Name that are customizable and Automation Engineer need to edit this file for the corresponding parameters, then transfer this modification.

image
image622×598 54.3 KB

FYI : Our mappView application is massive and compiling this is a bit long to do. And compilation time is time losing for Automation Engineers efficiency.

So that’s why I’m asking if there is any possibility to edit text system file at runtime!

Note : If mappView “Language” service could do this it would be perfect, currently I see that this “Language” service can only load and get texts from Text System. A custom widget could be develop to edit Text System file at runtime

I hope that more clear for you ! Don’t hesitate if you have any more questions !

Regards,
Florent

4

I think I understand. You have text fields that you edit at runtime. You want to automatically translate those text fields when the mappView language changes. To do this, you can either

  1. Define every possible item and translation in the tmx files at compile time, or
  2. Define the items you need and their translations at runtime and store those somewhere

Am I understanding correctly?

I have a couple of workaround ideas that may help. The first idea is to make your own text database at runtime using process variables. You would have an array of customizable recipe items. Each element of the array is a structure which contains:

  • Item ID
  • Value in Language A
  • Value in Language B
  • and so on…

You can then use the clientInfo.languageId system session variable to figure out the language that’s set in mappView, bind that session variable to an OpcUa variable, and run the code necessary to choose the correct structure values at runtime. An important caveat of this solution is that the chosen Language is a Session variable. This means that if you have multiple instances of the visualization open, you can have multiple languages. This solution would work best if you only use one language at a time. If you intend to have multiple, you could probably create a similar solution with eventbindings and session variables, but it would be very complex.

Another idea is to edit the tmx files before the project is compiled so that they have only the items you need. You mentioned that you found a workaround by including every possible value within your tmx files, but that this increases compile time quite a bit. If you already have an all-inclusive list, you could write a python script which edits the project file to delete all of the unused items before a build. Of course this means you’d need a way to determine which items those are, but if you are able to do that this would allow you to decrease your compile time while also using the tmx files.

Let me know what you think, or if I’m not understanding correctly.