Mike, On the FTP site, in the Ver 9 directory, there is a file called 27tooth.mc9. See if that is what you are looking for. I created it using the GEAR C-Hook I mentioned above. You can trim the OD and ROOT to what you need.

Mike, Sorry. Been doing gears so long using that program I forgot that it may not make sense to someone else. An easier way would be to just use the GEAR C-hook in MC. ALT-C --> choose GEAR.dll You can put in all the gear parameters you have and MC will draw the entire gear for you, all teeth or just one. Then you can make whatever toolpath you want on it.

Below is the output of our gear program. (in-house written) I see that the MOW doesn't match what your data shows (using the mean CTT. The radii listed at the end can be drawn and trimmed off to get a tooth wall. C:gears27TEETH using version 4.2 Number of Teeth.......... 27 Pressure Angle........... 30.000 Diametral Pitch.......... 8.00000 OD....................... 3.25000 Standard OD = 3.62500 Root..................... 3.20900 Standard Root= 3.06250 Wire Diameter............ 0.21600 Standard Wire= .2160 MOW...................... 3.66930 CTT...................... 0.19360 Standard CTT = .19634 Pitch Diameter........... 3.37500 Base Circle.............. 2.92284 Beta Prime............... 0.3003 Fillet Radius............ 0.00000 Standard Fillet = .0375 Tip Radius............... 0.0000 Change Factor............ 1.620 : 1 Tooth Spacing............ 13.33333° 1/2 Tooth Spacing........ 6.66667° POINTS ON THE INVOLUTE Points #1 - 12 Points # 13 to 26 X 0.007659003 Y 1.461397799 X 0.028062068 Y 1.546225952 X 0.008107096 Y 1.467938767 X 0.030494269 Y 1.552724450 X 0.008900855 Y 1.474477574 X 0.033022903 Y 1.559217488 X 0.009922557 Y 1.481014485 X 0.035645592 Y 1.565704723 X 0.011130811 Y 1.487549366 X 0.038360210 Y 1.572185807 X 0.012501998 Y 1.494081990 X 0.041164841 Y 1.578660391 X 0.014020377 Y 1.500612085 X 0.044057749 Y 1.585128126 X 0.015674532 Y 1.507139359 X 0.047037352 Y 1.591588661 X 0.017455723 Y 1.513663504 X 0.050102202 Y 1.598041644 X 0.019356999 Y 1.520184202 X 0.053250970 Y 1.604486720 X 0.021372679 Y 1.526701128 X 0.056482426 Y 1.610923536 X 0.023498016 Y 1.533213952 X 0.059795436 Y 1.617351738 X 0.025728971 Y 1.539722340 X 0.063188942 Y 1.623770968 Chords - Maximum of 4 0.32477 0.66486 1.00494 1.34503 6 Circles make up the Involute X Location Y Location Radius ------------------------------------------------ 0.185043613980,1.451154956128 0.177680094641 0.343205522169,1.420943036695 0.338688672307 0.441861743480,1.393264352622 0.441153517401 0.520897192060,1.365616551612 0.524885122786 0.588550465102,1.337814956132 0.598028047031 0.648440102647,1.309809647218 0.664142064017

Jack, Make sure you start editing by Machine Type -> Machine definition Manager. Open the correct MMD file, THEN open the control definition file from there. Make your changes, save the control definition file, then also save the Machine definition file. BTW, I had the same problem as you with a Dynapath post and the "$" after updating to MR1. Found the same solution as you did.

Well, adding the mtol variable (set at .00001) worked. Ver 8 & 9 are now outputing 5 decimal places as they are needed, and the machine seems to like the code. Thanks for all the help, guys.

quote: If mtol is not initialized in the post (V9.1 with MP.DLL v9.19 or 9.19) the default precision is used which means that the most you will get output is 4 places past the decimal point. Paul, in my original ver 9 post file, I did not have the mtol variable, but on some lines got 5 decimal places anyway. There must be something else that allowed the 5 decimals *sometimes* oy, I going to bed. gotta be at work in 4 hours.

quote: Quick question here. Why does it output G2's and G3's on every linewhen you add the "mtol"? Opps, I just checked and I ran it through a test post by mistake in the one without gcodes. Ran it though correctly, and the result was the same as far as the decimal places. The mtol variable has no effect on the G2's, G3's, etc. Nice catch, Jake.

