Just to be clear.. my only intent when making my initial post was to clarify the reason it was down for anyone who might not have seen the notice..

They have had a notice on their site for a week or so stating that their site would be undergoing maintenance today and would be down at some points throughout the day.

Most likely the originnum variable is undefined or possibly incorrectly defined. There should be a statement like this originnum : 0 #Origin Number Somewhere up at the top of the file which defines the variable, if there is one there, you might want to verify that it is spelled the same in both place. Just my two cents.. this is a relatively simple error, 5 axis posts are ridiculously complex.. there is a reason people get paid a lot for these type of posts. If your goal is to save money on a post you are probably going to end up spending more in time and aggravation creating one than paying someone, on the other hand, if your goal is to learn post editing because you just want to learn it.. then I wish you the best of luck in your quest.

Just happened to think, you also might want to verify that in the options for backplot (the old backplot that is) you have it set to simulate cutter comp. You probably also want to make sure that on the Cutter Compensation page of your Control Definition that Control supports cutter compensation in control is checked.

You can also use 2D contour set to ramp, then in lead in lead out use perpendicular (perpendicular lead in is ESSENTIAL) and then make sure lead in and lead out on both line and arc are set to 50% of the cutter minimum. The 50% of the cutter is what makes it move over since your using control comp on Mazak's.. I never had much luck with Helix bore when using control comp on our Mazak's, not saying its not possible, just I always had issues with it not doing what I expected. I like to use the 2D contour method because its totally predictable and I can change it to do whatever I want and see the correct info in verify.. and btw I am running this code in Mazak's were running all EIA, however so AFAIK any gcode that is run is going to run as EIA even if its a sub inside of Mazatrol.

Doing math keeps your brain young.. I suppose choosing the center point is ok for you n00bs.. j/k.. The funny thing is I actually knew about the center point thing but I almost never think to use it, I got so used to doing it the old school way I just haven't changed how I do it.. that said yeah .. choosing the center point is probably the better way to go.

To chamfer starting at the center of a hole use 2D Contour set to chamfer, under lead in/out set angle to 180 and radius to Diameter of hole minus the diameter of cutter divided by 4 - in this case ..using a cutter bigger than the hole.. use the cutter diameter at the depth you are going.. rather than the OD of your cutter .. so assuming the point of your 90 degree chamfer tool is at -.236 then your diameter for the purposes of this formula would be .472 From memory, I think Mastercam uses the width plus depth that are defined in the chamfer settings as the overall depth it goes when chamfering a hole, but you might want to post something out as a quick test to make sure.

Sorry I didn't notice it, I didn't intend anything by mentioning your last post other than to make the point that stock models are generally the preferred method now. I used to use STL files all the time, and if using different files I think they are still the only viable option for getting stock generated from the previous operation.

Unless there is an option I don't know about, there is not a way to set the stock for multiple operations and have it saved.. its something I mentioned in one of the beta surveys as something that should be improved. I made the suggestion that each toolpath group should have its own stock and fixtures setup... that is saved so that once you setup stock and fixtures for a given op they don't need to be changed. Currently if you have stock set for one operation, verify will display that stock when you go to verify the next operation as well, which means with multiple operations in the same file you are stuck changing the setting for the stock prior to verifying. If there is only stock its not hard to change it, but it becomes a pain to change stock and turn on/off levels for fixtures as well. This is an area where I think Mastercam's development team has always kind of had a split personality.. they program in the WCS stuff so its easy to use different WCS and maintain one file for one part with multiple ops, and they give us the stock model functionality that allows you to use the result from a previous toolpath group as stock for the next operation, then .. they somehow program the verify as if there is always only one operation per file. Hopefully this is something that is changed for the better in future versions. I though I would also mention, civicegg mentioned using STL files for subsequent ops, and that is a viable option, however I believe the new methodology is to use stock models over STL files for stock for subsequent operations.

At the bottom of the offset window is a box that says use new attributes.. if you check that box you can then specify what level you want to put the copied geometry on.

I think hes converting the X from roman numerals to regular.. so hence.. MC19 .. Anyhow.. I think the defaults for depths will come from your config.. could be wrong on this .. But the reason for using incremental is that if you program all your depths Incremental off geometry and then move your geometry then your depths will adjust automatically to the new location of your geometry. If you are programming 2D off of lines this is not as apparent since usually people draw all lines at a depth of 0 then modify the depths in the toolpaths. Now that there is more robust ability to do chaining off of solid models I am guessing this is why your seeing this as a default.. then again based on your question being considerably lacking in details.. I could be totally off the mark

I think when he says pound out the line he means to comment it out.. so it would look like this.. # force_tlchg$ : 0 #first operation marks input SOF as done, ASCII NCI toolchange Gcodes are not altered

I have always just drawn these highfeed tools based on the dimensions the manufacturers provide, I thought I saw at one point someone said custom profiles weren't used to determine stock to leave, but I seem to get good results when I have drawn them and checked stock to leave against a offset profile in backplot. Perhaps someone that has more insight into this will elaborate on how Mastercam currently handles custom tools internally when given a stock to leave amount. FYI.. only thought this was relevant here since if you can draw them as a custom tool the not having them in the tool manager isn't that big of an issue..

