We have 2 UR3e robots with Polyscope version 5.8 and 5.11 and we have a program running in a remote computer, that sends through the Dash Board the “load program.urp” and “play” commands. Funny thing is, that all the programs can be loaded and started manually without errors. Then, in remote control, there are 2 programs that have a compilation error and they do not run in the first try. Then the remote program re-sends the load and play commands until it succeeds. Sometimes it can be in the 3rd try, but sometimes it can be re-sending the commands for 2 minutes approx until it launches.
This is hard for us to debug since it only happens in remote control and never in manual. When the compilation error happens, the pop-up displays that it is an error in the “Before Start” sequence. Looking on the .script file from the program, it is always a problem with a motion or waypoint, which were programmed using the Polyscope user interface and the waypoints are fixed positions that have been taught manually.
Does this means, that the compilation failes because the faulty parts of the .script file come from an automatic-generated code from Polyscope?
Has anybody gone through something similar? Any suggestions on how to debug these 2 programs?
I have not seen this problem before but is it possible the programs that you are having trouble with are loading different installation files? Or maybe they are really large programs and/or calling subprograms that are large?
I have experienced a similar compilation error.
although mine happens in manual also.
when running a program that I know works fine (has been run previously) and without any changes after loading it and trying to run it, I get random compilation errors.
I do think its because I have quite a large program with many sub programs, and the UR just doesn’t have the processing capabilities of other Industrial robots I’ve used in the past.
Lesson learnt :- Add a PLC to do all the heavy lifting and use the UR as a Dumb actuator.
All programs are with the same installation files and their script is just a main routine (no subprograms, no parallel threads, no secondary functions).
One of the programs is just a pick & place for tools: go to dock station, drop tool 1 and pick tool 2. Also all the tools work with the same I/O settings, so the I/O mode is fixed on the installation and there is no I/O mode changes in the program. It’s short and easy.
OK so do you have any 3rd party urcaps installed on the controller? It might be that some function that is getting invoked in the urcap is contributing to this problem. The other thing worth trying is to make a bigger delay from when you issue the load program command until you issue the play command. Maybe it is taking some time to get the program loaded into memory fully.
Of course you can try shortening the program temporarily to see if that helps alleviate the problem.
The other thing worth mentioning is that many times these types of compile errors don’t point to the actual line number where the offense is occurring but it’s the line before or after.
So I tried to add extra time between sending the load and play commands (it used to be 1.7s and now it is 3s). Also just in case, the load command is sent twice (also with 3s in between). This was implemented last week and compilation errors stopped happening without having to modify the programs.
