Pyautogui automation - Identify waiting time issue - automation

I am trying to automate a task with pyautogui. After a click program starts loading for few second and this time varies every time. Th script has to wait for that time to perform next operation/click. I was thinking to take the screenshot but in screenshot mouse cursor is not showing and loading is shown on the cursor itself. what could be the best possible way to identify this loading time and stop the script for that seconds before performing next instructions.

You provided vague details, but I'll try to provide a way given what I understood.
So basically when you click, a program starts loading, and you want to find out when the program finished loading so you can execute the next part of the script?
If the program was gui based, I'm pretty sure, there are pixel changes before loading and after loading, you could for example use pyautogui.pixelMatchesColor(x, y, (R, G, B)) on a loop, to check whether a pixel in the program has changed, this could mean that the program finished loading.

Related

Jitbit Macro Recorder - IF Image statement, why it is not waiting until the image appears?

I am using Jitbit MacroRecorder and it is a really helpful tool. The problem is this: By using the IF image found feature, I want the program to execute 2 sequential commands as soon as the image I selected on my screen appears. However, the program is putting too much load on the CPU by running thousands of times until the IF statement is true. What I want is for the program to WAIT until the image in the IF image found statement appears on the screen, that is, not to run thousands of times.
My simple code
The only way for the program to know when the image appears is to continuously "scan" the screen until it sees it. You may be able to use the image NOT found feature inside a loop with a delay. You would look for the image, and if not found, delay a second, and then look for it again. The tradeoff is you will have that delay in there which will keep your program from running the following commands immediately.

Is there a method for script file loading control in labview?

first, I cannot attach my vi files, sorry. I'm not allowed, but I can attach snippets.
I've got a vi that opens and executes functions from a script file, and I'd like to be able to continuously click a button to reload the script file without having to restart the program. Currently the script file commands sit outside my main while loop and and uses a case statement to put the system in idle mode (manual control) when the button is not depressed before launching the program, or if it is, it will instantly open a dialog box looking for a script file upon program launch. I'd like to be able to open a script file numerous times during the execution of my program, but don't fully understand how, and this may be my own misunderstanding of what's going on with the code if I move it inside the main while loop. how is this best accomplished?
If you put your code outside of the loop, it is only executed once (very important: "dataflow"). You need to put the code into a loop to execute it multiple times.
You can insert the vi-snippet into your vi by drag&drop.
My vi contains two different options. You can change the vi as you need it, my vi is incomplete. I inserted a simple 2D-Array because I'm not sure if the vi you use after building the path is selfmade or given by LabVIEW.
For both options you should let the code run in some kind of state machine and use an Event Structure (I think you already implemented your program this way since you wrote about a main loop).
Version 1:
Everytime you click the button, the event is triggered and the code inside the event structure is executed.
Version 2:
Here you set a boolean if the button is pressed and handle the event with that value.
Since you wrote that you already have a main while loop, this option might be better four you. The first loop would be your main-loop, second one would be the loop in Version 2. You just need to add another case for the script to be loaded in.
VI:
I hope this is helpful for your problem.
Feel free to ask if you need more help or if you have any questions :)

Google Colab: What does a spinning play button with broken line mean?

Recently, I have seen the play button (the one to execute the cell) will have a spinning state with broken line as border and staying like this for a long time. But eventually, the line will turn solid and the thing will execute relatively fast after that. I would like to understand what the "broken" boundary mean? It seems to me it just hangs there waiting for something before actually running any code.
See image attach on that play button.
The spinning dashed line means the execution of the cell is queued behind an earlier execution.
(If you haven't yet executed a cell, it's likely that the backend is blocked by attempting to generate a completion or objection inspection. These should finish within a few seconds.)

Event-case management in while-loop

