Simple code output in mastercam

First off if memory at the cnc controller isn't a problem, is it (in your opinion of course) better to have more sophisticated program with a more sophisticated toolpath? Or is it better to have a simple program for the set-up operator to prove and edit? In my opinion I believe sophistication in toolpath is only necessary in production runs or a part that requires a very large amount of machining. On the simpler 2d job shop type parts though i believe basic toolpaths would be more appropriate for simplicity at the machine.

This leads to another question: If I am trying to output the simplest program via mastercam, how do I reduce the lines of code in the program down to minimal necessary? HSM techniques seem to lend themselves to long programs, but this is only my experience with the paths I've created. For example, I create a path for a rectangular contour and as the tool moves down a side of the part in a straight line I notice there is an inordinate amount of lines (according to the move list and move info) for what should just be an xy line.

simple program

Rbpercussion said:

First off if memory at the cnc controller isn't a problem, is it (in your opinion of course) better to have more sophisticated program with a more sophisticated toolpath? Or is it better to have a simple program for the set-up operator to prove and edit? In my opinion I believe sophistication in toolpath is only necessary in production runs or a part that requires a very large amount of machining. On the simpler 2d job shop type parts though i believe basic toolpaths would be more appropriate for simplicity at the machine.

This leads to another question: If I am trying to output the simplest program via mastercam, how do I reduce the lines of code in the program down to minimal necessary? HSM techniques seem to lend themselves to long programs, but this is only my experience with the paths I've created. For example, I create a path for a rectangular contour and as the tool moves down a side of the part in a straight line I notice there is an inordinate amount of lines (according to the move list and move info) for what should just be an xy line.

Click to expand...

Their are a lot of diff parameters in mastercam witch makes the code longer or shorter such as lead in lead out, roll around corners or not.
here is a sample of what you are looking for I think. no lead in/out and no rolling around corners.


( T1 | 1/2 FLAT ENDMILL | H1 )
N100 G20
N102 G0 G17 G40 G49 G80 G90
N104 T1 M6
N106 G0 G90 G54 X-.25 Y-4.25 S4000 M3
N108 G43 H1 Z.25
N110 M8
N112 Z.1
N114 G1 Z-.5 F22.
N116 Y.25
N118 X4.25
N120 Y-4.25
N122 X-.25
N124 Z-.4
N126 G0 Z.25
N128 M9
N130 M5
N132 G91 G28 Z0.
N134 G28 X0. Y0.
N136 M30

KENMASTERS said:

Their are a lot of diff parameters in mastercam witch makes the code longer or shorter such as lead in lead out, roll around corners or not.
here is a sample of what you are looking for I think. no lead in/out and no rolling around corners.


( T1 | 1/2 FLAT ENDMILL | H1 )
N100 G20
N102 G0 G17 G40 G49 G80 G90
N104 T1 M6
N106 G0 G90 G54 X-.25 Y-4.25 S4000 M3
N108 G43 H1 Z.25
N110 M8
N112 Z.1
N114 G1 Z-.5 F22.
N116 Y.25
N118 X4.25
N120 Y-4.25
N122 X-.25
N124 Z-.4
N126 G0 Z.25
N128 M9
N130 M5
N132 G91 G28 Z0.
N134 G28 X0. Y0.
N136 M30

Click to expand...

This was for a 4x4 block going around the od of course most people would like a lead in and out to avoid the tool being buried in the first z move but you can adjust that as well for straight lines or arks.
Mastercam gives ton's of variables for everything you would want to do.

Using HSM toolpaths can generate LOTS of code, even if the overall moves would seem to be simple at first look. What you want to look at is the ARC FILTERING tab. Since HSM toolpaths (depending on what your stepover, etc. is) will consist of many tens if not hundreds+ of trochoidal arcs. When first generating a toolpath, especially if using depth cuts, you might have 10-thousand lines+ of code for one operation. Adjusting the arc filtering settings can strip out much of the code that isn't necessarily needed to get from point A to B. In the same Arc Filtering Tab is also Arc Smoothing. This will also help to alleviate code bloat, but can also increase code size depending on many factors.

