[MitchB]

I'd like the MadCAM postprocessor to output the tool comments that CutViewer uses to define a tool. Then I won't need to tell CutViewer about each tool whenever I load a GCode file.

This would be in the *TOOL_CHANGE* section, but it looks like all the tool-related variables are not available in the postprocessor. Also maybe they belong in the Cutters file (.drl or .ctr). Is there a way to have the postprocessor do this?

[Dan B]

Can you post an example of the comments required by CutViewer?

Thanks,

Dan

[MitchB]

For a drill:
(TOOL/DRILL, Diameter, Point Angle, Height)
example - 0.201" drill:
(TOOL/DRILL,0.201,120,3)

For a center drill:
(TOOL/CDRILL, Diameter1, Angle1, Length, Diameter2, Anagle2, Height)
Example:
(TOOL/CDRILL,0.25,118,0.3,0.375,60,3)

For a mill:
(TOOL/MILL, Diameter, Corner radius, Height, Taper Angle (defines tool, corner radius is only used if it is a full radius ball mill (corner radius = diameter/2) and taper angle is not used.)
Example - 0.375" Flat End Mill:
(TOOL/MILL,0.375,0,3,0)

[Dan B]

Hi Mitch,

I believe you are correct. There are not enough variables available in the post to give you the definitions you need for CutViewer.

I watched a video on YouTube about CutViewer and there certainly seems like a lot of manual set-up.

Can I ask why you think you need something beyond madCAM's simulator?

Just curious.

Dan

[MitchB]

I am also considering whether I need something besides madCAM's simulator. The best argument is that it provides an independent check of the resulting G-code. If madCAM makes a mistake creating the G-code, it might make the same mistake interpreting it. Since I already have CutViewer, it's not so hard to justify using it for that small additional confirmation.

I don't see how to avoid the type of set-up that CutViewer needs unless something (either a person or the CAM software) provides it with the stock dimensions and cutter geometries. I was able to add a comment for the stock since all the variables are available in madCAM at post-processing time.

A way this could be implemented in madCAM would be to allow a user to add a field to the cutter file which would be inserted as a comment when that cutter is used by the madCAM post-processor.

[Dan B]

You do make a valid point. It's reassuring to see the results of the g-code, not just the intended movements. The best CAM software in the world can be turned into the biggest pile of crap with a poor post-processor, but the software will still show you good toolpath.

Dan

[MitchB]

I didn't think about it before your reply, but since the post-processing hasn't even happened before the madCAM simulator runs, madCAM isn't interpreting g-code in its simulator. I think that makes the case for using CutViewer much stronger.

[Dan B]

No CAM software simulates the code. You are correct. If you simulate before you post, how can it be reading the G-code???

We've never found the need to read the code back in to trust a madCAM path. However, if you already have CutViewer, you might as well use it.

Dan

[MitchB]

Here's an excellent reason for simulating the g-code:

When selecting a tool "It is possible to change the parameters before clicking OK for loading the cutter without overwriting the saved tool in the tool library. (Important! Only the saved tools will be used when post processing )"

That seems awfully dangerous - it is possible to create a toolpath using a cutter which will be different than the one which will be used by the post-processor.

[Dan B]

My suggestion would be to build a tool library for each machine and material and you won't need to make tools "on the fly". You will find that if you do make a tool and forget to save it, the code will lack a tool number and feed rates. It's easy to spot, and isn't going to run on your machine anyway.

Dan

[MitchB]

Good idea. I'll do that. Thanks.