Something like this ? code: % L100 (07/10/03) (BURN 2 HOLES) (1 ROUGH PASS w/ TAB AND 1 FINISH SKIM) H1 =.0098 H2 =.0072 G92 X-1. Y1. G00 X-1. Y1. M20 M78 M78 (Fill Tank) M102 (Power Master ON) G04 X2.0 (Dwell for Power Master) M80 M82 M84 (Turn stuff ON) E1201 H1 F.25 (Conditions for Rough Skim) M90 (Adaptive Control ON) G41 G01 X-.5 (Lead-in and COMP ON) M101 (PowerMaster OFF) G03 X-1.5 I-.5 J0. X-.5025 Y.95008 I.5 J0. M00 (Tab Cut STOP) X-.5 Y1. I-.4975 J.04992 G40 G01 X-1. (Lead-out and COMP OFF) E1202 H2 F.24 (Conditions for Finish Skim) G41 G01 X-.5 G03 X-1.5 I-.5 J0. X-.5 I.5 J0. G40 G01 X-1. M91 (Adaptive Control OFF) M21 (Cut Wire) G00 X1. Y1. (Move to next hole cutout) M20 (Thread Wire) M102 (Power Master ON) G04 X2.0 (Dwell for Power Master) E1201 H1 F.25 (Conditions for Rough Skim) M90 (Adaptive Control ON) G41 G01 X1.5 M101 (Power Master OFF) G03 X.5 I-.5 J0. X1.4975 Y.95008 I.5 J0. M00 (Tab Cut STOP) X1.5 Y1. I-.4975 J.04992 G40 G01 X1. E1202 H2 F.24 (Conditions for Finish Skim) G41 G01 X1.5 G03 X.5 I-.5 J0. X1.5 I.5 J0. G40 G01 X1. M91 (Adaptive Control OFF) M58 (Drain Tank) M02 %

Sounds like you have a mis-matched MP.DLL for the version of Mastercam Mill you are ruuning. (You CANNOT use MP.DLL for v9.1 with v9.0) What is the Version number of the MP.DLL on your system ? code: To determine the version of MP.DLL (or MPL.DLL, MPWIRE.DLL) 1. Locate the desired file using Windows Explorer (in the Chooks folder of the Mastercam installation). 2. Right-click on the DLL file. 3. Select "Properties" off the drop-down menu. 4. Select the "Version" tab in the "Items name" list. 5. Select "File Version". 6. Read the "Value" (to the right).

quote: I did a lot of changes in my post and i am not sure it will be safe to update. You should ALWAYS run your post thru the Update PST function to use them the a newer version of MC. Under the HELP button for this function is a list of changes that are made to the PST/TXT file set. Even if NO changes need to be made to your post for a new version, running if thru UpDate PST should not cause any problems. Note that the UpDate PST function ALWAYS makes backup copies of the files it touched ! That said, do not rely on that as your Post Processor backup strategy! Yes, it works, but you should keep BACKUPS of your PST & TXT files for your Posts on more that just ONE disk. I cannot recall the last time I lost a hard drive, UNTIL recently when one morning... No prior warning at all, just nothing, the drive would not even spin up! What a pain, and the cursing! Replaced the drive, got everything loaded up and 10 days later, another bad morning, with nasty noises coming from the new drive. Say goodbye to drive #2! What are the chances of that? Now if I could just get those long odds to work on the Lotto.

RStuart, The HPGL language is really quite simple. The real trick will probably be determing the correct "flavor" of HPGL that your equipment wants to see. Anyway, have you Dealer contact me. I believe I could find a Mastercam post that you could try. If I recall,(some) Multicam and Vision Engraving machines use HPGL (or "modfied" HPGL)

