Having an issue with Creating a HOME_RETURN PROGRAM with Multiple JMP LBL's.

I'm not really sure what you mean about adding multiple JMP LBLs in the same line. A JMP LBL is basically a GOTO statement; you can't jump to two places at once.

Line 12 is completely irrelevant to your program; if your logic on line 12 is true then line 12 jumps to lbl[3], if it's false then you jump to lbl[3] on line 13. Either way, nothing between line 13 and lbl[3] will be executed.

As far as having limit faults trying to go home, generally you'll want to do a linear move to safely clear the workpiece and then a joint move for the move home.

On lines 12 and 13 I noticed that they both have JMP LBL [3]. So whether it is greater than 1800 or not it won't matter because either way it is jumping to label 3 and skipping line 14. I would assume this could have something to do with why you're hitting limit faults because no matter what you're jumping to line 15 and 16 moving to PR1 without ever executing line 14.

EDIT* I typed this out a little over an hour ago and got called off to fix something and just came back and hit send. I didn't see where TitusLepic had already pointed out the mistake.

Quote from TitusLepic

I'm not really sure what you mean about adding multiple JMP LBLs in the same line. A JMP LBL is basically a GOTO statement; you can't jump to two places at once.

Line 12 is completely irrelevant to your program; if your logic on line 12 is true then line 12 jumps to lbl[3], if it's false then you jump to lbl[3] on line 13. Either way, nothing between line 13 and lbl[3] will be executed.

As far as having limit faults trying to go home, generally you'll want to do a linear move to safely clear the workpiece and then a joint move for the move home.

I'm wondering if line 14 is an intermediate move to get to a safe position to then move to PR1 and since it is never executed the robot tries to move straight to PR1 resulting in the limit error.

So you need the home_return program to figure out where the robot is in 3D space, move a safe direction/distance to clear any obstacles, and then go home without hitting a limit.

I've never used DCS, but if I understand it right from what I've read, you can set up 3d zones in your cell that will turn on an output when the robot is in that particular area. If you have DCS I think that would be the easiest way, just check what output is on and call the appropriate motion to clear your obstacles.

You can also do what you're doing now; grab the the LPOS x, y, and z and use lots of conditional branching to determine what home path to call

The third way is to use a register in your main program and update the value as the robot moves to different areas. For example

R[1] = 0

move somewhere

R[1]=1

move some other place

R[2]=2

etc

then use a SELECT statement at the beginning of the home_return program to call the right homing routine

SELECT R[1] = 0 JMP LBL[1]

=1 JMP LBL[2]

=2 JMP LBL[3]

ELSE JMP LBL[4]

I would be having a talk with your maintenance department for sure! But as TitusLepic suggested using data registers is a great way to prevent this. Another idea would be to also make the move to home a little slower and call a collision adjust right before hand so if there is a mishap it won't cause much, if any damage. You can always readjust the collision detect immediately after it is home.

To add, for a temporary quick fix while you work on the other program changes you could always add in a line at the top of the main program to wait until the "At Perch" output is on before executing the main job. That'll force them to take the robot home manually before being restarted after an abort all and give you a bit of "peace of mind" while you work to correct the issue permanently.

Quote from srtautomation

This was due to MAINT pressing Abort all and then pressing cycle start on the HMI.

The 1st call program in MAIN is PR[1:HOME POSITION] so the robot took the shortcut back home- Causing Chaos!

I've had this issue before and it is no fun. I did the same things motioned above: LPOS and monitor DCS and/or reference positions to figure out where in space the robot is and how to get it home.

On one installation with 4 motion groups in a rotisserie setup:

1. The operator needs to get the robot or other axes home after an e-stop condition or something else that left them in a place other than home

2. Abort all is required. This is done to prevent the HOME program from running (or possibly running) every time the loop restarts as this cell is pretty complicated.

4. The operator presses a button on an HMI screen to run the HOME program

4. Monitoring UOPS (if I remember correctly) will show that the robot has been aborted and will allow the HOME program to execute

5. Monitoring system variables, if the robot has been jogged by a human since the last motion instruction, the HOME program will end and display a screen that says the robot or another axis has been jogged and will have to be moved home manually. This is done to get the robot home from a general area where we can expect the robot to be during normal operations. I was unable to account for all the possibilities the robot may have been jogged to. The other 3 motion groups were rotary and fairly easy to get home.

6. Operators and maintenance are instructed to never jog anything on this cell unless they have tried to abort and run the home program. One of the very few times an abort all is encouraged.

Hope this helps...

You don't necessarily need DCS zones set up to adjust the collision detect within a job. Add in a line before it calls the move home such as "COL GUARD ADJUST 130" and it will adjust it on the fly. Just know that your payload settings must be properly setup or this will just cause issues for you. But you can do this anywhere in the program so if you want to decrease the sensitivity after it's home write it back in as "COL GUARD ADJUST 100" which is default or whatever it is you want it at.

I have used the register method to get home, and it works pretty well. There are some gotchas though:

* if you jog the robot, the register will be rendered invalid -- this is where monitoring the system variables comes in handy

* you have to make sure if you execute a motion instruction in teach mode, that you execute the register set instruction as well, or the home job will likely not do what you intended.

I haven't tried this, but a way to address the second issue is to use the DB tag in your motions, for example:

L PR[1] 50% CNT100 DB 0.0mm, POINT_LOGIC

R[1] = 1

The DB stands for "distance before", and setting this to 0 means perform the action when the robot reaches the position--not sure how this works with CNTx motion though.

POINT_LOGIC is a way to insert instructions inline.

I use J1 Like this:

! turned toward outbound conveyor

if R[20:Jpos1] > 120 Jmp Lbl [100]

! @ winder

if R[20:Jpos1] > 90 Jmp Lbl [200]

! @ buffer conveyor

if R[20:Jpos1] > 0 Jmp Lbl [300]

! @ Pick pallet

if R[20:Jpos1] > -45 Jmp Lbl [400]

! Not sure where I am. Job me please!

Ualm[2]

Lbl [100:@ outbound cnvr]

if R[32:LposZ] < 120 Jmp Lbl [150] or what ever checks are needed for that area

PR[30:Lpos,3] = 120 Often normalize Z to a point that will clear area

J PR[30:Lpos] 4000mm/s CNT 25

Lbl [150]

j PR[1:Home] 4000mm/s Fine

Jmp Lbl [999]

Lbl[200:@ Winder]

ETC... Different checks for each area

Jmp Lbl [999]

ETC...

Lbl[999:Done]

Quote from smurrill73

I have used the register method to get home, and it works pretty well. There are some gotchas though:

* if you jog the robot, the register will be rendered invalid -- this is where monitoring the system variables comes in handy

* you have to make sure if you execute a motion instruction in teach mode, that you execute the register set instruction as well, or the home job will likely not do what you intended.

I had argued with PLC guys, project manager,electrician, etc (Basically everybody that has no clue about robots) that this "Home return" function is ONLY when the robot is in auto mode. Once the pendant goes into manual mode game is over, no buts....

Therefore those gotchas should never ever happen