Hello:
I'm working with a KRC2 and we just added an external axis to the controller. We built our own turntable and are using that.
I created a code in KUKAprc that (I think) accounts for the external axis in the KUKAprc settings and the simulation is working fine. However, when I run the program on the robot, the program only moves the robot slightly from it's start position before I get the error "software limit -A3 out of range". I changed the start position of A3 around a couple times in KUKAprc as well as made some other positioning adjustments but no luck. There's no reason that A3's position should be out of range, and the simulation and analysis both look fine.
The simulations and analysis from KUKAprc were always accurate to real-life before incorporating the external axis into the controller. Within KUKAprc, the only info I added in about the external axis was under ADVANCED > EXTERNAL KINEMATICS > ROTARY AXIS > DYNAMIC VALUE BY VECTOR > X = -1 and of course using the Turntable component under 02 Virtual Robot.
Wondering if I need to give KUKAprc more information about the external axis so that all 7 axises run smoother together?
Hello,
Let's go through that point by point:
If you say that you built your own turntable, you used a KUKA motor and built your mechanics "around it", right? I.e. the control is KUKA standard?
As the next step you would calibrate your turntable, as a result you will get the XYZABC values that signify how the turntable is located in relation to the robot's base. So if X is 1500, the turntable would be 1.5m in front of the robot. Enter those values in the dropdown menu that you get from right-clicking the turntable component in PRC.
Finally you would calibrate an Offset system. That is the same as a Base system, but its zero-point is the origin of your turntable. So the values will be rather small, in the hundreds of millimeters probably. Enter the XYZABC values as a base in KUKA|prc.
Before you proceed with KUKA|prc, activate a calibrated tool and your offset base. Go into e.g. base movement mode and move the E1. The tip of the tool should stay at exactly the same position in relation to the turntable, it rotates with it. If it wobbles around, your calibration isn't very accurate. Or maybe the gear ratio is incorrect.
The dynamic value by vector works OK for some simple cases, I usually now write my own small logic to set the external axis values. You can directly set E1-E4 by right-clicking a movement component and clicking the appropriate option.
Hope that helps!
Best,
Johannes
Hello:
Thank you! That information is helpful.
It is not a KUKA motor that we built our mechanics around - it is instead a Siemens AG Three Phase Servomotor.
When trying to calibrate the turntable with the Root Point subprogram, I received the error message "Kinematic instruction inadmissible" which means that "A non--existent external kinematic system has been assigned to the system variable "$BASE" with the function EK."
I'm assuming that means further calibration needs to be done, but if the Base is the workpiece, and the workpiece is accounted for within KUKAprc, shouldn't that mean we don't have to further calibrate it with the robot?
Hello,
I may be wrong there, so please double-check, but to my knowledge you can only use KUKA motors (or let's say motors attached to a KUKA PowerPack in the cabinet) to drive a turntable synchronously.
Otherwise the E1-E4 values will simply be ignored. In your case I guess that you are controlling your external axis through maybe an analog output or serial commands to a controller? Or have got a servo driver at the bus coupler?
In that case you can set the rotation value e.g. through a Custom KRL command, but you will need to rotate your frames yourself in Grasshopper. At least the calibration should be easy, you can simply do that same as if you calibrate a KUKA turntable but write down the points. With the three points you can create a circle in Grasshopper, and the center is your rotation center and the circle's normal the rotation axis.
Best,
Johannes
Hello!
So my bad, I was working off of the wrong spec for the motor. It is a KUKA motor and the tag is attached, and yes, we did build our own mechanics around it.
Now, my only issue is that I am receiving the error message "kinematic instruction inadmissable" when trying to set the first point of the turntable calibration with the root point subprogram.
My only idea is that I perhaps need to calibrate the tool orientation? So far, we have only calibrated the tool position and have been using that information to mill with a custom spindle tool.
Hello,
But is it synchronizing properly, as per my previous post?
I don't think it's related to the tool orientation, that should not influence it.
Can you simply teach the robot positions that involve a change in the external axis? If that also does not work, I would just call the German KUKA hotline. I guess then it's just a small configuration issue.
If that works, and the KUKA|prc file does not work, please send me the *.src and .dat file from the program (which you manually programmed at the robot, not the PRC program).
Best,
Johannes
Hello,
Yes it is synchronizing properly when I jog it and through a program programmed on the teach pendant.
(sorry in advance but I'm new to this) when you say "teach the robot positions", I thought that that was what I was doing when I was guiding the tool to the 4 reference positions with the Root Point program? And then when trying to do that, I receive the aforementioned error message before I can save any of the points.
By teaching I mean that you "manually" program the robot - so called online-programming, where CAD is offline-programming. So rather than going through Grasshopper you create a new file on the KCP, move the robot somewhere, save it as a PTP movement, move it somewhere else, save it as a LIN movement, always with different values for the external axis. The robot should then be able to replay the movements exactly like you programmed them (relating to the positions, in between it will interpolate according to the movement type).
If that is working while PRC is not working, can post the DAT and SRC files?
Best,
Johannes
After reading your post again - you already cannot calibrate the root point due to an error message?
Does it fail at the end, or at the beginning of the process?
In any case, you should definitely check with KUKA or whoever set up your robot. Probably it's just a single wrong value somewhere.
Best,
Johannes
...and because of your username I somehow assumed you to be in Germany, which seems not to be the case. Sorry for that!
But if you or one of your colleagues DO speak German, I would still recommend calling the German KUKA hotline as it's free during regular office hours and they are very competent: +49 821 797 -1926
Have your robot serial number at hand, as they will ask for it.
I'm not sure how the technical support works in the US, but you can also give that a try!
Best,
Johannes
hello,
yes I am receiving an error message when trying to calibrate at the beginning of the calibration,
so within the Root Point subprogram:
- I can set the external kinematic system with "ExtBase Ok"
- then I can set the measurement tool no. with "Tool Ok"
- I can check the position of the reference mark with "Point Ok"
- but then, when it prompts me to "move the external axes and then move the TCP... (1st measurement)", I receive the error message when I hit
"Point Ok" for that first measurement
so I haven't even tried to run a program with the external axis yet.
However, a coworker wrote a program "manually" and the external and the other axises moved synchronously.
And yep I am actually in Detroit (german grandma) and we call the US KUKA hotline all the time so I will do that next!
Thank you for the help so far.
Hello,
Hmm... Strange. I'm more "fluent" with KRC4 so it's a bit hard to troubleshoot from away. I would recommend that you talk with KUKA first, and if they cannot really help you could send me the relevant machine data, so that I can compare it with a similar robot.
And if you program it manually, it might be that the axis movements are looking fine, but when you look at the Cartesian values they are all over the place.
Let me know what KUKA says!
Best,
Johannes
We had this error also "Kinematic instruction inadmissible".. there was a setting in: Setup-> Service-> Config External Axis that we had missed, or you can edit the R1\MADA\$machine.dat file directly.
$EX_KIN should have ET 1 set to EASYS
$ET1_AX should have TR_A1 set to E1 , name of transformation can be whatever e.g"turntable"
$ET1_TPINFL should have the x value set to the distance from the centre of the turntable to your reference mark.
hope it helps..
Thank you so much! That solved the problem of the error message!
Now I am able to calibrate. However, at the end of calibration, I first received a huge error measurement (600 mm) instead of anywhere close to the allowable 5 mm. So, I mastered the external axes again through Dial Mastering, recalibrated with the Root Point, and received a still massive - but not as massive as before - 328 mm error measurement.
I think this could be for two reasons: I am calibrating the external axes using a 1/2" diameter flat mill as the reference tool (and am eye-balling where the TCP on it actually is) and I have lightly collided the reference tool with the table a couple times.
I am thinking that I will remaster the robot axes (because of the collisions) and switch out the 1/2" flat mill with a tool that has a point to use as the reference tool for calibrating the Root Point. To me, 328 mm of error still seems too large even if the flat mill is what is the causing the problem, but if the robot axes were also thrown off by the collision, then that amount of error would make sense to me.
Hello,
You can quite easily check if something went wrong with the axes - simply test if the robot can move along a straight line. If it wobbles or deviates a lot you've got a problem, otherwise it shouldn't be in the vicinity of 300mm.
In general I'd say that most milling tools would shatter before the robot gets seriously damaged as they are quite brittle.
And is the tool calibrated correctly? I.e. if you move it in A, B or C the tip stays at the same position?
What you can also do, just for testing, is to guess the root point (move the calibrated tool into the center of rotation, display the actual position) and enter XYZ manually (is there a menu for it? otherwise in the machine data) while leaving ABC at 0.
...one more thing: When it asks you for a reference point, take the approximate distance from the center of the turntable to your calibration point as e.g. X.
Best,
Johannes
The tool is calibrated correctly: we moved it in the A,B and C axis and the tip stayed in the same place.
The robot is not professionally leveled and neither is the turntable. They are both sitting in the corner of a room with a poured concrete floor (where the floor is highest in elevation at the corners of the room) so we are going to focus on that next.
The actual "table" that sits on top of the turntable is also not completely level - with the middle where its secured to the mechanics being higher than the edge - but I don't see why that alone would create a deviation because the reference point for the root point stays in the same place relative to the table, and then just the entire table and the reference tool on the robot are moved.
Finally, the robot does seem to wobble as it moves: in the TOOL coordinate system, when we jog the X-axis or Y-axis @ 10% speed, the tool is clearly wobbling a bit - is that normal, when jogging at continuous motion? We went through and tightened the anchors that connect the foundation plate to the concrete floor, as well as the bolts that connect the robot to the foundation, but that produced no change in wobbling. If this is a problem, and the professional leveling doesn't completely fix our error measurement deviation, I am unsure of what to do next.
Hello,
It shouldn't matter whether it's levelled or not, after all the frame of the turntable is set in XYZABC, so just like a base it could also be tilted.
It's quite normal that the robot is shaking a bit when accelerating and decelerating during jogging, but while it's moving it should be a straight line.
When you calibrated the robot, did you use a calibration device (EMT/EMD)? Because it's not enough to just align the white marks.
Best,
Johannes
Okay! Got it - that's good-ish news I suppose.
When you say calibrate, you mean mastering, correct?
Because yes we used an EMT tool to master the robot, and we were also able to calibrate 3 tools correctly with XYZ 4 Point and only received an error measurement of around 0.5 mm with each calibration.
When mastering the external kinematic, we are not able to use an EMT tool because we built our own mechanics around the KUKA motor. So, to master it, we simply select Setup > Master > Dial > External Axis 1 > Master and that's it - we don't move the external axes at all before we master or do anything else. Does that matter?
Yes, I meant mastering. All of that sounds fine, as a turntable is generally symmetrical it doesn't matter too much where the zero point is located at!
Maybe one more thing: Did you set the gear ratio correctly? That might also confuse the robot during the calibration.
EDIT: I guess you could check the gear ratio by manually jogging the turntable, to check if 360 degrees are actually one full rotation.
If that doesn't help I would try to enter the values manually, just to see if it works out. In your $config.dat there will be a line like that...
MACHINE_DEF[1]={NAME[] "DKP-400_1_40A_400V",COOP_KRC_INDEX 1,PARENT[] "WORLD",ROOT {X 7000.0,Y 0.0,Z 0.0,A 0.0,B 0.0,C 0.0},MECH_TYPE #EASYS,GEOMETRY[] "ObjectId = -1068536877"}
Set the XYZABC of the ROOT to the position of the turntable. Maybe leave ABC at 0 to start with. Then calibrate an Offset Base and see if it's synchronizing (with a little bit of drift).
Best,
Johannes
Hello:
The process you suggested (I think) allowed me to calibrate the Root Point correctly. Referencing an earlier response to this thread, I moved the TCP to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.
I think though, that I am confused about the necessity of a base calibration when using a turntable and creating a code in KUKA|prc for it.
In KUKA|prc:
I created a toolpath from the control points along the polylines that were derived from the contours of a form that I want to mill out of a piece of foam. After entering in the Root Point Numeric values in the teach pendant, I entered the same values for XYZ for the robot under Positioner Root Frame in (the Generic Turntable component).
Because the root point is given, and the control points to mill between are given in grasshopper, why is it necessary to also enter in Base values in KUKA|prc? It's my understanding that the base in the initial "stock" of foam that will be milled - is that incorrect? In the .src file, my base is set at 0.
I've attached my .gh file and .3dm file in case that clarifies my question.
Hello,
Well, the thing is that even if you have got a turntable, you might not always want to use the root of the turntable as your origin. But note that bases on a turntable are called Offset Bases, and you need to calibrate them as such. If it's not an offset base, then it won't rotate along with the turntable. I doubt that base 0 would work as an offset base, so calibrate a new offset base - you can use all 0 if it's at the center of your turntable.
Some more suggestions: The GEO input of the turntable is meant for the geometry of the object on top, i.e. it will rotate along with the turntable. At the moment we do not support custom turntable geometries, though we can integrate it as a native component for members.
And very important: The more triangles you have, the slower Rhino gets. Your turntable model has got 45k vertices, which is more than the entire robot. So your performance will get quite a hit.
I have made a quick example for you on how to calculate turntable values automatically. See here: http://forum.robotsinarchitecture.org/index.php/topic,822.0.html
Best,
Johannes
Did you solve the large measurement error during calibration? This could also be due to an incorrect gear ratio being set. Do you have the exact ratio for your gearbox?
@ Johannes: Okay, that makes more sense about the offset base: if you don't want to use the root point of the turntable as your origin, the robot will use the origin of the base that's on top of the turntable. If you do want to use the root point of the turntable as your origin, then there is not a need to calibrate an offset base.
When you say "I doubt Base 0 would work as an offset base" - do you just mean in terms of the program being set to a base called "0"? (why does it matter whether it's called Base 0 or Base 17 if the XYZABC values will all be 0 for either one?)
Thank you for your note about the amount of triangles in the table mesh. I knew that the Geo input of the turntable was meant for the mesh of the final form and just forgot to unwire it so it was a good reminder to disinclude that. I've swapped it out for a simple extrusion in Rhino of the turntable top so that I can make sure the spindle isn't colliding with it (attached for ref)
Finally, thank you so much for the example file!! That has solved almost all of my issues. I think the last thing to resolve is that A6 is spinning all the way around in the first few motion blocks, and then about 30 lines down stops the program because "software limit switch +A6 reached" or something to that effect. Just something else that needs to be resolved in the .gh script I'm assuming.
--
@ mcb: for calibration of the Root Point of the turntable, I entered in the values numerically: I moved the TCP of a previously calibrated tool to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.
I believe the gear ratio is 24/1 based on the $rat_mot_ax variable (photo attached because not sure if that's it)
Aaand now looking at the analysis of the code again, I see that there is a wrist singularity right at the beginning, which would be the reason that the simulation after the singularity is inaccurate.
So! I suppose I am on to modifying the $SINGUL_POS[3] variable in the machine.dat file
Hmm... I need to look into why this is showing up as a singularity, because it seems to be part of a PTP movement, where singularities are not a problem.
In general to avoid singularities, just adjust the posture (e.g. via status, or simply by changing the starting position) or for milling rotate the tool around its axis.
And base 0 is "hardcoded" as the robot's base, so I wouldn't change it (not sure if you can even change it).
Regarding the gear ratio, as I suggested before I would simply manually rotate your E1 by 360 degrees and check if it makes a full circle!
Best,
Johannes
I've been updating our Call Center Engineer @ KUKA on this process as well, and he is saying that:
- Our serial number indicates that we are operating a KR 125-2
- But our $robcor.dat from the archive that I sent him shows it is configured to control: KR 150 L150 "#KR150L150_2_TJ H C2 FLR ZH01"
and that this difference could cause some substantial differences between the motion planning and the physical path of the robot. So, we've been instructed to reinstall
the default files for the machine.dat.
I'll keep you updated on this process - let me know if you're able to look into what could be causing a wrist singularity @ the PTP movement and maybe resetting the machine.dat is the right answer as supported by both investigations?
Also, okay good (!) - just jogged the E1 360 degrees and that worked. I think that instruction went over my head before - whoops
You should have got a sticker on the side that tells you the robot type - what does it say?
But it's of course possible that somehow robots and controllers got mixed up.
I'd recommend making a backup of the current setup before the re-installation. If you don't have the KUKA recovery stick, either install backup software on the robot or (better) connect the HDD to another PC via an USB adapter and use a software like Macrium Reflect to make an image.
Best,
Johannes