quote: I have recently upgraded from Wire Mc7 to Mc9. I am having problems with posting from Mc9. Are you using a different Post Processor now in v9? or did you update your v7 post using the UpDate Post commnand in v9 ? If you Updated your existing PST, I would assume the problem is how you are programming in MC. And are you running Wire v9.0 or v9.1? How the Start/Thread/Cut positions are programmed is different between 9.0 & 9.1 Ultimately the SAME data gets to the post in either case, this is really just a change the the programming method to define and select the Start/Thread/Cut positions. quote: Is this a mastercam function that I can select wilst programming or a posting problem. Depends... Usually (this is post dependant) you will get a 'G92XY' at the Thread Position. So if you are programming a dowel hole that is drawn with it's center at X5, Y1 and that is your Thread Point position, I would expect to get a "G92 X5 Y1" block output. There are MANY user preferences concerning the code sequence to output at the very start of a Wire program and what to do after positioning from a cutout to another. That is where the post comes into the picture. 1> At the start of a program... You can have the Start position different than the Thread position. Say the Start Pt. is set at X0,Y0 and the Thread Pt. is at X5, Y1 Some users want this -> G92 X0 Y0 (Start Pt.) G00 X5 Y1 (Rapid to Thread Pt.) G92 X5 Y1 (Re-G92 at Thread Pt.) G01 G41/G42 X Y (lead-in to contour) Some users want this -> G00 X5 Y1 (Rapid to Thread Pt.) G92 X5 Y1 (G92 at Thread Pt.) G01 G41/G42 X Y (lead-in to contour) Some users want this -> G92 X5 Y1 (G92 at Thread Pt.) G01 G41/G42 X Y (lead-in to contour) Depends on machine setup technique, auto/manual wire thread, personal preference, etc... 2> At the start of a program... You can have the Start position set to the same coordinates as the Thread position. Say both are at X5, Y1 in this case. Some users want this -> G00 X5 Y1 (Rapid to Thread Pt.) G92 X5 Y1 (G92 at Thread Pt.) G01 G41/G42 X Y (lead-in to contour) Some users want this -> G92 X5 Y1 (G92 at Thread Pt.) G01 G41/G42 X Y (lead-in to contour) ------------------------------------------- Now you have what to do when moving from one cutout to another. Say that the Thread Pt. position of the 2nd cutout is at X4, Y2 Some users want to re-G92 at the new Thread Pt. position and some do not -> G01 G40 X Y (lead-out of cutout #1) "Cut wire" (Manual 'M00', Auto 'M21', 'M12', etc) G00 X4 Y2 (move to Thread Pt of new cutout) "Thread wire" (Manual 'M00', Auto 'M20', 'M6', etc) G92 X4 Y2 (DO THIS AT THE NEW THREAD PT.?) G01 G41/G42 X Y (lead-in to cutout #2 contour)

quote: the top head makes the UVZ moves and the XY moves the bottom... It's the UV axes head that is shifted to create the taper. Imagine yourself riding on the wire, looking in the direction of travel. If you program to taper to the right, the UV head is shifted off to the right from the XY (and you would lean to the right). Since the UV is considered to be the the upper head, the 'top' of the part in this (taper right) case would be a larger opening than te 'bottom' of the part. Of course on many (most?) Wire EDMs, top (the UV coordinates) & bottom (the XY coordinates) can be placed where ever you wish by the work plane settings on the machine. Your 'Z1' & 'Z5', settings on Mitsubishi wires, the 'H', 'W' & 'R' on Charmilles, etc. On Sodick, I think these are the -> Table to Upper, Table to Lower, Table to Program ('TP'), Table to Next ('TN') settings. [ 06-20-2003, 09:51 AM: Message edited by: Roger Martin from CNC Software ]

