MayDay, You could look at the MPFADAL1.PST/TXT on the CD

It just sounded like this may have been the .SET situation in the initial v9.1 release. If running SP2, that's not it.

Andy, This just started ? What is the exact version of MC you are running -> v9.1, v9.1Sp1, v9.2Sp2 ?

quote: What i would like to know, is it possible to give 2nd option where MC takes me to point entry screen and use X-Y-Z values of point selected, instead of going thru Q2-Q4 ?? Quick answer is -> Yes, you can. The PST can call to run a VBS. The VBS writes the data is gathers into a file and exits, back to the PST. The PST then opens that file and reads in the data. This concept was what I had demostrated in the MUTLI_PST_VBS.ZIP (available on the Forum FTP) I took that basic concept and created the MP_GetPT.PST (an altered version of the MP_EZ.PST) that uses the Ask_For_Point.VBS Note: This VBS is a bit crude in that it ONLY allows you to select a POINT entity. I'm sure some to the VB experts on the forum can assist in adding to it. You can check it out in the MP_GetPt.ZIP available in the Posts area of the Forum FTP. Note that a couple of "hard-coded" data paths are required in the PST. These are defined in the StrVBS and sPRMfile string variables.

quote: I have a personal cell phone that I never use (pay-as-you-go plan). Ditto that ! Works out costing $15.00 a month and includes long distance. Toolfab, been there, done that! I sometimes keep the phone clipped to a strap on the backback I use to carry the laptop. O/T: Love those people with the laptop bags that say DELL on 'em (Read: steal me!) Anyway, one day I can't find it. Since I don't actually use it everyday, who knows what happend to it. Search the backpack, car, house, the dog's bed, etc = nothing. Next day I pull into the lot at work, grab the backpack as usual and swing it onto my shoulder. Hmmm, Swing the backpack onto... I know I'd backed in this exact same spot in the lot the last couple days. I walk back behind the car, look down and find the #^@&* phone laying in the snowbank.

Troy, You must have something else causing the problem. Using Mill v9.1(SP2) I can use this path successfully -> code: 90. Drive and subdirectory for NC files? C:mcam91millnctemptest me What does your line '90.' look like ?

The variable name is -> n_tap_thds

quote: No one suggested any reading material. I assume these posts are written in Visual Basic. Is that my starting point? Contact you MC Dealer. There is a Post Processor Reference Guide documentation CD that contains indexed searchable PDF files. Visual Basic.... Even though it is Basic "like", it's really a custom language for doing Post Processors. quote: RobMcD , more like C++. Not really... I can see your reasoning because of the special variable prefix characters (like *) used, except they don't have the same meanings as in C++ [ 01-27-2004, 10:27 AM: Message edited by: Roger Martin from CNC Software ]

Brian, In the CHOOKS folder, make copies of the MP.DLL and MP.TXT files and name them MP_MULTI.DLL and MP_MULTI.TXT

Surface, If it is a static NC folder destintation you are looking for, you can do this... In each PST there is a number question that allows you to specify the NC output folder for the NC files that PST produces -> 90. Drive and subdirectory for NC files? Setting a complete path as the answer for this line in the PST will overide the NC output path in the active system configuration. code: 90. Drive and subdirectory for NC files? d:mill9millnc

Check out the -> MP-TNC430.PST post on the CD code: # Product : MILL # Machine Name : GENERIC HEIDENHAIN # Control Name : HEIDENHAIN TNC-430 # Description : HEIDENHAIN MILL POST # 4-axis/Axis subs. : YES (NOT configured yet!) # 5-axis : NO # Subprograms : YES # # ---------------------------------- # Features: # ---------------------------------- # This post supports Generic Heidenhain 426/430 code output for 3 milling. # It is designed to support the features of Mastercam Mill V9. The "NOT configured yet!" on the 4-axis support means the basic 4-axis support postblocks and logic is there, but it is probably not configured/formatted to work on a specific machine - out of the box.

