In our shop we use subprograms to handle certain operations such as threadmilling. We feed a Fanuc Subprogram parameters such as thread lead, thread major, etc etc and the macro figures the rest out. This way we can reduce the amount of code in our programs.
Here is an example of our macro to cut a certain thread
G65P9502A1C.45 D1 M1. U.005 R3.51 Z3.31 F.003
I have the subprogram in the right directory but I can not get the variable M1. to get passed to the subprogram. M is variable #13 for passthru on Fanuc Macro B. It appears all other variables pass thru to the subprogram without any issues. I am assuming the CSE is seeing the M and assuming its a M code and not a fanuc macro pass variable.
When I change my code to
G65P9502A1C.45 D1 H1. U.005 R3.51 Z3.31 F.003
and change the corresponding fanuc macro subprograms from #13 to #11, everything works as it should. Is there a way to "fix" the OOTB Fanuc CSE to read macro passthough variable "M" #13 correctly?
Also, is there some kind of tool bar I can open up to see the current macro variables? I want to double check the computations without having to rig up the output to an Xmovement to see if the numbers are right.
Your observation is correct. At this point in time M is not supported to become a parameter in the OOTB Fanuc.CCF. I do not know why yet, but this is the description of G65:
Calls macro defined in address P. The subprogram filename is determined using GMe_GetSubprogFilename(P).Uses GMe_MoveVariableBlock and GMe_ResetVariableBlock to store the current local variables onto the stackSaves parameters using argument specification I (ABC...) on stack #100200, #100300 depending on stack level. They will be moved to #0-#33 in the first line of the macro (O Metacode). GMe_SetMacroArgument is used In argument specification I the M parameter is not yet supported.Argument specification II is not yet supported.
You can either open an ER or get in contact with service or partner to customize that.
Thomas Schulz Siemens PLM Manufacturing Engineering Software