Slow_script

[Hardware_Tester]

I edited a script which should perform the same operation on 10 Windows. There are the open windows HMI600 - P4LT_1.et6 to HMI600 - P4LT_10.et6 and each one has a child window which is called Firmware Download

//downTime for WaitWindowOpen> function
Let>WW_downTime=10
//Visible window Only for all functions over windows
Let>WF_TYPE=2
//create variable "session" because of the error > could not find label %session%.et6*
let>session=0

Gosub>resetHMI
Let>session=HMI600 - P4LT_1
Gosub>resetHMI
Let>session=HMI600 - P4LT_2
Gosub>resetHMI
Let>session=HMI600 - P4LT_3
Gosub>resetHMI
Let>session=HMI600 - P4LT_4
Gosub>resetHMI
Let>session=HMI600 - P4LT_5
Gosub>resetHMI
Let>session=HMI600 - P4LT_6
Gosub>resetHMI
Let>session=HMI600 - P4LT_7
Gosub>resetHMI
Let>session=HMI600 - P4LT_8
Gosub>resetHMI
Let>session=HMI600 - P4LT_9
Gosub>resetHMI
Let>session=HMI600 - P4LT_10
goto>END

SRT>resetHMI
Let>resetFocus=%session%
Concat>resetFocus,.et6*
SetFocus>%resetFocus%
SetFocus>Firmware *
press tab*4
press enter
End>resetHMI

Label>END

This script is a cut off with the only variables and code which influences the behavior, e.g it reacts exactly the same way as the original part of the script.

How it should work:
Focus window 1 and it's child window, perform the action and jump immediately to the next. The starting arragement is the window 1 is at the bottom of the open windows and so on until window 10.

How it actually works:
It starts the action at child window 10 but focus on window 1, then action on child window 1 and focus on 2 and so on until 9 where it performs the action at the end. This alone is not a tragedy, because no one is left out. BUT it waits for the further action until the child window before is no longer busy, instead of immediately going ahead. So the action durates 9 time
longer as it could. So instead of 30 seconds it takes 5 minutes.

[Hardware_Tester]

Does no one knows the cause of this strange behavior?

The code alone is really short and I think, it has something to do with the setfocus.


SRT>resetHMI
Let>resetFocus=%session%
Concat>resetFocus,.et6*
SetFocus>%resetFocus%
SetFocus>Firmware *
press tab*4
press enter
End>resetHMI

[Marcus Tettmar]

Without seeing this in action and having the software you're automating it is impossible to guess at what the problem could be. Have you stepped through this with the debugger?

[JRL]

Just a shot in the dark...

Anything change if you put a Let>WF_TYPE=3 just in front of the SetFocus>Firmware *? You probably want to change WF_TYPE back to 2 immediately following.

SRT>resetHMI
Let>resetFocus=%session%
Concat>resetFocus,.et6*
SetFocus>%resetFocus%
Let>WF_TYPE=3
SetFocus>Firmware *
press tab*4
press enter
Let>WF_TYPE=2
End>resetHMI


Hope this helps,
Dick

[Hardware_Tester]

Ok, now I tryed it out in several ways. It is not the code, it is the Runtime itsself. When a window, which is focused gets busy (when you go with the mouse over it, a hourglass appears) msched gets also busy.

Example:

Let>k=1
Label>start
Add>k,1
if>kwindowsaction
//Get window busy
END>windowsaction

Label>end

[Hardware_Tester]

I now solved the problem by moving the part of the script which makes the other application busy to a new exe and by assigning all variables a constand value. And then creating a exe for each case with its values. In the loop I call now start these exe's to make the same action with no delay.

Example:


Let>k=1
Label>windowsaction
Add>k,1
concat>busypath,%k%
concat>busypath,.exe
run program>busypath
if>kend


*remark* This is in my eyes a bug in the tool, and with my workaround it is prooved that the code would work but doesn't do when using the tool in a normal way - e.g in a subroutine. The workaround with a external exe is quite bad, because of its memory consumption (additional 50MB's) and the complicated way to update it - 11 instead of 1 exe is quite bad.