Best practices for scalable UDTs and Template Screens with OPC UA?

[kjellMenu]

Hi everyone,

I am currently researching FUXA for my Master's thesis to evaluate if a company can integrate it as a replacement for their current HMI. During my scalability testing, I ran into a roadblock regarding User Defined Types (UDTs) and Template screens.

My Setup & The Problem

I have a single OPC UA server connection where all my tags arrive, including the UDT tags.

• Each motor is structured via an index, for example: UDT Veld.Motor[0], UDT Veld.Motor[1], etc.
• I want to bind a specific motor to a single Template screen dynamically.

Based on my research, I found two potential workarounds, but neither feels scalable for a production environment:

1. Separate Target Devices: Creating one target device per motor (e.g., 100 motors = 100 target devices). This seems highly inefficient for a large project.
2. Placeholders: Creating placeholders and manually coupling the tags afterward. This completely defeats the automated purpose of a template screen.

My Question

Is there a native way to dynamically bind tags to a template based on the tag name structure (e.g., passing the motor index [x] as a parameter to the template view)?

If this feature does not exist natively, what is the best approach to achieve this? Should I look into writing a custom script to handle the dynamic tag prefix/suffix injection, or is there a better architecture within FUXA that I missed?

Any guidance or examples would be greatly appreciated!

[kjellMenu]

Hi everyone,

I wanted to share an update on how I managed to work around this scalability issue. I used OpenAI Codex to modify the frontend runtime component (client/src/app/fuxa-view/fuxa-view.component.ts) to intercept and resolve structured tag paths dynamically when a page loads.

It successfully proves the concept and gets the job done for my scalability testing.

How the Workaround Works

• Dynamic Interception: In the template view, I format tag names using a placeholder token prefixed with an @ symbol to pass validation (e.g., @UDT Veld.Motor[{index}].Status).
• Index Resolution: Before standard placeholder handling occurs, a new function applyIndexedTagMapping() strips the @, reads the target index number, and injects it into the string (resolving to UDT Veld.Motor[0].Status).
• Database Mapping: The code then searches FUXA's internal tag configuration by name/address to map the temporary template binding directly to the concrete internal FUXA Tag ID.
• Triggering the Index: Currently, I use a global internal server tag called Index. Before navigating, a button sets this tag value (e.g., 0), and loadPage() reads it to render the view. (Note: The code is also architected to accept an explicit templateIndex parameter passed directly via page navigation, which avoids global tag conflicts).

This proof of concept works well enough for my testing. However, I would still highly appreciate it if anyone could let me know if there is already a better, built-in native feature for this that I might have completely overlooked.

[unocelli]

Hi @kjellMenu Thanks for sharing this. The use case is definitely interesting.

Before evaluating the approach, could you please share the actual code, for example as a draft PR or a patch? It would make it much easier to understand how it integrates with the existing runtime and placeholder mechanism.

[kjellMenu]

Hi @unocelli

As requested, I have created a draft pull request containing the experimental code here: #2508

Please note that this is strictly a proof of concept designed to validate the architectural approach for my Master's thesis testing. It focuses entirely on demonstrating the functional viability of dynamic tag resolution via the "open page" command, so it does not include the extensive error handling or deep framework integration required for a production-ready feature.

Feel free to take a look at the runtime approach whenever you have some time!