Just curious what this error is and how to handle it. We had our power shut down around the time when this happened so I’m also wondering if they are related. I’ve attached an image of the errors in question. I have underlined the ones that I have never seen and have had issues finding information on.
Thank you.
Hi Chartman,
Wrist 2A C284 is saying that a critical error occurred during brake-release, and the joint is entering the fault state. This might be caused by incorrect setting of payload. I might be able to give you a better answer if you can provide the flight-report.
SafetyB C281A3 is saying that it detected that Wrist 2 entered the fault state.
SafetyA C281A3 is saying that it detected that Wrist 2 entered the fault state.
RobotInterface URSafetyA 0: URSafetyB 0: I dont know the meaning of this
PolyScope Safety checksum changed to: A900: This is telling you that the safety setting have been changed!
I suggest that you validate that the safetyCheckSum have the value that you expect. Otherwise you risk using the robot in an unsafe manner.
Regarding the power out
If the payload setting of the robot have not been persisted, then it is possible that the “Wrist 2A C284” can be caused by the power outage.
Thank you for the reply!
I dont know how to provide you a flight-report. Also, these errors are no longer in the log as this was from 5 days ago. If I can still obtain a flight report I would be happy to do so if you could help me to do that.
Im not sure about the safety settings changing. I dont know what they were before but everything has been running perfect before and after these errors so I hadnt suspected any issues.
And what do you mean by “payload setting of the robot have not been persisted”?
Hi chartman,
The flight-reports is located here on the robot “/root/flightreports”
Here is a guide on how to extract flight-reports magic-file-backup-log-history-file
Here is a guide on what you can do with the extracted information ur-log-viewer-manual
Regarding “payload setting of the robot have not been persisted”
If you make a change without saving it, then the change is not persisted.
Since you had a power outage, then it is possible that you made a changed that was “forgotten” after the controller was re-booted.
I would also suggest that make a backup of your programs, see guide here magic-file-backup-all-programs
Hi,
The C281 and C284 errors are caused by one of the following usually :
If it’s #3 then your best course of action is to send the support file (mainly log_history.txt) to your distributor (whoever you purchased the robot from) so they can help you to start a service case. This forum is not the proper place to initiate a service case if the joint needs to be repaired or replaced.
Setting up a service case through your distributor would be your best bet. Historically we’ve seen a couple C284 errors when the robot is physically mounted near something that gives off a lot of vibration (vibration table, bowl feeder, very rarely a large machine that is not isolated properly). Vibration can affect the initialization of the arm (the clicking you can hear on startup) and throw those faults.
Thank you both for the responses, that’s good information. I will speak to my supervisors and see if that’s something we should look into. We recently moved the machine and I thought I noticed some shaking for the first time, but I’d also never paid attention before so there’s a chance its always had a little shake and I had just never noticed but its definitely worth talking about.
If the vibration of the machine is the case, is that something that would occur when starting up the robot while the machine is vibrating? or would it/ could if also occur is the machine was vibrating while the robot was off and then someone turned it on?
If the root cause is external vibration, then the main issue is only during startup when you want to release the robots brakes. After brakes are released you shouldn’t see the same errors until you need to boot it again.
