Fanuc Robot Macro Programming

[Toney Talbot]

If I assign one to a DI, does that mean whenever I get that DI it calls that program? Like could I assign a GO_TO_MAINT program to a DI and when ever the robot receives that DI it goes to maintenance position? Does a macro input tender always run in the background?

often times i used macros with no group selected to operate stationary cameras running vision processes while the robot it off doing something else. maybe find the next part to pick up before the robot even gets there.

If I assign one to a DI, does that mean whenever I get that DI it calls that program? Like could I assign a GO_TO_MAINT program to a DI and when ever the robot receives that DI it goes to maintenance position?

Yes you can do this. I am using macros to control my conveyors as well as start a vision system program I have. When the DI = ON it runs the program that it is mapped to. You can set the macro to run on a few different inputs such as TP key, operator panel button, or input signal (DI,UI, ect).

Moosehorns, I am in the same camp as you, we don't want people other than programmers or maintenance touching the pendant. Also, we provide an HMI for a user interface. So in my situation Macros have no benefit. I can accomplish anything required using a combination of regular programs and BG Logic.

I find it funny that you say Fanuc is proud of the macro, when I find BG Logic infinitely more useful, but you never hear Fanuc talk about BG Logic. It isn't even taught in their Advanced programming course.

At my facility we use aux axis for dial tables and trunnions. We put the positions in the macro table and call the program via DI. This way the arm can be off doing something else, and the Aux Axis and get into its operator load position.

I use macros for some of my more elaborate EOAT setups. Multiple actuators with 2 or 3 brief WAIT instructions. Pack it all into one MACRO so each time I need to pick up or drop off, it is one line to call the appropriate MACRO instead of 5 of 6 lines of code.

I have an arcmate that welds some components together. Every now and then the tip 'burns' up and and wire can no longer feed through it. The operator has to call maintenance to come over, raise the tip up a few inches so they can get the nozzle off to get to the tip, they put it back and auto and walk away. The operator swipes the go button to continue.

If I understand it right, I can call a macro from a DI anywhere in a program??? So I could write a very simple macro to offset the current position a couple inches in Z, pause, then jump back in the program that was running and carry on. Put a button on the HMI that operator can press and cut out the downtime waiting on a maintenance guy. Is this the way it would work?

That will not work. The macro cannot take motion control because it will already be locked by the main program. In order to run a Macro with motion, you would need to completely abort the main program. Then it would be difficult to get your main program started back in the correct state.

What if you check the status of a flag in the beginning of the program?

If flag = ON, go to "maintenance position" and pause?

What happens when the tip burns out, will the robot just follow the program without welding or will it come to a stop?

seems like you will be better off by using Error Recovery Function. The Error recovery feature allows you to create a routine that will run whenever an assigned alarm code is generated. I.e. when you get an arc start failed (Alarm Code 53-013) the robot will run a program in the background to bring the robot to the maintenance position,where it will pause until the tip is replaced. Once the tip is replaced the robot will resume and go backwards through the path to its faulted point, then continue welding.

So, having done some TP and KAREL coding, I have a general sort of question about Macros. Basically... why? I mean, what do Macros have that regular TP programs don't? Are they just a leftover from a bygone age, or do they still have real advantages that make them worth using?

To start on answering my own question, I can see that Macros can be called (asynchronously?) from a DI, or triggered to execute as a Manual Function. And a Macro can be CALLed from inside a TP program just like another TP program, or with a 'handle" that isn't limited to the standard naming scheme of TP programs. So I can see where that could be convenient at times. But I'm interested in the experiences of people who spend more time in Fanuc-land than I do. Do you like Macros? If so, why? What keeps you coming back to them? When and why do you use them instead of regular TP?

I should have included the reason for why I wanted to know about the macro. I have a very large vacuum gripper that I need to put J4-J6 in a safe position before the robot moves any of the other axes. Would a macro be recommended? Although, I am using UF's for all my machines in this cell so I will probably need a program for that because I will need to change UF's for the desired motion, I think.

Tool controls programs from the UK inputs, yes, but the other thing I have used them for is without a PLC for instance if someone pushes an ENTRY request button I dont want to do anything now but I do want to set R[6:entry req] = 1.

Years ago, KAREL was also used for advanced motion programming, but these days FANUC has mostly deprecated that functionality. They've also been adding features to TP over time, narrowing the gap (at least slightly) between KAREL and TP.

KAREL code can also be rendered "invisible" -- a FANUC controller can export the ASCII versions of TP programs, but not of KAREL programs. Thus, orgs that want to write proprietary code to run on FANUCs without exposing the source code can write and ship compiled KAREL binaries.

Description:The Custom Macro Programming course provides practical instruction in the development and troubleshooting of macro programs. The fourth day provides enhanced troubleshooting scenarios and programming exercises.Topics covered in this course include:

Course Benefits:

At the conclusion of the course, students will be able to develop Custom Macro programs to reduce cycle times, increase automation and improve efficiency of programming. They will also be able to read, troubleshoot and simplify existing programs.

How often have you seen a set of macros called GRIP_OPEN andGRIP_CLOSE? What does that mean? You might assume that GRIP_CLOSEwould grip the part and GRIP_OPEN would release it, but what if thegripper expands within the part to grip it? GRIP_ON and GRIP_OFF area little more clear, but I typically use GRIP and UNGRIP.

Try and reduce your problem into its main operations, then break thoseoperations into even smaller subroutines. I had a project recentlywhere the robot had to be ready to perform any given operation dependingon the current state of the cell. I broke the requirement down into itstwo main parts and then broke those parts down into smaller chunks:

Before you can start programming your robot offline, you need to decide which offline programming software you will choose. You also need to be clear on the steps you should take once you have chosen your software.

The first step to getting your robot up and running with offline programming is to load your robot model. With RoboDK, this is simply a case of opening the Robot Library, filtering for FANUC robots, and selecting your specific robot model. This will load it into your simulation space.

This article describes the Fanuc user frame program commonly used in surface treatment and dispensing applications.More information about the logic of this program can be found in the robot-independent surface treatment and dispensing article.

In surface treatment and dispensing applications, the robot trajectory is based on the location of a user frame.This means that trajectory following programs can be reused quickly following changes in the pose of the part.When the part is shifted, only the user frame has to be updated.

If an object is found, User Frame 1 is updated based on the object pose. Then the user can stop the program and teach the desired trajectory poses PR[10],PR[11],PR[12],PR[13] w.r.t this user frame. Run the program one more time whithout moving the object to check if the trajectory poses are saved correctly.

If an object is found, User Frame 1 is updated based on the new object pose. Then, the macro PI_RG_REAC is used to check if the trajectory poses are still reachable w.r.t the updated user frame.

Make sure that User Frame 1 can be used before running the example program.Note that teaching the user frame is not necessary since it will take the value of the object pose when running the programs.

To avoid production downtime, it is recommended to add a collision recovery in the robot program.That way, if a collision is detected by the robot while trying to follow a trajectory, the robot does not raise an error requiring an operator intervention.Instead, the robot goes back to the detection and try to process another workpiece.

In Fanuc, this is done using the Skip instruction.If a condition is met, the motion is interupted.By using a condition of a joint torque being above a certain threshold, one can catch collision before the raise an alarm.

3a8082e126