AHA! gcode, you were right right off the bat. I tried ADDING the mtol variable to my post and I get 5 decimal places anywhere there is something other than zero. Don't know why it wasn't there in the first place, or how I got along without it all that time in ver 8. It doesn't FORCE 5 decimal output, but it does put out 5 places in spots where before there were only 4. I think this will do the trick, but I can't test it until I get to work tomorrow. Look especially at lines N20 & N170 from both outputs. sample output without mtol... %00000 N10 (1 ) N20 G1 X.31227 Y-.15623 F20. N30 M97 N40 G2 X.298 Y-.1526 I0. J.03 F6.16 N50 G3 X0. Y-.07698 I-.298 J-.5494 N60 X-.298 Y-.1526 I0. J-.62502 N70 G2 X-.3123 Y-.15622 I-.0143 J.0264 N80 X-.3407 Y-.1359 I0. J.03002 N90 X-.36004 Y-.0195 I.3407 J.1164 N100 X-.3547 Y.0423 I.36004 J0. N110 X-.3372 Y.0646 I.0296 J-.0051 N120 X0. Y.13548 I.3372 J-.7666 N130 X.3372 Y.0646 I0. J-.83748 N140 X.3547 Y.0423 I-.0121 J-.0274 N150 X.36004 Y-.0195 I-.3547 J-.0618 N160 X.3407 Y-.1359 I-.36004 J0. N170 X.3123 Y-.1562 I-.0284 J.0097 N180 M99 N190 M30 sample WITH mtol (set to .00001) %00000 N10 (1 ) N20 G1 X.31227 Y-.15623 F20. N30 M97 N40 G2 X.29796 Y-.1526 I0. J.03 F6.16 N50 G3 X0. Y-.077 I-.29796 J-.5494 N60 G3 X-.29796 Y-.1526 I0. J-.625 N70 G2 X-.31227 Y-.15623 I-.01431 J.02637 N80 G2 X-.34065 Y-.13593 I0. J.03 N90 G2 X-.36 Y-.0195 I.34065 J.11643 N100 G2 X-.35465 Y.04232 I.36 J0. N110 G2 X-.33718 Y.06463 I.02955 J-.00515 N120 G2 X0. Y.1355 I.33718 J-.76663 N130 G2 X.33718 Y.06463 I0. J-.8375 N140 G2 X.35465 Y.04232 I-.01208 J-.02746 N150 G2 X.36 Y-.0195 I-.35465 J-.06182 N160 G2 X.34065 Y-.13593 I-.36 J0. N170 G2 X.31227 Y-.15623 I-.02838 J.0097 N180 M99 N190 M30

quote: could / did you try changing this? fs2 2 0.5 0.4 #Decimal, absolute, 5/4 place fs2 3 0.5 0.4d #Decimal, delta, 5/4 place That is exactly how my post reads. Thanks, though. I have an hour or so tonight to play with this. Maybe I'll stumble on something.

gcode, Found the vtol variable, changed it to .000001, but no joy. Output exactly the same code. Thanks anyway. One would think there is a way to FORCE the 5 (or 6, or 3, or 8, or whatever) decimal output. Just have to find it. p.s. you are probably right about the control wanting 5 decimal place accuracy. Terry, The post is putting out anywhere from 3 to 5 decimal places, seemingly at random, even on the I's & J's. Doesn't make any sense to me. You would think both versions of MC would put out the exact same code from the same model.

gcode, That variable isn't in either the ver 8 or ver 9 posts. Should it be??

for MC 8, 9, and X.. I need a way to force 5 decimal place output on X, Y, I, & J codes. Our current posts will output anywhere from 2 to 5 decimal places, even when the number out to 5 places isn't zero. I have the post variables set to output 5 places after the decimal. This is causing a problem with a couple machines that crap out with an error "can't compute radius" in certain cases. It was never a problem in version 8, but 9 and X produce different NC code than ver 8, with the exact same model. All the tolerances in setup are the same in all 3 versions, so I don't know why they would produce different nc code. I figure that if I could force 5 decimal place output, it may solve my problem. Anyone know how to do this? (my reseller doesn't) partial examples follow.... Version 8 output %00000 N10 (33917GP ) N20 G1 X.36227 Y-.15623 F20. N30 M97 N40 G1 X.31227 F30. N50 G2 X.29796 Y-.1526 I0. J.03 N60 G3 X0. Y-.077 I-.29796 J-.5494 N70 G3 X-.29796 Y-.1526 I0. J-.625 N80 G2 X-.31227 Y-.15623 I-.0143 J.02637 N90 G2 X-.34065 Y-.13593 I0. J.03 Version 9 output... %00000 N10 (33917GP ) N20 G1 X.36227 Y-.15623 F20. N30 M97 N40 G1 X.31227 F30. N50 G2 X.298 Y-.1526 I0. J.03 N60 G3 X0. Y-.07698 I-.298 J-.5494 N70 G3 X-.298 Y-.1526 I0. J-.62502 N80 G2 X-.3123 Y-.15622 I-.0143 J.0264 N90 G2 X-.3407 Y-.1359 I0. J.03002

