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.

[Weinreich]

Hi There

I have somewhat the same problem.

I have a linear unit with 2 carriers, where i need to detect if the TCP of the robot, gets too close to the second carrier.
Therefor i need some way to detect if the value in $POS_ACT is valid, and it isn't at program startup, which crashed my Submit (SPS) if i try to read it.

Isn't there some way of detecting if a variable (of any type) has been initialized?

[stefanm]

Hi,

you can use VARSTATE("$pos_act").
Returnvalues:
#unknown
#initialized
for more information you should check the KUKA documentation.

but seems to have a bad performance.

BR Stefan

[Weinreich]

I've tried to use the VARSTATE check like this inside the SPS:
      IF ( VARSTATE("$AXIS_FOR.E3") == #INITIALIZED ) THEN
         MyValue = $AXIS_FOR.E3
      ENDIF


But sometimes it fails and i still get "E3 invalid value" and the submit stops.

Can i be because it is inside the sps ?

[SkyeFire]

The timing would be *extremely* close, but since the SPS and the top-layer program do not operate synchronously, I suppose there *could* be a time window in between the VARSTATE test and the next line of code for the #AXIS_FOR variable to change state.  It would be a *very* small time window, but it could exist.

Since $AXIS_FOR changes as each motion completes, it's timing is completely random from the SPS's perspective.  I'm not sure how one could test this theory, but I do have an idea or two (this is one place where KRL could *really* use an error-trapping command).

To test if this is the issue, I would try something like this:  build a test motion program to run in parallel with the same SPS.  Set this motion program up with TRIGGER commands to fire a global boolean variable or output at a set time before the end of a move, and use some WAIT FOR TRUE or WAIT SEC 0 commands after the move to break the advance pointer.  The intent is to create a situation where the time when $AXIS_FOR switches from #UNKOWN to #INITIALIZED or vice versa is predictable and controllable.
In the SPS, use the boolean variable from the motion program to control whether the VARSTATE check ever happens.  By tuning the time delay of the TRIGGER command carefully, it *should* be possible to find what time delay, if any, can cause the "E3 invalid value" fault to occur in a controllable fashion.

If this experiment is successful, the next hurdle would be how to *control* the problem in a production environment.  That's going to require some serious thought.

[stefanm]

Hi,

this is not a timing problem - initialized means initialized.
It would mean the function Varstate is not running well.
Check, if you use  $Axis_for.e3 somewhere else. If not, contact the KUKA hotline.

But I think, there is a different problem.
You run the SRC - $tool is valid and $Axis_for.e3 is initialized.
You write the actual value to MyValue.
You unselect the program, $axis_for.e3 is no more initialized but MyValue is still the last one.

It´s easy, to avoid this.

Code:

;-------------------------------------------
MySrc:
;-------------------------------------------

; fold ini
  ;-------------------------------------------
  ; initilaize all tool related variables.
  G_bInit = FALSE
  $tool = tool_data[1]
  ptp $pos_act
  wait for G_bInit
  ;-------------------------------------------
; endfold (ini)

Code:

;-------------------------------------------
MySub:
;-------------------------------------------
  if ( VARSTATE("$AXIS_FOR.E3") == #INITIALIZED ) then
    G_bInit = TRUE
    MyValue = $AXIS_FOR.E3
  else
    MyValue = -9999999
  endif

BR Stefan