Hi all,
I am a user of KR100 L80-2 HA 2000 (HF 130) KUKA plasma cutting robot. Recently, there was a crash during operation and the robot failed to stop during contact, resulting in torch damage. We called KUKA technician to investigate the issue. They took the log file, and come with a result that someone has modified the I/O setting which disabled the emergency stop function upon crash. I'm not trying to say that their report are false but as far as i know, no one did or knows how to change these settings. Asking for any kind expert here to look at the log report (provided by KUKA which suggesting modification on settings) and give a second opinion. I might be a user but i'm not an expert in this part of the machine. Thank you in advance. Cheers!
Crash Log Report -Second Opinion
-
camae -
April 22, 2013 at 10:33 AM -
Thread is marked as Resolved.
-
-
Do you have archives of the robot from recently, and from when the collision stop was known to work? Comparing these two archives should establish exactly what differences there were in the I/O setup.
The log file does show that the Auto-external I/O setup was probably altered in two different events. Which of these inputs is used for the collision detection?
-
Do you have archives of the robot from recently, and from when the collision stop was known to work? Comparing these two archives should establish exactly what differences there were in the I/O setup.The log file does show that the Auto-external I/O setup was probably altered in two different events. Which of these inputs is used for the collision detection?
Thank you SkyeFire for your reply. Just after the crash, we did a manual test on the collision sensor and it works fine (Acknowledge General Motion, and try to nudge the torch and it KRC shows general motion enable warning, and contactor was off). I don't have the archive from time before collision because the system was restored/reformatted just recently. The attached images was taken from the same log file. I don't really understand what's written there but i'm guessing it doesn't state that the collision sensor itself was disabled? Correct me if i'm wrong and sorry for my bad explanation. Thanks in advance.
-
The LogBook does not, unfortunately, record that level of detail. It merely records that the Auto-Extern I/O configuration was altered, and when. But the actual details concerning which signals were changed, and how, could only be determined by comparing the $MACHINE.DAT files before and after the change was made.
But it is definite that some sort of change was made to the Auto-Extern configuration, at each of the two time/date stamps shown in the images. And from experience, I know that the change people make most often is to change Motion Enable to $IN[1025], in order to bypass a lack of Motion Enable signal.
-
The LogBook does not, unfortunately, record that level of detail. It merely records that the Auto-Extern I/O configuration was altered, and when. But the actual details concerning which signals were changed, and how, could only be determined by comparing the $MACHINE.DAT files before and after the change was made.But it is definite that some sort of change was made to the Auto-Extern configuration, at each of the two time/date stamps shown in the images. And from experience, I know that the change people make most often is to change Motion Enable to $IN[1025], in order to bypass a lack of Motion Enable signal.
Thank you again SkyeFire for your kind explaination. Now that you mentioned it, operators usually do that to bypass a lack of Motion Enable signal, just as you said, when collision occurs and simply acknowledging the general motion enabled err msg in krc wont let you move the torch from its collided position. I wished that these log somehow showed that the person remembered to turned on the collision sensor before the crash. Thank you anyway for your time and i'll assume that this topic is considered closed for now. Thanks again, Cheers!