RoboTeam is the only software option I'm aware of that would address this situation completely. Without that, you could set up various workspaces and cross-link them between robots using I/O.
Posts by SkyeFire
-
-
So, is this a shock sensor, or a contact sensor? Does it detect impacts, or the flex of a compliant coupling in the torch mount? How is it connected to the robot? Does it include a hardware override or bypass switch? What I/O config are you using? What KSS version? What welding software TP (if any)? And what, EXACTLY, do you want to "manage"?
-
Yes, booting Windows to Safe Mode will also work.
Or, you could try using the keyboard to enter the BIOS menu, and select which device to Boot from (this is a temporary setting that is reset once the robot is rebooted again, but it works). This would allow you to boot from a recovery CD, or even from a floppy.
If the keyboard issue is hardware, to the point that you can't even enter the BIOS menu, I can only suggest trying an alternative keyboard type -- USB or PS/2.
-
There are software packages you can buy for that -- PowerMill, RobotMaster, Grasshopper/Rhino, KUKA.CNC.
Without one of those... well, you could post-process the G-Code into a sequence of KRL motion commands by hand, using Excel or some Python scripting. Or, similarily, you could convert the list of G-Code motions into a corresponding array of KRL E6POS positions in a .DAT file, then iterate through them using a FOR loop in the .SRC file.
This is probably too cumbersome for complex machining paths, but this one looks simple enough it might be doable. You'll still need to hand-program your entry and exit points in order to guarantee your correct pose configuration, and probably massage your G-Code conversion a bit to get it to work (the corners will definitely be an issue). This is a crude solution, but possible.
Of course, generating any OLP depends entirely on having excellent Base and Tool configurations that match between the CAD/Simulation environment and the real-world environment.
-
-
You can boot to Windows, and prevent KSS from starting, by plugging in a keyboard and holding down the Shift key during boot. Once you have the Windows Desktop without KSS, you should be able to do anything you need.
-
Check your Mastering as well. A badly-mastered axis could also have this kind of effect.
One other check you can do: rotate each axis an easily-eyeball'd amount, like 90 deg, and compare the actual physical motion of the axis to the motion reported on the pendant. I once had to replace the motors on a KR with their "identical" Arctic-rated equivalents, and it turned out that the "identical" motors weren't -- their internal encoder ratios were different from the original motors, so each axis move was about 67% of what the robot thought it was. Had to fix the $RAT_MOT_ENC values for all the motors.
-
Hm... there is no direct way that I know of. There might be some indirect ways.
For example, if all of the KRL files in the robot were encrypted using the KUKA Encryption option package, the KRL code would be unviewable and impossible to edit. So you could bury a function inside a critical part of the KRL code that would stop working after a certain date until a particular password was entered.
A different option might be to bury a Windows scheduled task in the robot that, after a certain date, would change the Windows login on the robot by editing the Registry directly. This would be easy to get wrong, though, possibly breaking the system when you don't want to.
-
Did the robot work properly after the new motherboard was installed? Or did it begin showing this problem immediately?
Possibly the new motherboard is defective. But it would be less arduous to try re-installing KSS first.
-
Robot model? Controller model? KSS version?
-
Generally, the only way to recover from a Sys14 fault (and there is a wide variety of them) is to cold-boot the robot. You don't need to leave it shut down for an hour, you just need to ensure the robot is cold booted, rather than hibernating.
Sys14 faults, in my experience, are generally "fixed" by upgrading KSS, or an option package, to a higher revision level that has the appropriate bugfix applied. But as Fubini says, you would need to describe your issue in detail to KUKA service to find out if they have a fix for this bug.
-
What model controller? What version KSS? And, as Panic Mode says, what exactly did you do, step by step, in adding this external axis?
-
What's the geometry of the cell layout?
Remember, a robot is not a CNC machine. It doesn't have anything like a CNC's rigidity or accuracy. Robots do have quite good repeatability, though. So, if you can arrange your cutting path to always move in the same way for each pass, that should improve things. It also improves path accuracy to move as few axes as possible (for example, set the arm to the cutting pose and then make the pass with just the linear rail axis). And you absolutely must avoid any axis reversals or singularities during the cut path, or you've no chance at all.
Also, again, note the lack of rigidity. You can't get accurate machining out of a robot unless you keep the applied forces VERY low. Robots have much more reach than CNC machines, but to achieve that, they trade away rigidity.
Panic Mode is also correct: at absolute minimum, correct mastering and load data are critical. Absolute Accuracy, especially re-calibrated with your working load, will squeeze more accuracy out of the robot.
-
The last time I had something like that happen, my robot's mounting bolts were slowly pulling out of the concrete floor (contractor had only put 1/4 of them in).
Is this an orientation change, a location change, or both? Is it something that could be isolated to a single robot axis, or would it require multiple axes slipping in concert? Could it be accounted for by just the wrist axes?
An RDC card going bad is very unlikely. They don't "drift" -- the either work perfectly, or fail completely. A mechanical cause is far more likely, but you would have to examine the nature of the slippage very carefully and isolate which axis, or axes, are causing it.
One approach might be to make a test program that touches the tool to a series of clearly identifiable points, and record their values in both Catesian and Axis values. Then, if/when the robot slips again, examine how much correction is required on each Cartesian and Joint axis to correct the slippage. That might help narrow down which axis or axes is the culprit.
-
KUKA Robotics Service dept has such a device, but I don't know if they sell it to customers.
The brute force emergency means of moving a KR axis without power is to remove the drive shaft cap on the back of the axis motor, fit a 12mm(?) socket with a long-arm wrench to it, and crank the motor by hand. This grinds the brakes and will void the warranty, but the assumption is that, if you're in a situation desperate enough to warrant this kind of action, the warranty is the last concern on your mind.
My understanding is that KUKA Roboter has long considered "brake release" buttons to be a greater safety hazard than a benefit, which is why no KRC from the KRC1 on has ever had them (I'm not certain about the pre-KRC1 controllers).
-
For the 3-point Base teaching method:
1. First point MUST be the origin
2. Second point MUST be on the X+ axis (to be precise, the line between the first and second points DEFINES the X+ axis)
3. Third point MUST be on the XY plane, in the Positive region for both X and YKeep in mind, if your tool is not a sharp point, you could suffer some accuracy degradation.
Whomever produced the program should be able to provide you a CAD file showing how they defined the Base. If for some reason they built the base in a way that isn't compatible with the 3-point method (X+ axis pointing out into space, for example), if you can define 4 identifiable features on the block that the robot can touch with the tool, you can use the 4-point method. The 4-point method is more flexible than the 3-point, but requires having CAD definitions for those 4 points in XYZ, and touching each of those points while providing the robot with the CAD coordinates.
-
Have you ever zero'd a CNC machine to a work piece? Setting a Base for a robot is conceptually the same, but taken to a higher level of complexity, and more degrees of freedom.
Just like zeroing a CNC machine, you can create a Base anywhere. But if order for that Base to work correctly with your robot program, you must have the program origin and the Base origin aligned to each other. So, the first critical question is: where is the Origin (zero point) of your program, relative to your work piece?
On a CNC machine, the Zero is usually a single-step process -- move the tool tip to the point in the work piece that coincides with the origin point set in the CAD/CAM model, and zero the axes. For a robot Base, the first point of the Base teaching performs this same function. The next two points align the rotation, or orientation, of the new Base.
For example: let us imagine that your stock is a simple rectangular block, mounted to a table in front of the robot. This stock has been defined dimensionally in your CAD/CAM program, with the Zero/Origin located at one top corner of the stock. Your G-Code, or robot language equivalent, is programmed relative to this zero point. But in order for the robot to carry out the milling program correctly, you must teach the robot where the Zero/Origin of the stock is, and how the stock is oriented, relative to the robot's $WORLD coordinate system. The CAD/CAM program does not care about the stock's location or orientation in space -- it only produces motion commands relative to the zero point on the stock.
So, assuming that the Origin/Zero point is located on one top corner of the stock, and the X and Y axes in the CAD/CAM model were aligned with the edges of the stock:
1. Touch the TCP (you must have a well-defined TCP for Base teaching to work) to the Zero corner of the stock -- this sets the Origin of the Base
2. Touch the TCP to any point along the top edge of the stock which is aligned with the X axis. The further from the Origin, the better the measurement
3. Touch the TCP to any point on the top surface of the stock (assuming the stock is flat). Again, the further from the other two points, the better
4. Avoid changing the orientation of the TCP during this process -- this improves accuracy of the measurementThen, when you attempt to execute your milling program, you must ensure that the Base you taught is activated. Otherwise, the robot will assume the points are programmed relative to $WORLD, whose origin is located in the bottom center of the robot itself, which can cause the "folding in" you observed.
-
The RESUME command is... badly named. Basically, it's only used in an interrupt subroutine if you want to terminate the interrupted task (usually a motion in progress) and return the program pointer to the level of the caller stack where the Interrupt was declared. If you only want your Interrupt to pause the program, then resume where it left off, you leave out the RESUME command.
So, in order to resume, don't use RESUME. (did I mention it was badly named?)
-
What is this robot's history? What changes have been made to it between now and the last time it ran properly?
Most often, this happens when KSS needs to be re-installed.
-
What model robot is this? What payload rating? It sounds like it's one of the really small models.
So... it's not just CG/inertia issues you're trying to avoid -- you're trying to avoid putting the weight of the wire feeder onto the robot at all, if I'm understanding you correctly. Hm....
A tool balancer might work. It'll really depend on the robot's travel. And how the feeder connects to the robot tool -- if it's just a wire hanging in mid-air from a reel, you're going to have issues when the robot moves up, since the tool balancer won't make the reel pull back the slack in the wire. OTOH, if it's an *active* wire feeder, and you have a sleeve or cable keeping the feeder at the right distance from the robot tool, then the balancer would probably work. You'd want a tool balance with just a little more lift than the weight of the wire feeder, though. And since the wire feeder's weight will change as it's wire payload is consumed...
You'll also possibly need a 1-D or 2-D travel axis for the balancer, above the robot, to keep the balance above the robot at all times, rather than letting it build up lots of diagonal tension. Again, this all depends on the exact details of your layout.