In most posts, you will find this 'arcoutput' option ->> arcoutput : 0 #IJ arc, 0 = IJK, 1 = R no sign, 2 = R signed neg. over 180 In the MPWSDMK30.PST the arc center outputs occur in the PARC postblock -> code: parc #Arc center output - IJ, arctype controls form if arcoutput = zero | do_full_arc, [ iout = i jout = j iout, jout ] else, [ if abs(sweep) <= 180 | arcoutput = one, result = nwadrs(srad, arcrad) else, result = nwadrs(srminus, arcrad) *arcrad ] If you wish to always FORCE output both I & J, on every arc block, you can add an "*" (asterisk) to the 'iout' and 'jout' variables -> code: parc #Arc center output - IJ, arctype controls form if arcoutput = zero | do_full_arc, [ iout = i jout = j *iout, *jout ] else, [ if abs(sweep) <= 180 | arcoutput = one, result = nwadrs(srad, arcrad) else, result = nwadrs(srminus, arcrad) *arcrad ]

Message for SODICK EDM users. Check out the MPWSDMK30.PST (It's on the CD) Try it - you'll like it...

quote: Roger, that's good info, I didn't realize that. Thanks! That's why I posted it I was sure that many "didn't realize that". quote: You'd prolly have to buffer the entire part, then pull what you need from that You can save off all the MI# and MR# values in a the program off into a buffer file. You would not need to buffer "the entire part". The MI and MR values are available in the PWRTT pre-read routine. But I'd always suggest to try to find a different way to do what I'm trying to accomplish to avoid doing that - unless that was the only solution.

Some may not realize that you have access to the Misc Ints & Misc Reals of the Operation about to be processed at the end of the current operation being processed. Example: Program with 2 tools. You've set MI10 = 1111 on Tool #1 You've set MI10 = 2222 on Tool #2 When MP processes the NCI, just before going into the PTLCHG (toolchange) postblock for Tool #2, it has read the Misc Ints & Reals that are set for Tool #2 The Misc Ints can be accessed in for this situation in the PMISCINT postblock and PMISCREAL for the Misc Reals. You can test this by adding this line into the PMISCINT postblock of the std MPFAN.PST -> "*-> mi10 = ", ~mi10, e # You'll see something like this -> code: N144G0Z.1 pzrapid prapidout 78 *-> mi10 = mi10 2222. pmiscint 84 N146M5 ptlchg1002 pretract 118 N148G91G28Z0.M9 ptlchg1002 pretract 118 N150G28X0.Y0.A0. ptlchg1002 pretract 118 N152M01 ptlchg 120 ( 1" DRILL TOOL - 2 DIA. OFF. - 2 LEN. - 2 DIA. - 1.) ptlchg ptoolcomment 120 (THIS IS THE OPERATION COMMENT FOR TOOL 2) ptlchg pcomment2 120 N154T2M6 ptlchg 120 N156G0G90G54X-3.2978Y4.3749A0.S250M3 ptlchg 120 N158G43H2Z.1M8 ptlchg 120 N160G99G81Z-1.R.1F3.5 pdrill 124 N162X.1495Y6.007 pdrill_2 126

Dave, code: qtoolpln : no # MP386 - Enable tool plane option qtoolopt : no # MP386 - Enable tool optimization Seeing those variable definitions tells me you are using an old FADAL Post. Doesn't mean it won't work, but have you tried one of the MPFADAL posts from the MC CD? Note that you would still need to add the HELIX_TOL setting as discussed earlier. Question: On the Helix motion(s) the machine complains about, what is the linear distance int that motion block?

Dave, Try adding a 'helix_tol' setting to your PST (Firtst, check to see if it already exists in the PST, then you could just alter the setting) The educated guess here is that the Z motion distance of that helix move is too small for the machine. From the Post Processor Reference Guide CD -> Code Example: helix_tol : 0.001 # Minimum motion in the axis perpendicular to the arc for helix arc motion output. Default: If helix_tol is not defined in the post (PST file), the default setting = 0.0001 (for Inch mode) and 0.001 (for Metric mode). Notes: helix_tol is the tolerance setting for the minimum axis motion perpendicular to arc plane. If the minimum is not met and the move distance is not zero, the arc is broken with the arc linearize routine.

Troy, Depends on WHICH drill cycle in the list you are talking about. The first 8 cycle "slots" in the list (Drill/Counterbore -> Misc. #2) call their own pre-defined postlbocks in your PST pdrill ppeck pchpbrk ptap pbore1 pbore2 pmisc1 pmisc2 The above postblocks get called on the FIRST point of the cycle toolpath (to establish the "cycle") On the 2nd thru the last point in that cycle toolpath the "_2" postblocks get called for each point. pdrill_2 ppeck_2 pchpbrk_2 ptap_2 pbore1_2 pbore2_2 pmisc1_2 pmisc2_2 *IMPORTANT* The cycle "slots" after the first 8, ALL call into the same single postblock called -> PDRLCST CAMMando left out this critical point in his example... PDRLCST is called for the 1st point of the cycle toolpath (if it is cycle #8 - #19 in the list) -> code: pdrlcst #Custom drill cycles 8 - 19 (user option) if drillcyc = 8, pdrlcst8 if drillcyc = 9, pdrlcst9 # ETC... And for the the subsequent points in that cycle toolpath, the single postblock PDRLCST_2 is called This means you need a way to determine which cycle (of 8-19) is calling to PDRLCST (and PDRLCST_2) You do that by checking the value of the variable -> 'DRILLCYC' as shown above. That logic is used to call to USER-defined postblocks, PDRLCST8 & PDRLCST9 in this example. In those postblocks your establish the cycle (or whatever you are tring to do) for the canned cycle that was programmed.

Jammer, Altering the prefix (address letter) output for a variable is easy... Use the NWADRS() function. You can see examples of it's use in the MPFAN.PST (mill), MPLFAN.PST (lathe) posts The following command would change the prefix that was defined for 'feed' in it's FMT statement with whatever the string 'stre' is defined as. code: stre "E" strf "F" pfeed_out # postblock in you PST result = nwadrs(stre, feed) # Change prefix to 'E' n, *feed, e # Do you output as 'E' result = nwadrs(strf, feed) # Change prefix to 'F'

quote: Yup, it's easy to automate Word, Excel or anyother Office program (maybe not Visio) using VBS. I don't about about earlier versions of Visio, but with Visio 2003 -> You can write programs to control Microsoft Visio in Microsoft Visual Basic for Applications (VBA), Microsoft Visual Basic, C++, or any programming language that supports Automation.

KCollins is correct, it's in the PST file -> 90. Drive and subdirectory for NC files? Either remove everything after the '?' mark, or add a valid path on your system to tell that PST to put it's output files in that folder, instead of the default NC path that is specified in the (Screen->Config) CFG file.

I apologize for the quick (not well thought out answer) quote: code is coming out code: G43H1Z.1T2 #1=0 #2=1 G98G81X0.Y0.R.1Z#1F#2 I noticed in your earlier posting that you had -> code: fmt "" 4 no_z #variable z output fmt "" 4 no_f #variable f output This is what I see in the MPFAN.PST for the definition of Format Statement (FS) #4 ->> code: fs2 4 1 0 1 0 #Integer, not leading Using this format you are only going to see INTEGER outputs (NO sign or decimal point or trailing zeros) My guess is that you are you are using the wrong FMT assignment. You are attempting to take the value from either ZABS or ZINC, put it into NO_Z and output as NO_Z So... What is the FMT number assigned to ZABS and ZINC in your PST ? If your post is derived from the std. MPFAN.PST, '4' is not correct. Formats defined in the MPFAN.PST {Edited for brevity} code: fmt Z 2 zabs #Z position output fmt Z 3 zinc #Z position output fmt F 15 feed #Feedrate There are a couple of ways to handle this situation (like most everything in a PST!) ------------- Solution #1 -> Since ZABS and ZINC are using different formats, we'll create two different 'no_z' variables and use the proper matching format. code: fmt "" 2 no_zabs fmt "" 3 no_zinc fmt "" 15 no_f (Note that the "" are not really necessary here, but it's OK to have them) ---------------------------- Now down in the area of the PDRLCOMMONB & PDRILL postblocks... NOTE.. # NO code added to the PDRLCOMMONB postblock... Since we are removing the call to PFZOUT in the PDRILL postblock, I'm just replicating the basic code from PFZOUT with the new special output code. code: pdrill #Canned Drill Cycle pdrlcommonb if absinc = zero, [ no_zabs = zabs pbld, 35, "1=", *no_zabs, e !zabs, !zinc ] else, [ no_zinc = zinc pbld, 35, "1=", *no_zinc, e !zinc, !zabs ] no_f = feed pbld, 35, "2=", *no_f, e pcan1, pbld, n, *sgdrlref, *sgdrill, pfxout, pfyout, prdrlout, "Z", 35, "1", pcout, "F", 35, "2", dwell, strcantext, e pcom_movea !feed ------------- Solution #2 -> You can alter the "prefix" that was assigned to the variable in the FMT statement using the NWADRS (New Address) formula. Instead of defining 'no_zabs', 'no_zinc' you would temporarily change the FMT "prefix" on 'zabs' and 'zinc' as needed from 'Z' to nothing, and then change it back to 'Z' after. First off you need to define a string variable that contains just "Z" and one that contains just an "F". Search for this section in the MPFAN.PST -> code: #Address string definitions strm "M" strn "N" stro "O" strp "P" srad "R" srminus "R-" sblank And add the two new definitions -> code: #Address string definitions strm "M" strn "N" stro "O" strp "P" srad "R" srminus "R-" sblank strz "Z" # ADDED strf "F" # ADDED Now down in the area of the PDRLCOMMONB & PDRILL postblocks... NOTE... # NO code added to the PDRLCOMMONB postblock... code: pdrill #Canned Drill Cycle pdrlcommonb if absinc = zero, [ result = nwadrs(sblank, zabs) # Re-define the "prefix" on zabs to "nothing" pbld, 35, "1=", *zabs, e result = nwadrs(strz, zabs) # Add the "Z" back on !zabs, !zinc ] else, [ result = nwadrs(sblank, zinc) # Re-define the "prefix" on zinc to "nothing" pbld, 35, "1=", *zinc, e result = nwadrs(strz, zinc) # Add the "Z" back on !zinc, !zabs ] result = nwadrs(sblank, feed) # Re-define the "prefix" on feed to "nothing" pbld, 35, "2=", *feed, e result = nwadrs(strf, feed) # Add the "F" back on pcan1, pbld, n, *sgdrlref, *sgdrill, pfxout, pfyout, prdrlout, "Z", 35, "1", pcout, "F", 35, "2", dwell, strcantext, e pcom_movea Produces NC code like -> code: N104T2M6 N106G0G90G54X-1.4415Y1.7508A0.S750M3 N108G43H2Z.1 #1=-.375 #2=4.5 N110G99G81X-1.4415Y1.7508R.1Z#1F#2 N112X0.Y0. N114X1.086Y-1.481 N116G80

Take out the no_z and no_f assignments in the PDRILL postblock and add this code to the end of the PDRLCOMMONB postblock -> code: #Added to the end of the 'pdrlcommonb' postblock if absinc = zero, [ no_z = zabs !zabs, !zinc ] else, [ no_z = zinc !zinc, !zabs ] no_f = feed Produces output like this -> code: N20G43H1.25M8 #1=-.144 #2=19.1 N25G98G81X0.Y.497R-.034Z#1F#2 N30G80

The varaible 'ntools' = Number of tools used (posted) Note that the post switch varaible 'bldnxtool' must be enabled for 'ntools' to hold a valid value.

code: # Define a string that holds the name of the VBS script to be run, # note that the FULL PathName is required ! strVBS "c:mcam91vbstrip_comments.VBS" result : 0 # Declare a numeric variable to hold the return value from RunVBS() psof # Start of File (Or whatever postblock you need to run the VB Script from) #Run the VBS script (FULL Path/Name is required !) result = runvbs(strVBS)