thad, Basically yes, you can just paste in this code. You must make sure that you are not stomping on any existing 'fs2' statements. (That is why I used 25,26,27 since posts usually don't have 'fs2' statements with those high numbers.) For future editing on your PST, it is best to group the 'fs2' format definitions with the existing ones in your PST and group the 'fmt' format assignments with the existing ones. But this is not required. I tried to copy and paste directly from the forum screen and found that when I pasted that text into a PST in my editor that each 'code' section was one long line. Sure you can break it down, but even I messed up the first time. So... I've uploaded an example "TIME.PST" in the "Text_&_post_files_&_misc" folder on the forum FTP site. This is the std. mill MP_EZ.PST with the code pasted in between the markers -> # START OF ADDED CODE ... # END OF ADDED CODE... Then I altered the area in the PHEADER postblock that actually outputs the date/time. Look for -> # START OF ALTERED CODE... # END OF ALTERED CODE...

Try this... code: #====================================================================== # Need to define the 'formats' to be used for the variables used 'ptime' postblock # Proper fomatting is IMPORTANT for this to work! #====================================================================== # These formats used only for 'Date' & 'Time' fs2 25 2.2 2.2lt #Decimal, force two leading & two trailing (time2) fs2 26 2 0 2 0t #Integer, force trailing (hour) fs2 27 0 2 0 2lt #Integer, force leading & trailing (min) code: #====================================================================== # Need to assign the 'format' to the variables used in 'ptime' postblock #====================================================================== # -------------------- Date & Time Formatting ------------------------------ fmt 25 time2 # Capture 24-hour time value into 'time2' variable fmt 26 hour # Hour fmt 27 min # Minutes # Uncomment the 'fmt' for 'day' and/or 'month' if you only want 1-digit format #fmt 26 day # Day (2 digit format) #fmt 26 month # Month (2 digit format) code: #====================================================================== # This postblock will create AM/PM time stamp, like -> 8:15 AM #====================================================================== ptime #Turn 24-hour time format into AM/PM format !spaces # Save current 'spaces' setting spaces = zero # Turn OFF any extra spacing if time >= 13, time2 = (time - 12) else, time2 = time hour = int(time2) min = frac(time2) *hour, ":", *min, if time > 12, " PM" else, " AM" spaces = prv_spaces # Restore previous 'spaces' setting code: #====================================================================== # Then from somewhere like the 'pheader' (or 'psof') postblock, call 'ptime' -> #====================================================================== pheader # This generates a comment block like -> ( CREATED ON 06-17-03 AT 8:15 AM ) " ( CREATED ON ", *month, "-", *day, "-", *year, " AT ", ptime, " )", e Note that if your 'spaces' setting is > 0 you will get additional spaces in this comment -> ( CREATED ON 06 -17 -03 AT 8:16 AM ) You can eliminate those using the same logic as in the 'ptime' postblock... code: pheader # This generates a comment block like -> ( CREATED ON 06-17-03 AT 8:15 AM ) !spaces # Save current 'spaces' setting spaces = zero # Turn OFF any extra spacing " ( CREATED ON ", *month, "-", *day, "-", *year, " AT ", ptime, " )", e spaces = prv_spaces # Restore previous 'spaces' setting

quote: My file is 124meg i tried to do the set up sheet and had to esc after letting it run for over 20 min. quote: I'm not sure of exact time to post the code ,but i know it was less than 1/2 hour. i was trying to use mill.setSo... What is the time difference between posting and creating a setup sheet (on the same toolpaths) ? Like I said before -> MILL.SET could take "a bit" longer than your Post Processor, since it actually scans the NCI file twice and your PST may not have a need to do that. Potentially, the Mill.SET could take almost twice the time to process. First, determine the real time difference between posting and creating a setup sheet. If it takes MUCH longer for the setup sheet... You could try this -> If you really do not need the XYZ limit information and the Comp information that the Mill.SET can output, do this (Save a BACKUP of your Mill.SET first!) -> Find these lines in the Mill.SET ->> tooltable : 3 # Yes, do NCI pre-scan (do NOT change!) xyz_limits : 2 # Output Max/Min X,Y,Z information, where? look4comp : yes # Buffer null toolchanges to search for comp (yes or no) and change the setting to -> tooltable : 0 # Yes, do NCI pre-scan (do NOT change!) xyz_limits : 0 # Output Max/Min X,Y,Z information, where? look4comp : no # Buffer null toolchanges to search for comp (yes or no) Now how much is the time difference betwen posting with your PST and creating a setup sheet with this Mill.SET? You MUST change all three! If you set -> tooltable : 0 # Yes, do NCI pre-scan (do NOT change!) and not the others, Mill.SET will error out. (That's why the comment on the tooltable line says "do NOT change!")

How long does it take to POST that toolpath? Which setup sheet generator you are referring to... MILL.SET? The HTML setup sheet from In-House? MILL.SET could take "a bit" longer than your Post Processor, since it actually scans the NCI file twice and your PST may not have a need to do that.