For instance, I have one part that when posted without any filtering, the .NC file is approaching 2MB in size. By using arc filtering with a 50%/50% tolerance setting, I can cut it down to 800KB. It is easy to go too far though, and you end up "over-filtering" your code. This results in a toolpath that will result in under / over-cuts, distorted contours, etc. I find that a 50/50% or 75% filtering setting usually works pretty well for me in 6061-T6. Again, this is all dependent on tool size & type, type of feature being cut, and the amount of changes in detail that the features have. If you are just creating an empty pocket, you can get pretty aggressive with the filtering. If there are multiple features inside the pocket that are not simple geometric shapes, you will have to back off on the filtering.

Someone explained filtering to me using a the example of a raw, unedited TIFF digital image file captured with a high-end camera. In the raw uncompressed (unfiltered) form, there is lots and lots of data (large file size) representing everything in the image. Now if I wanted to take that image and upload it here to Practical Machinist, I would exceed the file size limitations (5MB?) by 100mb. Now if I take that same image, but compress it (arc filter) and turn it into a JPEG file, it now becomes less than 5MB. Depending on how aggressive I adjust the compression, the image will either distort it and be very noticeable missing clarity and detail (over filtered), or no one will know the difference from the original large raw TIFF and the new smaller JPEG (measures correctly).

I am still a newbie to this, but I pretty much use HSM all the time now, especially for contouring, pocketing, slotting. The only drawback I know of right away is that you probably won't be doing much editing of the G-Code at the controller other than possibly adjusting Feeds, Speeds, and overall Z-Depths due to the huge volume of code generated. It is quicker, and more reliable to just change what you need to in Mastercam and repost, even just the Op in question and then merge it with your file.

My 2 cents.

I will look into the arc filtering setting. there are so many features in mastercam with little to no explanation behind them. The help contents are vague and use other terms that are specific to cam software. And for someone with little to no experience in this realm, their terminology of concepts does little to assist in understanding. The books available aren't great either. It really takes personal instruction in my opinion to gain the necessary understanding required to make good code.

Other than taking formal classes (what I have done), YouTube is your friend. You have to be willing to allot quite a bit of time at first to absorb and practice the lessons. Kinda like playing the piano.

Good luck.

When selecting your geo, if one line segment is split up into two seperate lines then this will cause more code to be posted at that intersection.

I strongly discourage operators from editing programs. It usually takes far them more time than editing in Mastercam and reposting, and punching code in at the machine is more prone to error. Also if you ever run that part again your file will be fixed for the next time.

Filter set to OFF will make a longer program than it would if it were set to something like 2:1

BernieBernie said:

I strongly discourage operators from editing programs. It usually takes far them more time than editing in Mastercam and reposting, and punching code in at the machine is more prone to error. Also if you ever run that part again your file will be fixed for the next time.

Click to expand...

I understand completely where you're coming from. I always dry run the section of program I edit no matter how confident I am. Also, it is nice to have the stored file not have the same mistakes it did the first time.

Where I disagree though is in the amount of time it takes to make a change. In my now former shop we use gibbs cam and everybody who is unfamiliar with gibbs cam hates it at first. I don't make the programs myself but the people who do are learning the ins and outs of it and it takes them much more time than you would first think. There are also the communication errors inherent with having someone else generate the intended output. If I am confident in a solution of my own I apply it and then note the error on the setup sheet

Mtndew said:

Filter set to OFF will make a longer program than it would if it were set to something like 2:1

Click to expand...

Can you elaborate on the filter you're talking about?

Here is a screeenshot of the arc/filter tolerance page. It is in the toolpath parameter for each tool.

brian.pallas said:

View attachment 154837

Here is a screeenshot of the arc/filter tolerance page. It is in the toolpath parameter for each tool.

Click to expand...

That thar be the one.

One of the biggest things that will make a big difference on program length is running arcs as line moves. That's a simple setting to make them into g2/g3 moves.