If I put the blocks showed in the picture in a while-loop everything fail, fo example the stop button does not working!
Someone could explain to me how use events correctly?
thanks
Also try to avoid coercion dots (small red dots near some blocks like add) the data type is changed dynamically (I32 to double) but it is not efficient and the convention in LabVIEW is to change the data type mostly manually.
You have not connected the timeout terminal.
How it always waits for an event and will not allow you to stop the loop. As it does not iterate, it waits.
To stop the loop you should specify Stop button Event, so your loop will iterate upon clicking on stop and you will be able to stop it. OR you can just specify timeout let say 100 ms and Loop will iterate on timeout case once every 100ms, even there is no event.
The other answers tell you how to patch your code so that your current architecture continues working. But that architecture is fundamentally flawed if your application gets larger -- you're going to waste lots of CPU redrawing needlessly and you're going to end up with lags in your UI. A proper LV separation of business logic from graphics logic would look like the image shown below. This image is a LV clip from LV 2015, meaning if you save the image to disk and then drop it directly onto LV 2015 or later, the code will just drop directly. Sorry, I don't have an earlier version of LV with me at the moment so I can't give you a clip for a previous version, but the code below should work all the way back to LV 6.1 (circa 2001a.d.) if you recode it.

How can Sikuli be used to wait for a button for a long time, with perhaps some maintenance task in between?

I have a webpage where I am waiting for a button to appear, and when it appears I would like to click it. The button is on a timer and may take as long as an hour to appear. Also, if the button takes longer than a certain length of time to appear, I'd like to move the mouse (otherwise the website will log me out automatically).
So, to wait for a button to appear I devised this Sikuli script:
button = "button.png"
while(1):
if exists(button):
print("found it")
click(button)
break
else:
print("wait longer")
wait(button,30*60)
# do a regular task
print "all done!"
The above does not seem to be functional. If the button is on screen, the script will find it... However, if it has to wait it will simply time out quickly with a FindFailed exception (on the click() even though the button does not exist on screen). I considered writing a handler, but seems like overkill.
What am I doing wrong and what is the best way to wait a long period for a visual event like this?
Some other thoughts for you...
while(1):
wait(Button, 30*60) # This will spinlock for 30 minutes for the button to appear
if exists(Button):
hover(Button) # Debug statement allowing user to see what Sikuli has matched to
click (Button)
else:
mouseMove(Location(50,100))
mouseMove(Location(50,200))
Links:
wait
mouse movement link
Location
Maybe Sikuli recognizes something that looks quite your button, and tries to click it.
If you right click in the IDE your button pattern, you can fine tune the tolerance level for recognition. Try to cut the image exactly around your button and increase the value to be more precise.
I suggest you to read this tutorial
http://doc.sikuli.org/tutorials/surveillance/surveillance.html
and to set up a event handler to manage your button when it appears
http://doc.sikuli.org/region.html#Region.onAppear
http://doc.sikuli.org/region.html#observingvisualeventsinaregion
It is not much code to write.
You can get a nice example with full source code in Sikuli's Blog here
http://sikuli.org/blog/2011/08/15/sikuli-plays-angry-birds-on-google-games/
I think you can just set up your handlers and go with
observe(FOREVER)
If you want sikuli to do stuff while your waiting for an image i would use the onAppear(pic, function) and observe(FOREVER, true) methods this is how it works
event = Sikuli.event
def function(event):
click(yourButton.png)
onAppear(picYourWaitingFor.png, function)
observe(FOREVER, true)
basically what this does is onAppear will continuously scan the screen for picYourWaitingFor.png. sikuli continues execution after words so it's scanning while its working. on the appearance of said pic it will jump to the function you put down as the second parameter of onAppear.
I have this same issue as described. Its not about waiting forever. And Observe won't work either, because that does watch forever. Think about wanting to check for event only for a certain period of time say 60 seconds. If it doesn't occur, move on. This could be happening in a specific series of events. If the image doesn't appear in the 60 seconds, move on to do another series.
wait(image,60)
...will crash after 60 seconds if it doesn't find the image, which isn't what is wanted at all in my case.
So I did something like this:
attempt = 1
count=0
while attempt:
if exists(image):
attempt=0
else:
count=count+1
if count>60:
attempt=0
else:
wait(1)
Probably a better way and doesn't give an exact time, but approach doesn't crash the script.
You could also try: except it.. Should be shorter.