We have experienced the same kind of mysterious reboots and software crashes (hangs) on a new IRC5 controller. The reboots are random and don't seems to be tied to anything obvious. My gut tells me maybe it is caused by intermittent noise on the incoming power lines but I don't have any way to monitor them. We have had plenty of KUKA robots in the same building, using the same incoming power and have not seen this. But then again, KUKA controllers have backup batteries installed (not capacitors) so perhaps they are acting as a UPS.
Posts by BluesMatt
-
-
Has anyone here used World Zones?
I am trying to understand how to setup a couple of different World Zones based on robot motor angles (not the position of the TCP). Each World Zone will be an area where the robot is not allowed into. I am trying to see if using World Zones will have a quick enough response time to prevent the robot from entering 2 different areas while running in both MANUAL and AUTOMATIC modes. (In MANUAL mode, the idea is to help the programmer from accidentally jogging into a collision with part of the cell which is very difficult to see. And in AUTOMATIC mode, the idea is to prevent a collision in the event that the programmer makes a mistake.)
Matt
-
I believe I have solved this problem.
In Task #1, a motion task, I was using a large loop which looks for the START button (on the OpCon) to be pressed for either station 1 or 2. Instead of looping, I tried using a WaitUntil <either START button is pressed> and this seems to work. No more "interrupt queue full" error.
I will admit that I do not understand why RobotWare 6 does not like to loop. Also, I don't understand where all of the interrupts are coming from. But, my code seems to be running now.
-
All of the hardware is connected yet I am still getting the error.
Here's what I have tried and learned so far.
I have 2 tasks set up. One task is a motion task and is responsible for moving the robot and welding. The other task is responsible for monitoring the operator's console's push buttons.
I'm finding that my program runs fine for about 30 seconds and then the "interrupt queue full" error occurs. If I use the operator console START button and get the robot moving within 30 seconds, no error occurs. Once the robot motion program finishes, as long as I press START within 30 seconds, I do not get the error. If I wait more than 30 seconds and not press START, the error occurs and the program stops.
I need to understand where these interrupts are coming from and how to stop them.
-
What will the robots be used for?
-
Hello everyone.
I am running an IRB800 set up for arc welding. The robot sits in between 2 stations. There is an operator control panel at each station. Each control panel has several push button switches and indicator lights. I need to use the multitasking option to monitor each operator console while the robot is busy moving and welding.
All of the robot moves and welding commands will be executed within one task and the code used to monitor the control panels will be running in a different task. I have just started writing the code to monitor the control panels. This first piece of code simply blinks a light on each control panel (to indicate that the robot controller is running). This blinking code runs but after about 30 seconds, the 40206 error occurs and I cannot figure out why. (see the attached screen shot of the error)
I have tried running the same code in the other task and it runs fine with no errors.
From the error screenshot, it seems like the source of the problem is the tAwSys_1 routine. This appears to be a trap routine used by the arc welding software. Since the code I have written does not include any welding commands yet, I don't understand why this routine is generating interrupts (if that is what is happening). For some reason, is it possible that this routine is interrupting itself eventually filling the queue and causing the error?
-
Here's a different suggestion....
Why not use OrangeEdit's search and replace function?
-
I can tell you that I have spent many hours working with KUKA's Touch Sense software in a welding application and the software does work and does all of the math to correctly reposition the TCP. In my application, I also needed to compensate for part rotations around all 3 axis; I believe the math to do this on my own would be daunting.
The biggest challenges we have faced with Touch Sense was in using the correct type of sensor. If you plan to use the welding wire as the sensor, make sure there is a wire brake (so the wire does not get pushed back up into the liner when touching the part). An alternative is to turn the torch side ways and touch the part with the side of the wire. In our case, we developed a simple rigid probe to touch the part with.
You will also need a "master" part from which to determine the baseline measurements. You will need to hang on to this "master" so you can recalibrate the system if needed.
Let us know what you decide to do and how it is working out.
-
The link below is for a video on YouTube showing a small robot IRB 120 being calibrated. Each axis was manually moved to a position against a hard stop (a pin) and "fine calibration" updated. With all of the fine calibrations updated, the robot is jogged into a position where all of the marks on the axis' line up and then the revolution counters updated.
Are any of the larger robots calibrated in this way (i.e. using hard stops to indicate the "zero" position)?
External Content youtu.beContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy. -
-
-
It sounds like you want to be able to turn ON an output once the robot reaches a certain position. As was mentioned in an earlier reply, the HOME position works this way already and there are 5 or 6 HOME positions already setup.
HOME is a global position (meaning any program can see it and modify it). Once you understand how these HOME positions work, perhaps you could create you own global positions in the same way. Also see that there is a tolerance already setup for the HOME positions. To constantly monitor the robot position and actually turn ON (and OFF) the output, write some code that runs in the SPS.
Here's what my code typically looks like in the SPS:
;Check for HOME position
IF $IN_HOME == TRUE THEN
$OUT[10] = TRUE ;turn HMI HOME lite ON
ELSE
$OUT[10] = FALSE ;turn HMI HOME lite OFF
ENDIFHope this helps.
-
SizemoreJK, was the problem caused by crater fill?
-
Robot Freak, can you tell us what was wrong with your earth ground?
-
Thanks Roulv.
I work for a system integrator that builds arc welding cells. Typically, we design and build the cell, install the robot and welding torch, and program the customer's parts to be welded. Once the welding programs are finished, the cell gets disassembled, shipped to the customer's location, and reassembled.
My main concern is if a robot loses it's calibration for some reason (say during shipping), how does the robot get re-calibrated at the customer's location so that all of the previously programmed robot moves (points) are still correct?
With KUKA, it is not unusual for 1 or more axis to lose mastering during shipping (the arm moves slightly while powered off). With KUKA, use the EMD at the customer's location to re-establish mastering and all of the previously programmed position (points) are still correct. How is the same thing accomplished with ABB?
You mentioned that the new robots use pins and some software routines to calibrate the robot. Do you know which robots use pins?
I don't understand the reason for updating the 'revolution counters'. If all of the robot positions are keyed off of the zero point calibration (done with either with the Calibration Pendulum or with pins), what are the revolution counters used for?
-
Thanks for your reply Fluke. Here are my follow-up questions:
1) So it sounds like the Calibration Pendulum is used to determine the calibration offset numbers recorded on the manipulator label? Is there anyway the numbers on the label can become obsolete and new numbers need to be determined?
4) By "external circuit" do you mean my string of 2-channel switches (i.e. door switches & safety relays)?
5) We will be using DeviceNet to communicate with a welding power supply. Does that suggest that we should also be using DIO modules that communicate using DeviceNet?
Thanks again for your help.
-
Hello everyone. I hope you don't mind some very basic questions. My company builds robotic welding cells for general industry. My next project will be using an ABB IRB 1600 and a 2-axis positioner. I need to learn as much as I can in advance of the delivery of the robot (due in late August). Because I don't have a robot yet, I'm learning what I can from pdf's. In no particular order, here are my questions.
1) Mastering (calibrating) the arm - KUKA uses an EMD and software on the controller to move each motor into the mastering position. Does ABB have anything like this? What I have seen so far are some marks on the arm that you line up by eye and then update the revolution counters. Are there also some alignment pins or something?
2) Mastering (calibrating) external motors - When mastering an external motor gear unit with KUKA, we use an EMD. How do you master (calibrate) an ABB MGU?
3) Virtual PLC - KUKA has a virtual PLC which we use to monitor the state of some pushbutton switches the operator uses to control the robot while running in AUTO mode. Does ABB have a virtual PLC? How do I monitor mechanical pushbuttons while the robot is busy executing a welding program?
4) Safety chain - KUKA has a built-in Safety Interface Board that I wire up the safety chain (a string of 2-channel switches/outputs). So far in my early ABB education, I've been lead to believe that I need to add my own safety PLC the output of which is wired to the controller (somehow).
5) Digital I/O - It looks like ABB uses their own DIO modules that communicate with the controller PC using DeviceNet(?) and are setup/configured (mapped into memory?) using RobotStudio. Is this correct? In KUKA, WorkVisual is the configuration software where DIO modules (we have used Beckoff) are mapped into controller memory space.Thanks.....Matt
-
yes, yes, yes
Because all of the components are networked together, it is difficult to tell which component(s) failed. The LED status lights help and so do the error messages reported on the SmartPad and in the log files.
-
Turned out to be a bad KSP. The tricky part was that we tried 3 new KSPs before a 4th one worked.
-
We have a KR5 arc HW with a KRC4. The robot ran fine at our facility (we are the integrator). We shipped the robot and cell to the customers and reassembled. When I arrived at the customers, I double checked all of the connections, everything looked good. Powered on and tried to move the robot and I get General Servo Errors. I never saw any of these errors at my shop. KUKA has an archive and diag but no real concrete answers. There is a long list of things we have tried which include:
- verifying the incoming power is good (Our KRC4 has a transformer.)
- checked all of the cable connections by disconnecting/reconnecting. (Have done this countless times. Verified 7.1, 7.2, 7.3 connectors for the external motors are good.)
- replaced a KSP because it was showing a red error light (Never had a red light at my shop.)
- replaced a KPP because the early error messages shown on the SmartPad indicated issues with power (Never got these messages at my shop.)
- updated the firmware on both KSP and KPP (Never tried this before.)
- replaced the CCU board (then put the original back in) (The replacement sent by KUKA appears to be defective.) (We have had several CCU boards fail in different robots before.)
- replaced the motor and motor cable mentioned in the early error messages (E2) (I never had to replace a motor or motor cable.)None of this helped.
We do not have any other robots here to borrow known good working parts from. We are beginning to think some of the replacement parts sent are indeed defective but we do not have any way to verify this.
Wrote a basic WoV project that just included the robot and the robot was able to move. (This seems to indicate that the incoming power is good, the KPP is good, and the KSP for the robot motors is good.)
Wrote another WoV project with the robot and E1 and all 7 motors move. (This seems to indicate that the KSP channel used for E1 at least is good.)
Wrote another WoV project with the robot and 3 external motors and the errors appear. (E2 and E3 use the other two channels on the KSP E1 is using.)Tried swapping cables to the external motors to see if the early errors would follow the cable swap - they didn't.
Talked to KUKA countless times. Currently working with a KUKA tech onsite.
Still no closer to a resolution.
After putting in the 2nd replacement KSP (which is where we are now), upon power up, we immediately get "General servo error (E1)" and (E2), and (E3). We think perhaps the new new KSP did not auto address itself on the eCat bus so we are trying to figure out how to manually set the address.
What is really baffling is that this same robot ran fine at our shop. When it was shipped, it went on an air ride flatbed (we always ship on an air ride trailer either flatbed or enclosed.)
Has anyone else run into these General Servo Errors before and if so, what was your resolution?