I have a process that loops loops through a series of tasks that have it running around an application timing how long it takes things to load. The process will go through the first iteration just fine but when it hits the second iteration it freezes. I have tested this 6 times today and it freezes at the same spot every time until eventually the Robot times out. The kooky part is that if I run the process in debug mode this does not happen. It just runs to completion like I would expect.
I found this topic in which the solution was upgrading to the latest version ā¦
But I did that last Friday. Is the problem that I built my process on an old version? Is this a written about somewhere?
Try putting required delays in the process , version 2018.1 has memory management issues ,try clearing the variables (huge data tables for example ) if they arenāt required in the process after certain steps .
I have played with the delays and that hasnāt worked yet and clearing the variables seems like a decent enough idea to free up memory so I will give that a go.
Thank you
Do you mean you run it from Studio as attended? Can you identify the activity where it gets frozen? Also, when you say āfreezesā, do you mean it never throws an error and just gets stuck, or does it throw an error and stop?
If you can show what the activity is (and activities right before it), the properties you have set for that activity, and any errors that occur, this will help anyone who tries to help solve your problem.
Itās most likely a timing issue, which can be solved by adjusting the properties of the activities.
Yes, I have been running it from studio. I suppose I could try the command line and see if there is a difference though which is probably a good idea.
Yes, I know exactly which activity it gets frozen on, itās a Type Into activity, and I tried setting up a 90 second delay prior too that event and that did not make a difference.
When I say āfreezesā I mean that the application I am interacting with goes non-responsive and UIRobot times out because it cannot find the element in the screen that it wants.
This is the the errorā¦
Type in to Last Name Tet box : Cannot find the UI element corresponding to this selector:
Now, the error makes sense because we never succeeded at these previous stepsā¦
I am assuming it is skipping over the click the Quick Inquiries button, but thinks it is successful.
Do you have āSendWindowsMessageā or āSimulateClickā checked? Sometimes those are not compatible and does the click but doesnāt actually click.
If thatās not it, then it is difficult to solve without seeing the web portal that it is interacting with. However, I can make a couple suggestions. First, I would watch it in run mode and see if it does click the button successfully, then see what the site looks likeā¦ thereās a chance it is working as intended but it just loads longer so you need to change the TimeoutMS for the TypeInto longer. If it is not clicking the button (but moves the mouse to it trying to click it), then thereās something before it that causes the website to load longer so you would need to wait until an element is found or attribute is a certain value before Click the button, so the website is in the correct state.
An alternative to this would be to place a Retry Scope around the Click and TypeInto, so when the TypeInto fails, it tries to Click the Quick Inquires button again. - I donāt know how I feel about this method without seeing how the web portal works.
I donāt know if it still is, but Debug used to run much slower than in Run mode, so at times it would be more successful, until the properties are all set for a reliable execution in Run mode.
I think the design here is important. What this process does and run through an application and do a bunch of checks (8 in total). Once it finishes those checks it loops through them again and again until the loop ending condition is met which in this case as a fixed number of iterations. This process does run through the first iteration successfully. The second one is when it freezes up and it always freezes up in the same spot (this succeeds in debug mode).
When I watch the process it does do those clicks on the buttons and I validated this because once the bot times out and stops because it cannot find the type into object, the App navigates to the page that it should navigate to after licking those buttons. It is as if the Bot and the App are competeing for resources that are not an issue if ran in debug.
I double checked for simulated click being set and it was not thought simulated type was set for the type into activity so I unchecked it to see if that made an impact but it did not.
As a note, if I stop the bot immediately after it does its button clicks, the next page of the Application loads up fine which would seem to mean that something the bot is doing is break itself, but that could be wrong.
I put a retry scope in there to retry the Type Into but it just retries 3 times and then the bot times out.
I really think someone needs to actually examine both your workflow and the web application you are trying to automate in order to figure out a solution. This is because you say it works in Debug but not in Run mode. I feel like itās how the application loads after you click the button. Make sure you have set a large enough TimeoutMS property on the TypeInto where it fails, so it gives it enough time to look for it. - Also, sometimes you need to change the WaitForReady to None.
Iām sure itās solvable though. To get UiPathās support I recommend using this link: Tech Support
You can also PM me but I donāt work for UiPath
I meant to do the Click inside the Retry also, so when the TypeInto fails, it tries to click the button again.
I think it is a problem with the workflow and the Application I am interacting with but I do not think it is a problem with my workflowās design and the reason I think that is that it runs through clean the first time AND it runs flawlessly in Debug mode. I could still be a design flaw in my work but it isnāt clear to me what might be causing it there.
I set the timeouts up to 5 minutes and the bot behaved as I suspected in that it froze up, the page didnāt load so the text box was unfound, the bot timedout, the page loaded.
I figured a solution though that works in this instance. I just fire up the process with a batch file and have Windows Task Scheduler run that every 5 minutes. This isnāt a solution in all cases but it does work for me here.
And yes, I agree with you that I should take this up with tech support for UiPath.
I donāt know if this is related because in my case the problem is very random and was happening today on atleast one of our robot machines, which hasnāt been a problem until now. It would act as though it clicked a link or button, however it didnāt, so the next activity failed.
My error handling takes care of this situation very smoothly and retries that section of the process, so itās not a big deal, but Iād like to iron out any random issues the best I can.
I tried changing Single click to Double click and/or adjusting the delay before to a second. I ultimately solved it by placing the Click and the next Click activity in a Retry scope with 0 delay and 3 retries, just to eliminate that random occurrence. This is kind of what I suggested with the Retry scope, but not to say that is the right solution for you.
Which is where we would have been ideally without the hiccup. Once the app goes non-responsive, I canāt interact with it until the UiRobot service dies.
I seeā¦ so something is causing the application to freeze up. You probably need someone to look at it directly, cause Iām not sure what I can suggest to get around that without playing around with it.
Yes sir. That is why it has been so puzzling for me; doubly so because it works the first time and it works all the time in Debug mode. I was going to throw process explorer at it this afternoon and see if that turned up anything.
Hi FFS2,
Sometimes a Click will not give you any error, even the button is not available and the click does not actually happen. In such case you get the error in one of following steps.
Play with āWait for readyā first. I have seen applications that make clicking happen exactly when the activity is about to timeout, set NONE in this case.
2.Then put a highlight before clicking - this may reveal the issue, this control is smarter than Click.
3.You can also put the click into āOn element appearā, which has control over Active and Visible. Do not forget to change āRepeat foreverā to False, though.
Be very careful with āOn element vanishā - what if the element disappears before you ever check it?
BR Rosen
ashokkarale
MD_Farhan1
Ajay_Mishra
postwick
Dheerendra_vishwakarma
Anil_G
chandreshsinh.jadeja
Gautham_Pattabiraman
vrdabberu
aravindbalineni123