Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - jschmidt

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.
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.

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.

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.

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.

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?

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?
Support / KRC2 Cross3 start up program unable to start
January 21, 2018, 08:20:53 PM

Upon start up of the Cross3 start up program for my KRC2, I get an error message that says "This program has performed an illegal operation and will be shut down" (picture 1 attached). I've also attached the "Details>>" page, which says that "Cross3 caused an invalid page fault..." (picture 2 attached).

Has anyone encountered this when working with a KRC2?
Support / Re: KRC2 will not master all of the sudden
December 14, 2017, 11:26:02 PM
all good information. Thank you! I will look into the RDW.
Support / Re: KRC2 will not master all of the sudden
December 13, 2017, 11:39:09 AM
thanks for your reply! I ended up employing the time old tradition of turning it off and turning it back on, and then it mastered right away...

also, if I could tack on another question, to ensure that the robot is still mastered every time I turn it on, I go to setup > master > EMT > standard > set mastering, and then see if it prompts me to master the axises instead of saying "no axises to master" (meaning that mastering saved from the last time.
However, it ALWAYS prompts me to master all of the axises again instead of saying "no axises to master". So, I have to master the robot upon every start up. By doing the checking process of that I just described, am I unintentionally reseting the mastering?

I know there is a set process to actually check the mastering, but it seems so much easier to just hit "set mastering" and see if it prompts me to master or not. However, I will obviously switch to the cited "check mastering" process if my way is causing the mastering to constantly reset.
Support / Re: KRC2 will not master all of the sudden
December 11, 2017, 11:06:41 AM

Thanks for your reply.
I tried to move on to the 2nd axis to see if it was just the 1st that was wrong, but I got a message that said something like "incorrect mastering sequence" indicating that I couldnt do axis 2 before axis 1. Do you know if theres a way to override that?

yes I did look if the prongs were bent and they didn't appear to be. However the prongs on the connecting port on the robot are really old, so Im worrying if maybe there's a problem with those.

also, to be clear: the lights on the EMT are on and responding correctly, but when I click "axis 1 > master > start key" the robot moves like it's mastering, and then I watch the prong from the EMT tool go into the divet on the robot that it's supposed to line up with, and then move past it. Then the HMI has a message that  says "EMT mastering distances exceeded". Basically it looks like the EMT isn't sensing where the point on the robot is that it's supposed to line up with.
Support / KRC2 will not master all of the sudden
December 09, 2017, 09:34:15 PM

Im working with a KRC2 and trying to master it with an EMT. I've mastered it multiple times before with not much issue, but it won't master today.

Besides switching out the cable/emt (I've tried 3 different sets) do you know of other reasons why mastering would stop working all of the sudden?

I was thinking that maybe I'm plugging the cable into the X32 port on the KUKA wrong - because the cable can easily be removed and doesn't appear to be locking in - but the green lights on the EMT tool flash on when it's plugged in so I dont think thats the problem.

Any suggestions are appreciated - thank you!
Support / Re: KUKAprc collision checking not working
December 09, 2017, 09:29:30 PM
thank you!
Support / KUKAprc collision checking not working
December 04, 2017, 08:57:20 PM

I am working with a KRC2 and using Grasshopper KUKAprc to generate the code.

I am trying to mill a foam shape, and when wiring in a box mesh (simulates the table the foam stock is sitting on) to the "collision" input in the CORE,  the simulation still shows the spindle tool running into the mesh box. Is there a simple answer as to why this is?

Jpeg, rhino and gh files attached.

Thank you!
Perfect, thank you!