Posts by HawkME

    This has been discussed many times before on the forum if you search for recovery routines.


    A simple and effective way to recover is to analyze the current position of the robot and then choose a recovery path.


    You must create a recovery path for each different scenario the robot can be in. In your case that may be one for each fixture. You will want to decide what to do with the part if one is in the gripper. Also you will want to detect if you are not in a valid recovery zone and can't safely automatically recover.


    The zone you are in can be detected several different ways (LPOS/JPOS, DCS, Ref Pos).

    A picture might help to understand. If the robot is holding all of the load of your tool then why would orientation change the pressure applied?


    A mechanical solution would be a much better way to go. There are also software options to apply a constant force with a force sensor.

    When you install RoboGuide it allows you to select what controller software versions you want to include. I don't think it goes earlier that 6 on RoboGuide. You could try that or possibly there is an older software available.

    The W,P, and R angles are actually Euler angles. They are not always going to be an intuitive value depending on the orientation of the robot.



    Can you tell us your what you are trying to accomplish by reading the angles? Maybe there is a different solution.

    I use a combination of TP Programming on the pendant and using the same TP programming language in a text editor.


    I agree with Lemster68, first and foremost you need to be able to work on the pendant. Then if you do offline, it's best if it's the same language as the pendant so you don't have to context switch.


    When an assembly line is down, operations doesn't care if you know ROS or c++, they care how quickly you can get the machine running again. The fastest way to troubleshoot a down robot is through the pendant.

    I have seen that before and think it is a bug in RoboGuide. I don't know a way to fix it, but you could store user frames in PRs and then have a small program to set a UF = PR. Then you can have many frame definitions saved that you can load as needed by calling that program.

    That's good.


    Still start by taking image and AOA backups of each robot.


    Then you can restore from the other completed robot.


    After that you will want to load the correct mastering counts. If the new robots were already mastered you can simply load the sysmast.sv file from your AOA backup. If not then you should enter them manually from the original data sheet. After mastering, take reach robot joint to 0 degrees to verify mastering is correct.


    Then go into the system variables and enter the correct robot F#.


    After that is completed you can do your list of things above (tool, frames, vision, etc).

    Do what you think you will enjoy more.


    In my region of the US it seems that in demand trades sometimes make more money starting out, but engineering has a higher top end and more flexibility to move into different career fields.


    Engineering also tends to involve a lot of other non-technical aspects, such as project management and people management. While Robot techs and electricians tend to stay much more focused on technical hands-on work.

    A search algorithm, like Hermann mentioned will work but can be somewhat slow on a Fanuc to process. A lookup would be better.


    You could create an array of position registers where the index # is the search value, and the X and Y value of the PR are your two return values. It is kind of a trick to get a multi-dimensional array. You would need to go into a controlled start to increase the number of PRs available, then enter them all. Alternatively, you could do the same with regular points in a dummy program.

Advertising from our partners