Not sure what you mean but you can define a visu initialization program and call it once at the visu initialization step. Look in the Visualization Manager there is a possibility to define such a program.
Did you found a solution?
I found a way to do it: You can use, for example, the text variable property of any visualization element and call a function in it. Example: Write a test POU as a function (FUN), like MyTestFun which need a boolean Variable as an input value. Now write into the text variable property: MyTestFun(bBooleanValue) Thats it. The function is called at each visu_task cycle.
I found out that the Codesys simulation mode is not good to measure performance. As soon as I upload the code onto the hardware PLC I can see that my visu-task needs around 60 ms to complete. I'm wondering if there is a possibility to find out which visualization/visualization element takes a lot of computing time? Then I would look for ways to decrease the long computing time.
I found out that the Codesys simulation mode is not good to measure performance. As soon as I upload the code onto the hardware PLC I can see that my visu-task needs around 60 ms to complete. I'm wondering if there is a possibility to find out which visualization/visualization element takes a lot of computing time?
Im looking for a way to implement ST-code into the visualization element without creating a helper POU or method in my device/application tree. Like visualization properties are evaluated at each VISU_TASK cycle I want to be able to create own ST code which interacts with the visualization interface variables. To be more specific I want to have a property which executes user defined ST-code at each VISU_TASK cycle exactly like its already possible for Input Configuration on various mouse and dialog...
You could work around this problem by implementing some sort of "state machine". Each dialog sets a boolean variable when they are closed so you know which dialog was closed. Then you can react to this accordingly.
You could work around this problem by implementing some sort of "state machine". Each dialog sets a boolean variable so you know which dialog was closed. Then you can react to this accordingly.