All, This has made me nuts for a couple days. I found a little freebie macro program called "ALLCHARS". Great little program, but it doesn't play well with MC. One can load it at startup, and have special chars and macros at your fingertips in all windows programs. I love it. BUT, in MC 8.1.1 and MC 9.01 MR015, it causes MC to crash when deleting any toolpath from the OP manager. Everytime! It doesn't seem to affect MCX, near as I can tell. I've since removed it, and just wanted to point it out here in case anyone else ran across the program and tried to use it. Not really a Mastercam issue, but related more or less. A shame, since it is a nice little addition to windows. Running WinXP Pro service pack 2, FWIW. Anyway, just wanted to let everone know.

If I understand you correctly, all you need to do is create surfaces from the solid, then you can choose any of the surfaces you wish to lay a toolpath on. create >> surface >> create surface from solid... then pick your solid. You can then get rid of the solid and you have any of the surfaces to choose from. Is that what you meant

Check this thread... http://www.emastercam.com/ubb/ultimatebb.p...ic;f=1;t=019240

Not that this solves the crashing problem, but... I've never trusted 'autosave' with any program. Anything I'm working on that will take more than 10 minutes I save manually adding an incremental number to the end of the file about every 10 minutes, or when you're about to make a major addition to the program. File-1.mcx File-2.mcx File-3.mcx etc... That way, when you change something that doesn't work, and undo doesn't 'undo' like you want, there is a file to go back to. After everything is done, you can go back and delete all the incremental files. This has worked for me for years. You do have to remember to do the saves yourself, but once it becomes a habit it works well. my .02

quote: Another thought is whether or not you have the check box for "Regenerate NCI on File get" or something worded like that in 9 Tried that. Tried saving the NCI file with the file when exiting, after ticking on "regenerate NCI...". No good, the next time I call the file up, make a change and exit without saving first, after the prompt to save the changed file and the NCI, it regens the toolpath. Don't ya just love these little picky problems. I'm heading home now, won't be able to try anything else until Monday. Thanks for the suggestions.

Some more info: If the file is changed, but saved before exiting, MC doesn't regen the toolpath on exit. It only does it if MC (ver 9.1) has to prompt you to save the file because it changed. Seems as thought if MC9 has to save the file as part of the exit routine, it wants to regen the toolpath also, because then it asks if you want to save the NCI file (which I never do). Not the best solution, but for now we'll live with it until we finally go strictly to MCX. If anyone has any other ideas, I'd be glad to try them out. Thanks, Don

Jim, Yep, that works, but now there is no prompt if the file has changed. Not a good thing, being the forgetful person I am.

Kannon, Nope, mine looks just like your picture.

Glad you like it Kannon. I love finding these little utility programs. Saves me having to write them myself.

In ver 9.1 MR015, I seem to have inadvertently set some parameter that causes MC to recompute the toolpath when exiting the program. I've turned off every switch I can find that would cause this (i thought). EX: load an existing old file, change anything in the program, save the program, exit MC. Upon exit, MC recomputes the entire toolpath. for a large model with a fine stepover, (almost all my work), this may take some time. Anyone have an idea what I'm missing? 'save toolpath with file' is NOT checked.

Here's a neat little freebie that can be setup to instantly print the screen to a printer, or save it to an image file. pretty cool little program. http://www.gadwin.com/printscreen/

Working on a network, but only source files and posted files are shared. Tool libraries, post processors, etc are all local. We keep all source files and posted NC code in zip files on one of the computers, separated by customer. All this is backed up to another computer daily, and the entire network to DVD weekly.

We have a mahince with a simlar problem. Even though it should complete one command before starting another, it will get ahead of itself. (different application, but maybe the same problem as yours). We program a 1/2 sec dwell after the retract, before the rotate command. This works well for us. Might be your machine has the same problem??