Help needed. How to disable gripper opening with tha part beeing held ?

[FanaJel]

Hi everybody..

I've got a problem with Kuka VW robot application (palletizing of motor blocks). All I want to do is to inhibit opening of some grippers when there is a part inside (or another clamper - the speciallity of my application, one gripper holds another one). I've got the input signals of the part in the gripper, ok, but problem is validating the position of the robot (if it is actually possible to open the gripper in this pos or not - 15kg falls down and kills somebody  , in better case it was me :). For this reason, I call my speciall UP from SPS.sub interpreter to handle this. Trouble follows - I've got three pallets = three identical base systems, and i want to evaluate, if the TCP of the robot is located somowhat inside the cube of the pallet (in general). And I need it to work always - I can prevent the open action in hand mode (reseting the zange_action) and by program call (observing FP of the output to the gripper), BUT only as long as the $tool and $base is set. After power-on, I've got a message from SPS.sub "XYZabc tool not defined", which is actually right - $tool is $nullframe, $base is even not set to anything, I can't even see the actual position. When I set a tool, the $tool and also a $base is updated, and SPS works all right  , so I guess I need to initiate $base and $tool somehow, but I don't know how, because it's not possible to do it in SPS.sub (message "$tool/$base write protected"), don't know why. In other program, I can set $base to whatever I like, no problem.

I have searched the forums, but haven't find anything concerning this topic. How could this be done, or have you any exp how to prevent the parts beeing manipulated from fall down by accidental opening of the robot's gripper ?

Thanks for any help or know how.. 

[jseger]

Hmmm....   

Sounds like you should hard wire this safety feature in.  Define an interference cube and when that output comes on kill the power to the relay that opens your gripper.  That way there should be no accidents.

[SkyeFire]

I'm with JS on this one: safety through software is always iffy.  And if the main program fires an output and the SPS is shutting that output off, there's a chance that you might get a very short "blip" of that output getting to the outside world.  I tried setting up a conflict like that once for testing:  a loop in my motion program always turning an output ON, and the SPS always turning it off.  Sometimes I could generate a 12ms square wave...

Still...  okay, you CANNOT change $BASE or $TOOL from inside the SPS.  Anything that directly affects motion that way is prohibited from being manipulated from the SPS.

The good news is, you *should* be able to program around this in the SPS.  Just put something like
IF NOT ($TOOL==$NULLFRAME) THEN
....
ENDIF

around your current code.  Add a check for $BASE if necessary.  The trick isn't to initiate $BASE/$TOOL, b/c the first move your application program does will fix that.  You just want to keep your SPS from faulting out between power-on and when the robot starts moving.

Alternatively, you could put your SPS code inside an IF statement that only goes True after a signal (like a global Bool variable) is set from inside the motion program. 

...I'm positive there's actually a system variable somewhere that shows the valid/invalid status of $BASE and $TOOL, I've *used* it for something much like this.  But for the life of me, I can't remember what it is.