Hi Folks

Here my (so far) errata to the yesterday released Update for Unified V19.3

triggerDataSet  (undokumented api change):


The addressing was wrong in the beginning (came with V19.2) as it didn’t reflect the tag structure, but it would be nice to get informed of such changes. Its not fun to edit 400 faceplates!
BTW. Where is the faceplate functionality in Openness?
Waiting for 2 years on that, would be an 20min job to do that with a python script!

Given a faceplate Interface with structure: “elem1.elem2.elem3”
Trigger tag: “elem1.elem2.elem3”
Pre Upd3 addressing: “triggerDataSet("elem3").Value”
Post Upd3 addressing: “triggerDataSet("elem1.elem2.elem3").Value”

Global Scripts (Bug):

The global script editor lost its Tag awareness completely in some cases.
Bug showed with an internal variable, is reproducible in my project, but does not trigger on every compile run. Mostly happens if a global script is imported in a faceplate.
When releasing the importing faceplate the compiler cant find the tags that are used in the imported script and throws an “Object not found” error.
Sometimes the same tag in 2 separate script in the same global lib one is ok in one script and throws an error in the other.

How it should work:
Tags(“aTag”).Read()

Workaround in Upd3 to get your project compiled:
let mytag = “aTag”;
Tags(myTag).Read()

Faceplates Wrong Rendering of Text elements

happens on Microsoft Edge - Version 115.0.1901.188 (Official build) (64-bit)

Text gets rendered below its desired position on a random chance.
Position changes when reloading the screen or switching between screens.
No problems on MTP1200!

I really don't have the time to convince 1.lvl. support and create endless test projects for them.
i do support requests for problems i cant solve myself.
A not working dynamic listBox that got fixed with that update for example.
What i did i sent the link to this post to the Vienna Siemens Department in charge of unified though.
What they do with this info is out of my bounds.

greets Peter

Hi Stefan,

on the contrary, this is exactly where developers (like myself) look to find information and workarounds. Issues reported via SR's are kept secret from developers so we all waste our time discovering the same problems.

Thank you h_p_l for publishing the issue and the workaround.

Stefan Arcularius

However, the chances of a responsible developer reading your post are close to zero. Therefore, in order to get WinCC Unified changed, you should report all your findings to Siemens by creating a support request. Your request will then lead to a bug that will be addressed by the development team.