Return to home issues

Would help if you post some of your code as auto recovery is bespoke to each application and therefore there is no 'golden rule' applicable to all situations.

Myself, I always have auto recovery set at the start of the main program.

So in ANY instance required, the operator just primes the main program again and the robot will auto recover to home based on the condition checks I use and then from then either starts again from the start, or any subroutine I choose to reselect.

I never auto recover from a fault or a process stoppage situation.

I leave the robot in the last position so that an operator can decide on the best course of action to either recover or continue the process (after rectifying the fault or the process stoppage).

I've seen many situations where a previous programmer is trying to be too clever at auto recovery by putting in lots of un-necessary, over the top solutions as opposed to keeping things simple:

- Recover to a master position clear relative to current process so it can move directly to home.

- When at home, do you need to check EOAT state and dump parts or not, purge a gun etc

- When all is done, restart or go and repeat the previous process (application dependant).

I have only mentioned my method which I use as it is used automatically within the application.

If you want to rewrite your code so that it is part of your startup/restart then it's upto you.

You mentioned you switch to teach and press a button to call up your home routine and it doesn't load in the program queue.

This is why I asked you to post your code so we can see what's going on as to why it's not functioning as per your instruction.

Do you not think it would be worthwhile troubleshooting your code instead before deciding on changing your sequencing?

Quote from Jerryl859

If anything went wrong in pgs. 1/2 , I would want to go to manual and call up prg. 4 to return the robot home

By switching to teach and selecting prg4 should work no problem.

- Check/Reset fault/process stoppage, recover robot then reselect main program afterwards to restart.

- You would need to ensure the Robot 1020 and 1030 inputs from the PLC are reset.

- So that afterwards, the robot would wait for permission again.

So I don't know what you mean when you say it doesn't load in the robot queue?

Quote from Jerryl859

Sorry if I am not explaining very well.

No problem........

Quote from Jerryl859

So, in a faulted condition

What does this mean: Robot fault or Process stoppage?

Quote from Jerryl859

I want to go to manual mode without going into teach

What do you mean by this, teach is manual.

Quote from Jerryl859

by pressing a button have the robot load pg4 into the stack and as long as i am holding the button, have the robot step through the return home prg.

Yep, I can't get my head around this either.

Are you saying you have a push button somewhere and when you press and hold this on it:

- Primes the home program.

- Executes the home program sequentially as long as you are holding the button down.

Quote from Jerryl859

We could just load a return program in teach and step in through

That's always the safest method, least chance of ramming the robot and tooling through fixtures as the operator is running it at slow teach speeds.

Many questions exist still:

- What happens if the button is pushed during normal use.

- If the robot is in error, it is not executing anymore, so the button will not work unless asynchronously monitored for in a PCTASK using specific conditions.

- Have you looked at using pgxx and RPS functionality.

- Are you really looking at hard coding a solution in.

One of my old button monitoring functions is below (minus condition checks) which I include in my main PCTASK (cyclic asynchronous program).

At ANY time during non execution or execution of motion routines, simply pressing the button (allocated an internal signal to a button on the IFP in my case) will hold the robot, turn off motor power and prime a specified program from step 1.

A programmed interrupt, to stop any motion and prime a specific program only.

Even if it's not in execution, it will prime the specified program.

;
; Reset to xxxxx Program
;
    IF (SIG(si.pg.reset)==TRUE AND (mi.pg.reset==FALSE)) THEN;
      mi.pg.reset = TRUE;
      MC HOLD;
      WAIT (SWITCH(CS )==FALSE);
      MC ZPOWER OFF;
      WAIT ((SWITCH(RGSO )==FALSE));
      MC PRIME xxxxx,1;
    END;
    IF (SIG(si.pg.reset)==FALSE) THEN;
      mi.pg.reset = FALSE;
    END;

Quote from Jerryl859

The button would only work in manual operations and not in automatic.. or repeat

Doesn't make sense, no such thing as manual.

Kawasaki has 3 modes of operation:

- Teach (requires deadmans)

- Fast Check (requires deadmans and fast check button).

- Repeat

What do you mean by manual, please describe manual operation you are referring to?

Quote from Jerryl859

I thought RPS didn't play well with AS language

Depends on how you integrate it.

If you have a PCTASK running you can ensure it works very well indeed, but it requires some clear understanding of setting it up and how it is integrated.

My code above is a direct substitute for RPS and external program reset, that's why I posted it.

Quote from kwakisaki

What do you mean by manual, please describe manual operation you are referring to?

So by using my code above in a PCTASK after pressing the button, you would just require to press motor power and cycle start.

Alternatively you could include those commands in the code by inserting MC ZPOWER ON and MC EXECUTE xxxxx,1 and do away with the MC PRIME xxxxx,1

I would advise additional checks and management of any PLC signals that are needed to start again with.

You cannot do anything like that in a main program, unless you use interrupts (See ON and ONI and IGNORE in the AS Manual) and cycle start is still enabled.

But in the event there is a robot fault, cycle start is likely to be disabled and possibly motor power and 'something else' would need to motor power on and cycle start enable again.

In any of my applications, I have process faults (waits until a signal or timeout occurs), robot errors or safety activations I monitor for in a PCTASK

Emergency or Safety activations - clear and then continuance or auto recovery and wait.

Process faults - pause the robot - allowing for either continuance based on a loop re-check of conditions, or auto recovery and wait.

Robot errors - I reset if they can be cleared, then continuance, if not, then auto recovery and wait.

You're welcome, just providing some pointers which you may decide to pursue as alternative solutions.

I don't personally 'push' auto recovery on my clients and try and steer them down the manual recovery route as there could be scenario's where the auto recovery is found to create problems and it's usually because operators become reliant on the auto recovery for EVERY and ANY circumstance and totally forget about manual jogging to home as a safer solution.

Including where they manually jog the robot to a position outside of sequence lets say to get to the gripper to check it or other maintenance reasons, so I try and ensure not only a home auto recovery, but a maintenance position too where applicable.

Lots to think about, but try not to overcomplicate things, Keep It Stupid Simple.....or KISS it for short.