One of the major benefits of custom macro B, especially with part family and user created canned cycle applications, is the ability to change the criteria for how the custom macro should run. This is done with input data, called arguments (though some people simply call them variables). This benefit gives a single custom macro the ability to use a bolt circle custom macro to machine three holes – or three hundred – based upon the current value of the number-of-holes argument. It gives a single peck drilling custom macro the ability to peck once or one hundred times, based upon the hole-depth argument and the peck-depth arguments. It gives a grooving custom macro the ability to groove with one pass or ten passes based upon the width-of-the-groove and the width-of-the-grooving-tool arguments.
The manner by which you specify input data to the custom macro is largely determined by the type of application you are developing. For user created canned cycle applications, you commonly want your custom macro to behave like any other canned cycle. For a machining center application, for example, and prior to calling the custom macro, you’ll want to change tools, start the spindle, make some prior positioning movement to get the tool up to the work surface, start the coolant, and instate tool length compensation. Only then will you call the custom macro.
The custom macro command that most resembles a canned cycle calling command (like G81) is the G65 command. With G65, you specify the custom macro program number to be executed along with a series of arguments. The arguments in a G65 command are letter addresses, and can include A, B, C, D, E, F, H, I, J, K, M, N, Q, R S, T, U, V, W, X, Y, and Z. (Note that not all the letters of the alphabet are available.)
The custom macro programmer will try to choose letter addresses that make sense (like D for depth-of-cut), but there are no rules in this regard. In the custom macro, the values of these letter address arguments are referenced with local variables. The custom macro section of your programming manual will specify the relationships (like #1 for A, #2 for B, #3 for C, #7 for D, and so on).
Again, the G65 command makes the best way to get data into a user created canned cycle custom macro. But it doesn’t work so well for part family applications, since the custom macro will be the main program. That is, only one program will be involved, and all activities – tool changing, spindle starting, approach movements, coolant activation, etc. – will be done in this single program.
The most common way to get data into a part family application custom macro is to use a series of common variables at the beginning of the program (in the #100 series). Each common variable will contain the value of an argument. Since the numbering of common variables doesn’t make much sense, you should include a message in parentheses that tells everyone what the argument represents. Here’s an example:
Again, the messages nicely specify the meaning of each variable. Without them, it would be impossible to know what each one is supposed to represent.
This part family method assumes the operator will be manually editing the values of each common variable when they go from job to job. You wouldn’t want to keep a separate program for each part in the family (with all arguments appropriately set) – doing so would defeat the purpose of using custom macro for part family applications. Again, only one main program will be used to machine all the parts in the family.
But in some cases, it doesn’t make sense to have an operator changing the variables every time they go from one job to the next. There may be many to change – or you may be worried that the operator might make a mistake. Another way to handle arguments in part family applications is to create a separate subprogram for each part in the family that only includes the #100 series arguments. Now there will be a separate program for each part in the family, but the (one) custom macro program will constantly remain in the machine. Here is an example:
The subprograms for this part family can now be created off line – and transferred to the machine with a distributive numerical control (DNC) system. Also, the messages next to each argument may not be so important with this method since it will not be the setup person or operator who sets them.
One last way I’ll mention to get data into custom macros is to use permanent common variables (#500 series). Like offsets, permanent common variables allow entry through the keyboard and display screen. They may not be convenient for all data, but there may be some times when you find them helpful. One reason they may not be convenient is that only some of them can to be labeled (the first ten) – and the label (with most controls) can only be four characters. So again, it will be difficult for people to be sure about what they represent.
I like to use them as system constants for part family applications. They are still arguments, but not among those I would want an operator to have to regularly deal with. For example, say you use a 0.1 inch rapid approach distance. But you’d like to have the ability to reduce this value (globally) once a job is up and running to save time. You could place a value of 0.1 in permanent common variable #500 and reference #500 during all rapid approach motions in your program. If and when you want to change the rapid approach distance, you have but one value to change.
Or maybe your part family custom macro runs on several machines. Any differences in how the machines are programmed may require the need for a different program on each machine. But if the differences can be handled with system constants, the same exact program could be in all machines (you’d have only one program to maintain). Say one machine uses M41 to specify the low range while another uses M23. You can use #501 to specify the range selection number and use M#501 to call up the low range on both machines. You must, of course, place a value of 23 in #501 for one machine and 41 in #501 for the other.