Try this... code: psub_st_m #Header in main level result = nwadrs(stro, main_prg_no) " ", e *main_prg_no, e ptoolcomment #<added this line here> #G51/G68 requires absolute position on first move if mr_rt_actv & absinc = one, [ sav_absinc = absinc absinc = zero prv_absinc = m_one prv_xabs = m_one prv_yabs = m_one ] else, pbld, n, sgabsinc, e

Rekd, Is stl_mfg_com really blank in these doesn't work cases? Check to see if it actaully contains 'spaces'.

Here is an ASCII chart you can always find, without digging thru your desk.... ASCII Table

Here is a bit more about Dieter and his monkey Klaus. Some great Dieter quotes and a few sound bites. Der Sprockets

kathy, What is the verion of the MP.DLL you are running? (it's in the CHOOKS folder) In windows explorer, find the MP.DLL, right mouse click on it, select Properties on the menu, then the Version tab, now the File Version entry in the Item name list, read the version # in the Value pane on the right. You need v9.12 along with the SET file fixes.

FIRST - MAKE BACKUPS OF ANY FILE YOU ARE GOING TO TOUCH! Yes, I did mean to SHOUT that ! You alter the TXT file that goes with your PST file. I altered the MPFAN.TXT for this example -> code: [drill cycle 12] 1. "RIGID TAP" 2. "Feed rate" 3. "Dwell" 4. "Clearance..." 5. "Retract..." 6. "Depth..." 7. "" 8. "" 9. "" 10. "" 11. "" ... and further down in the TXT file ... [drill cycle descriptions] 1. "Simple drill - no peck" 2. "Peck drill - full retract" 3. "Chip break - incremental retract" 4. "Tapping - feed in, reverse spindle - feed out" 5. "Boring #1 - feed out" 6. "Boring #2 - stop spindle - rapid out" 7. "Misc #1 Drill" 8. "Misc #2 Drill" 9. "Custom drill cycle #9" 10. "Custom drill cycle #10" 11. "Custom drill cycle #11" 12. "RIGD TAP - feed in, reverse spindle - feed out"" 13. "Custom drill cycle #13"

The 'canned_postblock_name_2' postblocks are called after the call to the 'canned_postblock_name' is made. ONLY if there is more than 1 point position to be drill/tapped/reamed/whatever. Example: PDRILL # Called for 1st point in the pattern PDRILL_2 # Called for the 2nd thru last point. Reason for this? You are creating the Drill/Tap/Whatever cycle code in the PDRILL postblock. The PDILL_2 is to output the positioning code for the subsequent points - if they exist.

Brent, Sorry for dropping a sample part with no explanation. I haven't been back to the forum 'til now. You have Thread & Cut points defined, but you have not selected them. Since you have these points ON the endpoints of what you are going to chain, you need to be a bit careful when selecting the these points. You could fix the chaining in your program using the Chain Manager. Click on the Geometry line of your operation, right-click, select Add Chain ,then add the Thread point Select 'Point' for the chaining method, the 'Point' to tell MC that you want to select ONLY a 'point' entity, then drag 'n drop that point to the top of the list. Now repeat this procedure for the Cut Point (except you don't need to drag 'n drop this point, it's already at the end of the list.) This may sound complex, but it's actually quite easy once you've played around with the Chain Manager. BUT, (in this case) it's not a big deal to just re-chain everything... This is the sequence I used when chaining everything (I rebuilt the entire operation) -> Wirepaths, 4-axis (checked that the Sync Mode = Entity) Chain, Mode, Point, Point - then select the Thread Pt. Now Chain the lower profile. Now Chain the upper profile. Mode, Point, Point - then select the Cut Point. Again - The extra 'Mode', 'Point', 'Point' menu selections here are because your Thread & Cut points are ON the endpoint positions of the profile you are going to chain. So we need to be specific in telling MC that we want those 'point' entities, not the endpoints of the profile. BTW, You could also do this using the Color Mask option if your Thread and Cut Points were a different color than the adjoining entities. You can make this chaining process a bit easier (a few less menu picks) by eliminating the first and last lines of your profiles. MC is going to cut from the selected Thread Point to the start of the profile anyway, and from the end of the profile out to the selected Cut Point. This way, with your Thread and Cut points just 'floating out in space' you don't have to concern yourself with telling MC that you just want to select a 'point', since there is nothing else for MC to grab onto at these positions in space. Also, make sure that "Thread Distance" is Un-Checked. You're using the Thread and Cut points you've selected, so you don't want this active. Roger

