for some programs we use the URCap: Remote TCP & Toolpath
ran today and yesterday into a freezing screen of the controller and couldn’t press anything on the tablet.
I could still move the cursor around the screen and the in-/outputs and the program could still be executed/was still welding.
I could even press our safe guard (which runs in a thread and will eventually use halt command to terminate the program nicely) and then use the free drive button.
When you go to Hamburger Menu > Settings > System > URCaps the Remote TCP & Toolpath has a green check mark?
If the above is OK-have to tried deactivating the URCap, and then re-installing it?
Are you using any other functions and nodes in polyscope with the Remote TCP Move command? some of the functions/nodes in polyscope are not compatible with TCP Move command. Shown here: Universal Robots - Remote TCP & Toolpath URCap FAQ
Once the above have been checked, we can move onto the next steps of assistance.
in the hamburger menu the URcaps has got a green checkmark
-the URcap has been re-installed, problem was not solved
we are not using the ‘‘remote TCP move’’ command, Toolpath move command is used.
We think the problem is related to the NC and to the amount of NC’s in the program. there is a connection between the amount of NC’s and the duration of the freeze. the freezes are happening with multiple different NC’s
The program we are using is to weld a contour on a piece of stainless steel to round the edges. For every part there is a seperate NC and there are usually about 10-20 NC’s in a single program. Every NC is the same exept for the origin of the NC.
we have not updated Polyscope to version 5.10.1 as there is a problem installing it, so we do not know if it fixes the problem.
I saw this today Out of memory Error. Could this has something to do with this? Didn’t saw anny erros in the past few weeks, but we still have a freezing screen/robot.
it took a while(graduation project in between) but thanks to @ypan, i have fixed it.
he gave some advice so i would like to share this to you for in the future.
answer @ypan :
I noticed two issues in “test program hook 2.urp”. First, it contains a Loop node under Robot Program. I am not sure if it is necessary to do so. Robot Program already represents a loop that runs forever. Is it possible to get rid of the other Loop node? Having one loop running inside another is likely to cause issues.
answer @ypan :
Second, you are using Wait nodes inside the Toolpath_MoveP node. The subprograms Start_las and Stop_las both contain a Wait node. You cannot call these subprograms under a Toolpath_MoveP node. Can you call them before and after the Toolpath_MoveP node, as shown in the example below?
the above 2 didn’t quite help me so the next step was to free up some space
we couldn’t upgrade the cobot from V5.9.3 to 5.10.1 we thougt taht it could be a memory isseu. had around 60 different programs resulting in 2700 files on it. deleted a whole bunch (look for all files then you see all your old files and backups etc) now around 1000. after that (2h) i could do the upgrade to 5.11.1. loaded the NC files in a program with 80 NC it would still freeze the program but after a 15 min it would unfreeze so this defenitly helped. (before it could be freezed up to a whole day ) also see this thread for cobot file
answer @ypan :
I also noticed that most of your NC files represent the same pattern with a different Part Coordinate System (PCS). Basically, the robot needs to execute the same pattern in a 2D array. In this case, you can use a Toolpath_MoveP inside a Pallet. The Toolpath node should call the same NC file and use a variable PCS updated by the pallet. Below is an example for your reference.
The variable PCS is essentially a pose variable. At each item within the pallet, you can update this pose variable to change the location of the PCS before running the Toolpath node. This should significantly simplify your robot program and reduce the number of NC files needed. Let me know if you have any questions about this approach.
.
this did the trick I din’t use a palitizer but a pose transe. The NC’s in the program are brought back from 80 to 4 NC
i=0
loop for i<20
Point_A=pose_trans(Plane_1,p[0,0.1*i,0,0,0,0)
toolpath_moveP
etc. etc.
i=i+1
the fouth did the trick but i think you also need to do the first 3 advices.
thanks to @ypan the program runs smooth as silk again.
) also see 