This not a huge issue as I have a post that I will use occasionally just to get an accurate cycle time for a program but I have noticed that when running backplot, the software is interpreting the dwell (on a G82 spot drill cycle)as a value of seconds. The control reads this value in milliseconds (P30 for example). The Backplot function sees that as 30 seconds, little difference there. I usually use a dwell value that will let the tool dwell for 5 revolutions when it reaches the Z target. With a high load operation like spot driling it helps to unload the tool and servo before heading for the next hole. Just wondered if maybe there was a cfg setting that I was missing Thanks in advance, Bob

Thanks Roger! That did it. I was lookin at the ptoolcomm section and it apears that the post was barfing on the snull deal and then posting the "DEFINE TOOL NAMES" deal. Thanks to all again for all the great tips!!! Have a good one, Bob

Thanks for the info. I'll start hackin' on this deal. This post works great for multiple vise jobs but the tool output is annoying. Thanks again for the tips

I use a couple of posts that were the off the shelf sub-rep post from the web site. One has been modifed slightly to work on Fadals but other than that they are pretty much bone stock. The thing works great but I have ran into a real annoyance. Has anyone had problems with the tool description not coming out in the posted code? I mean it will output most of the descriptions but will occasionally just put in (DEFINE TOOL NAMES) in brackets when it should really be ( INGERSOLL 90 DEGREE SPOT DRILL)? WTF? I know that there is some kind of padding of the text string but I'm kind of lost on this one. I've tried more and less spaces before the text but no worky. Any tips would really be appreciated. I don't like cutting and pasting into the posted code. Thanks in advance

If you have an assembly in SW and want to send it to MasterCam do a "File", "Save as", then use the drop down menu and select the Parasolid "x_t" format. Under "Options", check the "Flatten assembly hierarchy", then give it a file name. In MC, do a "File", "Converters", "Parasolids" and import your file. It will maintain the original colors and will put each object on a unique layer. Note that this will work in reverse also. From MC, do "File", "Converters", "Parasolids", "Write file", and when prompted select the "All Solids" option. Open it up in SW and you have all of your parts. Parts created in MC will come in as "Part 1", etc. Works slick for setup diagrams. HTH

This has always bugged the crap out of me too. I have found that you usually get the best sorting routines when using the "Window Points" selection. So now I have finaly found a use for the solid drilling deal. If you use the solid drill thing there is now an option to create points at all the arcs. If there are lots of holes that won't sort, I use solid drill, let it create the points on a new level, then torch the solid drilling op and use the window point selection method. It will usually get a good looking toolpath using the sort options. Just my $.02 (Before taxes) HTH

You might also look into the parameter settings regarding 4th axis positioning. There is a usually a "shortest distance" parameter to keep the 4th from takin' the long way home. HTH