Aaron, Sounds like you are missing the edits needed in the 'pwritbuf1' and 'pwritbuf2' postblocks. .SET File Edits information.

Brent, Check out the MC9 in the Thread_Cut_Points.ZIP in the MC9 folder of the forum FTP site. Is this the result you were looking for ? I included the Thread & Cut Point (actual point entities in v9.1) in the chaining

Is is NEW behaviour? Does this only occur in program with a SINGLE tool?

quote: Will there be a patch to correct this in the near future? Yes, there will be an update. In the "near future..." How near is near? I cannot tell you a time frame, since... 1> I don't know it. 2> I don't control it. The .SET files on the v9.1 CD are not the problem, these changes to the .SET files are designed to work around the root problem. In addition, I plan on having updated SETs -> MILL.SET, MILL2.SET, and MILLM.SET ROUTER.SET, ROUTER2.SET and ROUTERM.SET available for download from www.mastercam.com on Monday. (I will post a message when they are available) *Note that -> These updated SET files will be the SETs that were on the v9.1CD with the changes shown in my previous posting ^^above^^ Please see my previouis posting. It contains *NEW* information! -----------------------------

To fix the multiple tool data outputs in an existing .SET Setup Sheet generator... Add the four (4) lines of code to your .SET file as shown below -> Search for the 2nd occurrence of "psetup" in the .SET file. (This will be at the END of the PSOF postblock) Add the 4 lines marked: #Added (4/22/03) in this section of the .SET file -> code: psetup # Call for toolchange info output !op_id #Added (04/22/03) ptlchg0 # Null tool change !gcode !op_id #Added (04/22/03) ptlchg # Output of time calculations for the last tool run if op_id = prv_op_id, ex # If True, NOT a real toolchange - Added (04/22/03) ptooldata # Output ending data for tool (X,Y,Z, Feed limits, Time) " ", e # Blank line tmax_fr = fr # Initialize (max fr used in current tool) tmin_fr = fr # Initialize (min fr used in current tool) psetup # Call for toolchange info output !op_id #Added (04/22/03) **** NEW **** In addition to the above changes.... You want to add the addtional changes shown ->> ------------------------------------------------- Now search further down on the .SET file for 2nd occurrence of "pwritbuf1" Add the one (1) line marked: #Added (4/22/03) into this posblock ->> code: pwritbuf1 # Write Buffer 1 b1_gcode = gcode if gcode = 1002 & op_id = prv_op_id, b1_gcode = 1000 #Added (4/22/03) b1_tcode = t b1_xmax = x_max b1_xmin = x_min b1_ymax = y_max b1_ymin = y_min b1_zmax = z_max b1_zmin = z_min b1_gcode = wbuf(one, wc1) # Write the record ----------------------------------- *NOTE* the following change is NOT needed in the MILL2.SET or ROUTER2.SET Now search further down on the .SET file for the occurrence of "pwritbuf2" Add the (2) lines marked: #Added (4/22/03) into this posblock ->> code: pwritbuf2 # Write Buffer 2 b2_gcode = gcode if gcode = 1002 & op_id = prv_op_id, b2_gcode = 1000 #Added (4/22/03) !op_id #Added (4/22/03) b2_ccomp = ccomp b2_cc = cc b2_cc_computer = cc_computer b2_gcode = wbuf(two, wc2) [ 04-25-2003, 05:51 PM: Message edited by: Roger Martin from CNC Software ]

FYI, There is a MPFADAL1.PST and a MPFADAL2.PST on the v9.1 CD Note that... MPFADAL1 supports -> Format 1 Subroutines MPFADAL2 supports -> Format 2 Subprograms Any feedback form FADAL users on these posts is appreciated! Post Processing Services CNC Software

RLEZ, Do you know what is wrong with the 3D code? What version of Mastercam are you running ? If using v8 or v9, do you have the toolpath filter function enabled when creating your 3D paths? This can cause ARC moves to be generated (in planes OTHER than the XY plane), which your post may not be handling properly. [ 04-16-2003, 12:31 PM: Message edited by: Roger Martin from CNC Software ]