Homing filosophy with Fanuc

    Quote from TomFoolious

    This is good information, but I'm curious about a couple things: I get using DCS Zones to see if robot is here or there, but once you've determined you are inside that DCS zone are you then using LPOS to see where the robot is inside that Zone? How are you determining then where the robot is compared to the programmed position(s) to bring it home? Do you query each point of the program and see how close LPOS is to each point? Saying that out loud to myself sounds silly, so I know I'm missing something very obvious...Thanks for any input you can/may provide. I'd love to replace my lazy use of the breadcrumb trail (i.e. register setting). I definitely have seen where it can fail to do its job.

    I have posted a sample R_HOME logic macro that answers your question . Only difference is that instead of DCS I use a BG logic routine to continuesly scan TCP location and activate certain DOs depending the location. You don't need to worry about the programmed positions but only for the current one. Using LPOS to save the current position and Linear move for exit move your TCP orientation will not change so you dont need to worry about crashes when exiting from a tight spot (provided you have programmed a correct exit move).


    For the application that this macro takes place there are effectively 3 zones I need to look out for: a Barrel fixture, a feeding table and a double rotary wheel. When robot moves inside one of the 3 zones, BG logic activates the specified DO. If any of the specified DOs are not activated it means that the robot has a safe distance away from any fixture, so a simple JOINT move to P[1:Home] is safe and the robot need not check anything.

    Tom, just as the last 2 posts have said.


    You create enough DCS zones (or LPOS "zones") to handle each situation needed. I prefer DCS zones because they can be seen visually on the teach pendant so are easier to setup in my opinion, but they achieve the same result as checking the LPOS.

    Quote from HawkME

    Tom, just as the last 2 posts have said.


    You create enough DCS zones (or LPOS "zones") to handle each situation needed. I prefer DCS zones because they can be seen visually on the teach pendant so are easier to setup in my opinion, but they achieve the same result as checking the LPOS.

    Right, sorry I missed that as I skimmed through. Too bad my current robots have neither DCS nor 4D (it's a very strict budget project...) I can get creative with the basic interference check I twisted their arms to get for the robots possibly or setup all the LPOS boxes...Thanks for the information.

    Quote from TomFoolious

    Right, sorry I missed that as I skimmed through. Too bad my current robots have neither DCS nor 4D (it's a very strict budget project...) I can get creative with the basic interference check I twisted their arms to get for the robots possibly or setup all the LPOS boxes...Thanks for the information.

    Pay 2 minutes trouble to read my orginal post :winking_face:
    You don't need DCS, only a well defined BackGround Logic routine to check your TCP location. Use Diag_GRP[1].CUR_TCP_X, Diag_GRP[1].CUR_TCP_Y, Diag_GRP[1].CUR_TCP_Z system variables. Use your own DOs depending the TCP Location. Create a home routine and use those DO signals to safely exit any danger zone (defined in the BG logic) and return home. BG logic will constantly update those DOs based on its current TCP location. Each time you will call your Home routine, the robot will use some branch logic (IF-ELSE) based on the signal ON from the BG LOGIC to decide the exit strategy and safely return home. You can even use CUR_TCP_W, CUR_TCP_P, CUR_TCP_R which represents your TCP orientation to better define your danger zone. Or you can use Space Function which is a standard function although I find that creating my own Space Function is a lot more reliable than the embedded space function that has a lot of bugs (especially when using continuous turn axis).

    This is a sample code that defines 3 "hazard zones" for my robot and constantly checks for them.



    IF ($DIAG_GRP[1].$CUR_TCP_X<1050) THEN

    DO[4:ON :out of space wheelstabl]=ON

    ELSE

    DO[4:ON :out of space wheelstabl]=OFF

    ENDIF


    IF ($DIAG_GRP[1].$CUR_TCP_Y<700) THEN

    DO[35:ON :out of space bench]=ON

    ELSE

    DO[35:ON :out of space bench]=OFF

    ENDIF



    IF ($DIAG_GRP[1].$CUR_TCP_X<(-90) AND $DIAG_GRP[1].$CUR_TCP_Y<(-700)) THEN

    DO[3:ON :out of space barrel]=OFF

    ELSE

    DO[3:ON :out of space barrel]=ON

    ENDIF

    Quote from PetrBroza

    Does $DIAG_GRP[1].$CUR_TCP_X work when robot is jogged? Somewhere else on the forum someone mentioned that it only works in auto.

    It always works, but you can copy paste the code to a sample bg program on your own teach pendant and test it for yourself by splitting your screen in double and have one screen switched to Digital Output Monitoring. Jogging the robot must switch the defined DO's on and off when exiting/entering the zones you create.

    Gotcha, yes that makes sense. And the nice thing is it will always update and an operator or inexperienced user can't just turn off or on one of the outputs used, so therefore it makes it idiot proof, for lack of a better term.

    Quote from TomFoolious

    Gotcha, yes that makes sense. And the nice thing is it will always update and an operator or inexperienced user can't just turn off or on one of the outputs used, so therefore it makes it idiot proof, for lack of a better term.

    You can better encapsulate a Home routine by declaring it as a MACRO and binding this macro to an SU key of your teach pendant. (Operator can then use Shift + SU key shortcut to bring the robot home. This is provided you don't use a PLC, which is even easier to bind the Home macro to a DI signal and just create A BIG BIG HMI button reading: "HOME" or "H-O-M-E !!!" or "HOME4DUMMIES"

    Quote from PetrBroza

    I see one problem with Diag_GRP[1].CUR_TCP. If someone change the tool or frame for whatever reason, it will give false results.

    if someone changes the physical TCP (meaning the actual tool currently mounted on the robot) without updating the robot's TCP values or falsely enter wrong TCP values for the currently mounted tool of course it will give false results. But this practice is false by definition.
    When you program and commission a robotic application you need to box and encapsulate certain critical tasks like TCP value assignments. Changing a tool is obviously associated with updating the TCP values to reflect the specified tool and those tasks must always be automated in the background and hidden from the operator.

    Agree. Can I force Diag_GRP[1].CUR_TCP to use certain tool and frame, or it's just using current tool/frame?


    For example on ABB, you can specify tool and frame for getting LPOS, so it doesn't matter if someone chose wrong tool.

    No you can't. It monitors the current TCP and this is really the way it SHOULD work. You can change the current TCP by pressing SHIFT+CORD button and selecting a new number near TCP but you really shouldn't. What you should do is make different routines to update the TCP values based on the different programs and tools, and run them each time you run your program. You tie each program to the tool it uses. If you have diferent tools you can create different TCP programs containing only the TCP values saved to specified PRs.

    I have 5 different tools each containing different TCP values representing the TOP, Bottom, Center, outer side middle, inner side middle. For every tool, I use a seperate TP program and store each representation of that tool in specified PRs. Now depending the tool each of my production programs use, I bind the correct TCP program call inside the production program. This way I make sure each program will always use the correct TCP values + I encapsulate critical tasks such as TCP values away from the operator.

    Thinking it all through I have some concerns going this method though...Let me ask the question: Have you (ps0f0r) ever had issues with any end user getting stuck or not understanding how the robot goes home? I'm asking because I feel like, even though breadcrumb trail isn't always the best, it would be better(?) for troubleshooting with Maintenance personnel? What are your experiences with that? I'm thinking at least with breadcrumb trail anyone can pick up the TP and read, "JMP OK...goes to this label here ok...then it jumps to home position and goes there, ok..."


    Maybe the point is, don't let them have to think or read anything - just work?


    Have you had any experience with customers who may not be as experienced with robots, but plan to add equipment or processes later on that would require them to make additions to the home routine? Are they on their own then to figure it out themselves? Pay you more money to come out and add stuff in? Just asking out of curiosity because my mind is sometimes a dumpster fire of What If's :grinning_squinting_face:

    I dont leave such decisions on operator personnel. The robot operators only deal with the HMI and the controls I have implemented through the PLC. I dont even let them choose the production program or cycle start. I use recipies that directly store every variable the robot needs, to choose the correct program.

    Recipies take care 90% of the decisions. I also use RSR services to start the robots remotely. When the operator loads the desired recipe, the RSR program goes through a switch case logic to decide which production program to start based on the selected recipe. All this does not require any particular experience on robots.

    If you check my original post, the Home routine uses a pretty sofisticated branch logic to decide how to go to home based on the cell's current equipment. This way the operator only needs to know how to navigate through the HMI pages and press "HOME" to home the robot. It goes without saying that when you add a new fixture or equipment inside the cell you will also need to modify your background logic to add one more danger zone and your home routine to calculate one more exit move based on the new equipment/fixture added.

    Usually, when a customer needs to make additions to a cell they always contact their intergrators. If an employe of a company has the skills to modify a robotic cell by adding new equipment and integrate it to the system (=integrate it to the machine controller/PLC controlling the system) I can assure you he can modify the home routines too, or easilly learn how to do so.

    They can add as many processes as they want as the home routine is not subject to the currently running program but only to solid fixtures and equipment inside the cell.

    Quote from ps0f0r

    I dont leave such decisions on operator personnel. The robot operators only deal with the HMI and the controls I have implemented through the PLC. I dont even let them choose the production program or cycle start. I use recipies that directly store every variable the robot needs, to choose the correct program.

    Recipies take care 90% of the decisions. I also use RSR services to start the robots remotely. When the operator loads the desired recipe, the RSR program goes through a switch case logic to decide which production program to start based on the selected recipe. All this does not require any particular experience on robots.

    If you check my original post, the Home routine uses a pretty sofisticated branch logic to decide how to go to home based on the cell's current equipment. This way the operator only needs to know how to navigate through the HMI pages and press "HOME" to home the robot. It goes without saying that when you add a new fixture or equipment inside the cell you will also need to modify your background logic to add one more danger zone and your home routine to calculate one more exit move based on the new equipment/fixture added.

    Usually, when a customer needs to make additions to a cell they always contact their intergrators. If an employe of a company has the skills to modify a robotic cell by adding new equipment and integrate it to the system (=integrate it to the machine controller/PLC controlling the system) I can assure you he can modify the home routines too, or easilly learn how to do so.

    They can add as many processes as they want as the home routine is not subject to the currently running program but only to solid fixtures and equipment inside the cell.

    Thank you for the response. Sounds like a good practice to get into. Will definitely start a slow transition to a system like that (at least on the robot side for what I'm responsible for) going towards the future. I've been looking for something new to tryout!

    I'm more with Karel (or a combination of Karel and TPE).
    I have set up a set of work- zones. In addition I also use TPE- registers for checking which part of the job the robot is working on (Not the single motion).
    In my case: Palletizing; Simplified: Part jobs are 'Get product from pickup' and 'Put product to pallet'


    When starting up I check at which zone the robot is. Depending on the zone i use special routines to move the robot to a safe zone where he can start up.
    When the 'homing' is done, I start the standard routines, but giving them the information at which part of the whole job the robot was stopped.


    Takes some time, but it is safe...

Advertising from our partners