When using I,J,K values on a machine tool, the control is checking the math on the fly. You're basically telling it that from where I am right now, do an arc and oh yeah, by the way, here's where the arc center is. Whatever your circ interp tolerance is set at in the machine if your math is off (usually .0004") the machine will alarm out. There is no problem with using R's as long as your numbers are correct (i.e., from MasterCam). Here's the good part. If you use the R word and your math is off, the machine will just "fake" the move. Bascally it knows you want to do an arc and you've given it the start and end points but your math is well, not so good. On most machines the math can be off by up to two times the programmed radius value and it will still do the move! Makes for some really crappy looking parts. HTH Bob

Thanks for the info. I still can't figure out why it would "pick up" some weird Z value (even though they are "grayed out" in the Ref Box). I never used anything but X when defining the Ref Point. I have noticed that if all ops are programmed for c/l of rotation and only use 1 work offset that the post forces out an XYA rapid move when indexing, then a Z position move after that. When I gave each index position a wo it posts out XYZA rapid moves WHHHEEE!!! It's not a bad thing since Z zero is at the c/l of rotation. My $.02

Okay Gurus, I am using the mpmaster post and doing some 4th axis work on a vertical. I have been using the "Ref Point" option for a safe tool change point. The strange thing is that on all of the ops I have only checked the "X" axis box, nothing else. Here's the hitch, I have about 3 ops (drilling) that also posted a Z axis move on the ops using this tool change move. The Z axis value it is posting seems to be the drilling target depth. Anyway it makes for an interesting tool change move when it moves X-6.0 and then oh say Z-4.0 on the same line. Has anyone else noticed this issue and if so is there a workaround or fix? The edit common parameters thing doesn't work on this thing either. To get rid of the problem I had to give it a Z clear value, then un-check it and then it seems to post out right. The real strange thing is how the mucked up Z values got into the un-checked and unused registers in the first place! Thanks in advance, Bob Mill Level 1 V9 SP2 (Ouch), Win 2k Pro

After installing the SP1 deal I found that if you use the circ mill routine you now need to turn on the "Keep Tool Down" option in the "Depth Cuts" box to actually keep the tool down and in the cut. My $.02 BK

Thanks James, This thing is dialed now. I turned the "stage_tool" option on and removed the "next_tool" call to eliminate the pre-stage deal. Every shop I've seen that runs Fadals does this same thing. This is on a 6030 so it is a long reach to even get to the spindle and the whole tool change process occurs "above" the spindle Z zero position. When programming for these style machines we always sequence the tool numbers in ascending order and do a lot of spot drilling and pre-chamfering to economize on tool change time. Here is the "peof" section of the post . . . peof #End of file for non-zero tool pretract if lock_codes = 1 & rot_on_x, pbld, n, *sunlock, "(UNLOCK)", e rotretflg = 1 pbld, n, "G90", "E0", "X0", "Y14.9", protretinc, e rotretflg = 0 if lock_codes = 1 & rot_on_x, pbld, n, *slock, "(LOCK)", e comment if stagetool = one, pbld, n, *first_tool, "M6", e n, "M30", e mergesub clearsub mergeaux clearaux "%", e

Thanks James it worked slick. I've got another question for you on the post. I used the "Canned Text" deal to put in a program stop (M0) in one of the ops. I'm getting an extra M0 in the code before the Z retract move prior to the tool change and M0. I turned on debug and when I posted the code, I get this . . . ptlchg1002 p__81:2019 on the line where I don't want the M0 and then again where the M0 should be. Can you tell me what the values 81:2019 are referring to? All else is dialed on this post. I can get edit free code if I use the Manual Entry to home the table and then turn on the force tool change in the NCI button. Any ideas??? Thanks, Bob

Got it working. James I tried the following . . . pbld, n, *first_tool, "M6", e and kept getting T0 M6. I had to turn on the stage tool option, remove the "next_tool" (pre-select) call in the post and use the following for the peof block . . . peof #End of file for non-zero tool pretract if lock_codes = 1 & rot_on_x, pbld, n, *sunlock, "(UNLOCK)", e rotretflg = 1 pbld, n, "G90", "E0", "X0", "Y14.9", protretinc, e rotretflg = 0 if lock_codes = 1 & rot_on_x, pbld, n, *slock, "(LOCK)", e comment if stagetool = one, pbld, n, *first_tool, "M6", e n, "M30", e Thanks to all for the tips, Bob

Thanks to all for the post info. I think that the first_tool deal is the way to go. In answer to the other posts we always tool change to the first tool in the program after the move to home the table "G90 E0 XO Y14.9", puts the table .100" off the Y limit. This toolchange ocurrs after the home move and is above spindle zero. Doing this just lets the tool change ocurr while unloading a part. Otherwise ater hitting cycle start you have to wait for the tool change at that point. This is an old Fadal with the standard carousel type tool changer. You can't "stage" (pre-select) a tool like machines with a random access tool changer. Thanks again for all of the tips. Bob

I need a post for . . . just kiddin. I'm using slightly modified versions of the mpmaster post and have a question. We have one Fadal (Wah Wah) and the post works great for this deal except that I want to load the first tool used in the program at the end of the file so we don't wait for 20 minutes while the carousel does it's thing. I have the stage tool option "off" for this machine and I am looking for a way to store the first tool used in the program and load it in the spindle at the end of the prog. All else is dialed on this post but was wondering how to go about getting the tool load issue resolved. Thanks in advance, Bob

When you use the subrep post, open the very first operation in the Op Manager, then check the misc integers box and open it up. You will find the option for the 1st offset (enter 4 for G54), then enter the total number of vises (or workpieces) in the box for number of repetitions. The starting work offset and # of reps is driven by the values in your 1st operation. It will spit out awesome edit free code using sub calls. HTH, Bob

Yo SandyBar, I've had this happen with models that have been through 19 or so different cad systems. I've had bad luck with bad models. Try doing the solid check in MC. Next try putting surfaces on all solids then using the surface checking tools to check for garbage. Ciao, Bob

If you need to bring in assembly, open the file in SolidWorks then do a "Save As" and choose the X_T file format. It will ask if you want to smash the file heirarchy (spell check) and select "yes" for this option. Go to MC, file, import, Paasolids, then select the X_T file format. Works great. The colors come through as in the assembly and if I remember correctly, I think the cad comes in on several diffeent levels. Pretty easy to grab a color and switch to diferent levels for ad management. HTH Was a level 3 user, now a level 1, Yikes!

I noticed the same thing when using the smokin' new extend / shorten deal. Have you noticed that it only barfs on the exit extension? On the entry move (at least on my box), it just adds the ext amount but combines it with the chain selection so you only have a single line move. The exit is the X or Y where it ends at the chain, then it adds the extension amount. Just my $.02

What if you use Create, Next Menu, Letters, then select True Type. If you have the same font as the original doc you should be able to match it perfectly. If there's a lot of text, Copy the text from the doc and then paste it in the MC dialog box. HTH, BK

Figured I'd jump in on this one too. The new lead-in / out thing rocks. I have one question though, and it's definitely related to me being picky about g code. If I use the extend start and exit point it all works well. The one thing I noticed is that say you if use a .01" perp move to turn on comp, then cut the line it will "add" the extend amount to the start of the line but at the end of the line it will post the "X" end of the "source" line, then posts another "X" position for the extension amount. So when cutting a line for example it will post the "X" start position then feed to the end of the line, then add the extension amount. I wish it would do the same thing at the end as it does at the start. Just bein' picky I guess. Posts out okay but if you were single-blocking it you would get 2 moves to do a single line. BK

Thanks PDG, This isn't a huge issue . . . just something I noticed the first time the first time I used v9.1. The strange thing (and the reason I posted this)is that it doesn't do it all of the time. I have xformed a few solids with no message and no entities left in the source position. Thanks for the responses, BK

So it's not just me. I'll do the Parasolids X_T conversion all the time to cleanup a solid but when this occurs (and it's not all the time), it will leave a copy of one piece of geometry on the screen, usually a line or an arc. Weird thing is after xforming all of the stuff is purple except for the geo it leaves in the "source" position. Some soilds I have moved or copied won't do it, others will . . . go figure. Bob

I just installed V9.1 (Mill 1 running on Win 2K Pro / Service Pack 3) and have noticed something new when doing an Xform "something" with a solid. I get a message (after moving or rotating a solid) that says . . . "Cannot move entities which solids are dependent on". It doesn't happen all of the time but when it does, it will leave one entity (an arc or a line for example) on-screen. You can then delete this entity and it doesn't give you the "You're an idiot . . . what were you thinking" message. If it does this when translating the solid, it will do this every time and leave one entity on screen. Has anyone else noticed this? Thanks, Bob