So, we have this program running in UR3 robots. And we got 5(five) time joint (wrist 3) errors!
The support isn’t being able to help us, and actually we need help to avoid this kind of errors/situation.
They said that is this program the cause. Can i find some help here?
Dass-PUR.script (9.6 KB)
DASS-PUR.urp (721 Bytes)
Do you know what specific line of the polyscope program the error occurs on?
Are you able to send the error that shows up in the log?
The URP program is just one line that calling the script file.
If I put to run the program, if run without any errors. BUT sometimes I get the C264A0 error or C157A0 error.
But it is just happens once day or not
URScript can be hard to debug. Unless someone else gives another suggestion, what I would do is use the textmsg() function as you enter each stage of your script to identify where the error might be happening. And then narrow it down from there. Try not to write too many of these rapidly as it will overload the system. The printout will show up in the log.
Also, outside of being used in the threads, do you need the sync() calls in all of your while loops?
I put the sync() becouse they ask me to put that.
Hi,
C264A0 error is a task manager error.
I noticed that your script has many threads. Are they all necessary ? Could they be gathered, or converted in functions ?
To go further, your contains many sleep() and sync() functions. Are they all necessary ?
For instance, would it be correct to rewrite the thread sprayON as follows ?
thread sprayON():
if spray == False:
set_standard_digital_out(0, True)
set_standard_digital_out(1, True)
else
set_standard_digital_out(0, False)
set_standard_digital_out(1, False)
end
sync()
endHi!
Actually my program at start, have no threads! I swicht the I/O directly.
I just put the thread becouse the UR Support told me to use that! The function sprayON() was sended to me to put in the program. So when i need to change de I/O states i change the variable spray.
In the head of the program it start the thread, and that keep waiting to change the state of the variable to switch the I/O.
Ps. The point is: I need change the I/O after a moveJ and before a moveP
They sad to me that I have to do in this way. Becouse if I switch directly, It can cause trouble with the normal function of the robot.
Would be reeeeeaaallllllyyy nice If i found a way to change the I/O without the use of the treads!
I´m curios about this: in my example, I swith the I/O only 4 times in the whole program. But in this one, it keep sending the command to the I/O the whole time. ?
My understanding of the problem is that the robot gets confused in performing all what is asked at the same time (C264A0 error is a task manager error).
Note that a sleep command is some kind of work for the robot (it takes computing resources).
In the implementation of the thread sprayON I sent you, yes the I/O is set each time. In your implementation sleep 200 ms is sent each time.
Then I think a thread is not necessary to set your I/O.
Actually the sleep() “freezes” the thread. I did test with SSH and checking the CPU load with the “top” command, but these thread haven´t take almost any load of the CPU…
“Then I think a thread is not necessary to set your I/O.” YEP! I think the same!
Actually the C264A0 happens rarelly (once in weeks) but I Still can´t find where it came from.
C264A0 is reported from the tool and indicates that the tool (device in the tool flange) is losing packages.
The rest of log seems to indicate that there could be a problem with the HW.
My best guess would be that there is a communication issue between Wrist3 and the tool, which causes this error, and that Wrist3 might need to be replaced.
I would guess the likelihood of the error happening is higher when rotating wrist3
It seems that your robot is UR3e of the e-series. The fault might be generated because of the usage of infinite rotation in your application and something wrong to the hardware connection. You could try to replace the wrist3, or even both of wrist3 and tool flange to solve this issue.
It seems there have been a few cases of this issue on the UR3e. The slip-ring between Wrist 3 and the tool flange is most likely faulty. The slip-ring is what allows Wrist 3 to rotate endlessly while maintaining communication with the tool flange.
This issue causes the robot to lose communication to the tool flange and results in the C264 error, as pointed out by others.
You can test the theory by making a program that rotates endlessly in Wrist 3. 
If you encounter the issue by rotating endlessly, Wrist 3 will have to be repaired. As sya said. I would do the above test beforehand, though, to verify the issue before investing in a repair.