First off, you now say your out of round tolerance is "0", is that what the inspector is saying? and if so have they given you a spec or shown you a note requiring that? Anyhow.. so far as the inspection method goes... Plastic impression compound has a shrinkage value to it, also depending on the feature being measured an optical comparator is going to be open to interpretation by the inspector to a certain degree. In inspection, accuracy and repeatability are the most important aspects of the inspection method. If multiple inspectors can reliably inspect the same feature using the same method and achieve accurate results over multiple checks then its probably a good check. If they cannot attain similar accurate results then its probably not a good check. I would guess using the method you described they wouldn't attain the same results if they were to make multiple impressions and if multiple inspectors checked the part, so most likely this is not a reliable method for checking the part. If this is a first piece check, then I would say make the part better to appease the inspector, if all the parts are complete, then I would try and find a better method to check the parts because IMO this method is questionable at best. One method I can think of off hand is, If you have a small ball you could draw up the thread and get a dimension over the top of the ball, then indicate it in several locations to determine actual pitch diameter.

The allowable tolerance at the pitch diameter on a 3 1/2-16 thread from the Machinery handbook is 3.4594-3.4669 that's a range of .0075 .. so unless otherwise specified would mean that in this case roundness should be a function of allowable size.. so the maximum allowable measurable out of round on an indicator would be .00375 however this would only be the case with the maximum allowable diameter and and the minimum allowable diameter. In reality what you would be looking for is for the entire pitch diameter to fall within the zone between the two diameters. Since a thread gage is really a go and a no go gage, the go is checking to see the thread isn't too small, and the no-go is checking to verify the thread isn't too big, they should be checking to verify that the thread size falls within the .0075 allowable tolerance shown above. There could be something in a spec or something that says different in regards to an allowable out of roundness, if it were me I would ask to see the dimension/spec that controls roundness on the thread.. although if its the customer's inspector rather than an in house inspector it becomes a question of whether you want to argue with a customer or not. (And apparently while I was writing this novel .. I could have just typed.. yeah what John said.. )

PM sent..

If you get a Max value of 1000.00 when posting .. I would suggest that the next thing you do is simply modify that value at the machine to a higher value.. make it 2000.. then try it.. does the machine alarm out? Keep trying values until the machine alarms out and you can find your actual Max for F (I would strongly suggest running in the air when testing this..) If 1000.00 is the actual Maximum.. then I would say you need to talk to the people you deal with for your Machine and see if there is a parameter or something that can be changed to modify the time settings.. If you find the value can actually go to 9999.99 or 99999.999 (or any other value) then the solution is to modify Inverse Time Feed Rate Limits in your General Machine Parameters in your Machine Defintiion to use the new maximum F value you figured out.. I realized after posting this.. that I probably should have stated that the 'correct' thing to do would be to look up the proper values in the manuals / documentation.. I have found in practice however that the documentation is generally pretty hard to find for this stuff.. and that's if the shop has kept track of all manuals and documentation to begin with..

And yeah .. I get these all the time with that exact comment.. lol.. and sure.. you could probably fudge it with some messing around.. but in reality its often harder to fudge something in than it is to create the proper geometry to do it.. At least for me.. I would rather know its correct before getting it in the machine.. than risk screwing up a part for a lead in ..

XXX_SWEPT_SURFACES.MCX-5 Here is a copy of the file with the surfaces done the way I was explaining..

The problem is basically that what you are after will be a swept surface with a constantly changing angle create by the cone angle of the part. Given the Cone angle on the face of the tooth, in order to maintain a given chamfer width over the length of the tooth will require the chamfer angle to change approx. .2 degrees .. if I were to have to do this I would create points at the endpoints of the top and bottom of the tooth, do some math and rotate/copy them around the conical face at the top and bottom of the spline tooth .0275 (they will rotate different amounts angularly in order to go .0275 because the diameters are different at the top vs. at the bottom of the tooth), then translate/copy them along the length of the tooth .0275 Now you should have 4 points that are the four corners of your surface, create some lines and create a swept surface and you can them make a flowline toolpath to cut that swept surface..

I am pretty sure a lot of managers I have worked with if asked to quote that would say "its no problem manufacturing will figure it out.."

Wait what? they never sent me any free t shirts... I'm lucky to get a mouse pad.. Sheesh..

It would be a lot easier to figure out why if you posted a piece of code from BOTH posts rather than just one post.. what you gave is only one piece of the puzzle..

If you use the post debugger it becomes obvious pretty quick that the comment stuff is a pain.. however its possible to modify how it works if your stubborn enough.. I did something similar with comments and yes it did require using buffer files.. I think pretty much anything of this scope with comments is going to require buffers.. since the comments variables don't always have the values you might expect in all the places you might want to use them.. The solution is basically to buffer comments out to a file and then read them in where you plan on outputting them.. at least that's what I did and it worked good for me.. Here is a thread where I show how I accomplished this.. http://www.emastercam.com/board/topic/72936-moving-manual-entries-using-string-buffers/?hl=comments

I may be ridiculously lucky or something, but I have been using X9 since the public beta came out, so far I have yet to find a bug, for me at least; its been more stable than any version of Mastercam I have used, and I have been running Mastercam since version 9. I haven't had a chance to do any multiaxis stuff with it yet though, so maybe I can still find a way to break it...