Hi @Thijs_V,
When it comes image processing - we need high computatinal power. When the flow automation is based on the capturing and processing image - you need leave some rooms for that processin, need to accept noise! But we can minimize the processing capactiy we are a bit carefule.
One of the best suggestions I had on this - if it is possible - run PAD flows on dedicated automation machines or virtual machines to isolate CPU load from your daily work laptop, further if possible in attended mode! SOLVED? No, not for your case.
The root cause:
The “Wait for image” action continuously scans specified image. This is done via frequent screen captures and pixel comparisons, which are CPU-intensive. It's really running on the backround means its consuming CPU! It still actively polls for the image, consuming resources even if the user is not interacting with the machine.
Preventive measures with economical strategies:
1. Avoind unncessary image regions selection (narrow done screen area) - as minumum as possible.
2. Set longer timeout values so the action doesn’t poll excessively.
3. Add delays or increase the interval between image checks to reduce CPU load
4. Identify and use distinctive images to speed up matching.
5. Use event-driven triggers or conditions rather than continuous polling.
6. Good one to me - If we can use very low tolerance (0 to 1 to be exact match) values might cause longer wait times or more retries, indirectly increasing CPU usage over time. If the tolerance value is 10 or above (you are trying to have every match) its expensive.
I am sure some clues I tried to give. If these clues help to resolve the issue brought you by here, please don't forget to check the box Does this answer your question? At the same time, I am pretty sure you have liked the response!
