When you develop a custom macro that will be used by others, you must give strong consideration to what will happen if they make mistakes when using it. As you know, Fanuc – and other control manufacturers – have developed a series of alarms that will catch mistakes made in G code programs. Consider doing the same with your user created custom macros.
My first suggestion is to consider input data (arguments) that people will use when entering information for your macro. If you’re having them use a G65 command, as would be the case with a user created canned cycle application, you should do one of two things with every argument. Either test it for inclusion (make sure it is set) or create a defaul tvalue.
Testing for inclusion:
Use vacancy (#0) to test whether an argument is included in the G65 call statement. For example, if X represents the X center of a bolt hole pattern, test #24 (the local variable representation for X) against #0. If #24 is vacant, generate an alarm, like this:
Maybe C represents whether coolant comes on (C1.0: on, C0.0: off). With this kind of argument, it may be better to set a default value. Maybe your company uses coolant most of the time, but you want your custom macro to handle the possibility that coolant is not being used for a given job.
Note that vacancy is not zero. If C is left out of the call statement, #3 will have no value(again, it is vacant). So if C is left out of the call statement (or set to anything other than zero), you can have your custom macro turn coolant on. If C0.0 is explicitly specified in the call statement, then hav eyour custom macro turn coolant off, like this:
IF [#3 EQ 0.0] GOTO 10
M08
GOTO 12
N10 M09
N12…
.
.
.
If you have your custom macro consider every argument in the call statement in one of these two ways, you can rest assured that once the function of the macro is begun, the custom macro will have appropriate settings for all input data.
Other potential mistakes
There may be countless things that people can do wrong when using your custom macro, and it may be impossible to catch every potential mistake. But you should at least try to incorporate error trapping for those mistakes people may be most prone to making.And of course, if someone eventually does make a mistake that is not being error trapped, you should modify your custom macro accordingly. Here are a few suggestions:
More about input data
In addition to setting defaults and checking for inclusion, there may be things you know a person could confuse about the input data you have them enter. You may, for example, expect a hole depth to be specified but the person using your custom macro may instead plug in an absolute position along the Z axis instead. Or you may know that a given input variable shouldn’t be over a given amount. Maybe you are having them enter the diameter of an end mill and you know that for the application handled by your custom macro, the end mill can’t be smaller than 0.5 in or larger than 1.5 in. Or maybe your custom macro necks a groove, and your user must enter the tool width and groove width. The necking tool width must, of course, be less than or equal to the groove width. Error trapping for potential mistakes in these regards would be relatively easy.
What else could go wrong?
Given your additional ability to access axis position, certain control panel switches,and offset registers from within a custom macro, you should be able to error trap just about anything else that could go wrong. Did the setup person enter a tool length and/or cutter radius compensation value into the appropriate offset? Is it an acceptable value? Is the position of the machine appropriate to perform the desired function of the custom macro? If it’s critical,will the machine be feeding at 100% during the machining operation (as is required when tapping)?
Again, there are lots of things you can do to ensure that your custom macro will behave appropriately, generating alarms if a mistake is detected that will cause it not to.
Comments