It seems you're right again Colin. I was overthinking the issue. In my last attempt, I was still relying on the log hand to get my subroutine and then forcing the canned cycle on to get get the additional points. When I suppressed the merge and clear, I realised that I was getting two separate subs with the same# in the ext file. That's why I was getting the error that I was. You're the man sir!

I'm using the Mpmaster docs one a post modified from the mpmaster.pst. It won't let me merge an .aux or .ext either.

Output like a standard call for subroutine: N81M01( -.4724 DIA- 12MM LOW HELIX DRILL ) (MAIN CHANNEL PREP) G0G17G40G49G64G69G80G90G53Z0M5 T2008M06( -.4724 DIA- 12MM LOW HELIX DRILL ) T102 G0G90G17G54X5.968Y6.4596S2500M3 G43Z1.H8M8 G8P1 M98P2290 X11.2936Y6.7661 M98P2290 X16.9564Y6.7661 M98P2290 X22.2779Y6.4173 M98P2290 ...etc...... M30 O2290( DRILL SUB, ONS_ROW4_ACB REV1 -OP2) (N81 T8 -.4724 DIA- 12MM LOW HELIX DRILL) G90 Z.5 G1Z-.5F75. G0Z.5 Z-.47 G1Z-1. G0Z.5 Z-.97 G1Z-1.5 G0Z.5 G0Z1. M99 This cannot be done using G83 long hand function.

Bear with me X9 guys. We do not use canned drilling cycles on our routers. Mostly because the cycles run faster in long hand, but it gives me more control on what the tool is doing on the back end. Deep holes in particular. That's just how it is going to stay on the router. The operators prefer it, and so do I. It is not an issue on the mills and lathes because they can flood with coolant when needed. Having said that, Mastercam does not convert the custom drill cycles to long hand. That's fine because I wrote my own code for them anyway. The way the built-in subroutine function functions does not work so well for the long hand drill cycles just plain doesn't work me, as it generates a crapload of code that negates using it in the first place. We try and keep the file sizes as small as possible. We've had to use the transform function to generate the pointes and a single subroutine with only the plunge depths. I was able to create a custom drilling subroutine function that allows me to select all the points on a single operation and outputs the code as stated above. The problem is that it work flawlessly with the custom cycles, but refuses to perform on the long hand conversions of standard drillcyc$ 1-7. Mastercam tells me that I cannot merge a subroutine with itself when posting. Apparently, Mastercam flags the longhand code as a subroutine. I've tried turning on the the canned cycles and writing the code by hand and anything else I could think of to no avail. I cannot find anywhere in the mpmaster docs how the conversion to long hand is handled. Does anyone have any idea how to trick the software into letting me use the custom code on the canned cycles?

Without seeing your specific post, I do not know exactly how it is formatted. This is how I solved it for my ST30. Ordinarily generic posts put the 'if millcc' call to the pmillccb(a) conversion process before the the first position is called from the mtlchg$ post block. Move the millcc call after the position call as demonstrated here and see if that solves it. I had to make some changes to the pmilccb post block, specifically for my machine, but it appears that you have that handled already. toolno = t$ * 100 + tloffno$ pbld, n$, *sgcode, *toolno, ptoolcomment e$ #pbld, n$, pfsgplane, e$ #Turn off to set plane manually in mill operation pcom_moveb #Reset machine position, set inc. from last position pcaxis_on_m #Postblock for mill transition pcan sav_absinc = absinc$ xabs = (xa + dia_shift) * dia_mult # if millcc, # [ # pmillccb #Set mill conversion # pmillcca #End mill conversion # ] if home_type > one, absinc$ = zero pcan1, pbld, n$, *sgcode, if mdrl_dir = 1, pbld, "G19" else, pbld, "G18" pbld, pwcs, pyout, pfcout, pfzout, strcantext, e$ pbld, n$, pfxout, pscool, e$ pindex pspindle prpm pcom_movea #Update previous, pcan2 ps_inc_calc #Reset current absinc$ = sav_absinc c_msng$ #Position single-tool sub, sets inc. current if G54... toolchng = zero #mill_tool = 0 if millcc, [ pmillccb #Set mill conversion pmillcca #End mill conversion ] !xnci$, !ynci$, !znci$

Also, after looking at the subout$ setting, I realized that the output is being forced to zero at the start of the header, to three at the end of the header, and then back to zero at the end of the sub or file.

Thank you Colin. That was very informative and I will probably take your advise, but I will play around with it later for curiosity's sake. Between you and Tim I think there is a lot usable info here.

You're right. Creating a different machine def, control, and post would be one heck of alot faster and simpler. I'm attempting to idiot-proof the process long term. We're going to be adding three more facilities in three different states over the next couple of years. We're so busy right now, that we are getting behind. And yes, I have my own workload to do, too. Again, thanks for all of the help.

That's the plan, but writing it back to the parameter seems like it will have to occur in the header before the start of the file. How do I actually write to the parameter?

It should. One last thing. Since I now know I was off in the wrong direction, how do I overwrite that parameter and force it to switch between before/after?

Thank you Tim. Can you possibly tell me what value range this parameter should be when read? My variable always seems to be zero. Maybe, since I have never had to worry about reading/writing parameters, I'm just not doing it right. I'm not getting any errors. I borrowed some code from mpmaster. I am using rd_cd$ to to store 18713 in a variable in a table. I should mention that I am using Router, not Mill. The original pst what created in Mastercam 8, then v9, then X5 and finally X9. Everything works, and a lot of functionality was added. variable definition: # -------------------------------------------------------------------------- # General Output Settings # -------------------------------------------------------------------------- wheresub : 0 #Read param 18713, sub before/after main program # -------------------------------------------------------------------------- # Parameter read postblocks: # -------------------------------------------------------------------------- pprep$ #Pre-process postblock - Allows post instructions after the post is parsed but before the NC and NCI file are opened. param_read$ = 1 rd_mch_ent_no$ = 0 #Read only the machine base parameters (use to collect common parameters from CNC_MACHINE_TYPE) #rd_md$ #Read machine definition parameters # Control Definition Parameters fprmtbl 2 1 #Table Number, Size # Param Variable to load value into 18713 wheresub # -------------------------------------------------------------------------- pset_mach rd_cd$ rd_tlpathgrp$ # Read toolpath group parameters - calls pmachineinfo$ rd_prm_op_no$ = op_id$ rd_params$ #Read operaitons parameters # -------------------------------------------------------------------------- # Machine definition and control definition parameter capture: # -------------------------------------------------------------------------- pmachineinfo$ #Machine information parameters postblock #Read parameter lookup tables - if prmcode$ >= 18000 & prmcode$ < 19000, result = fprm(2) #Run the parameter table for Control Definition Parameters Again, any and all help is greatly appreciated

Fellow programmers; I am trying to configure a post for use at multiple facility sites. I know that the control definition sets up subroutines to post out before or after the main program. Can anyone tell me how to change that setting from inside the pst? Is there a variable, a parameter, or something that I can use to switch back/forth on the fly? I've changed the setting in the control and compared the NCI files, but I cannot see anything that indicates where it happens. Anybody? Any help will be appreciated; -PMC