[BrianSP]

It's been quiet here so let's ask a question for the experts.

Let's take the example of thread milling. Whether or not the g-code is created as a helical move or a series of straight moves depends on the post-processor yet the simulator can show a tool-path before post-processing.

So what is the simulator actually showing? Does it perform a background generic post-process or does it create some other form of temporary simulator file or does it run an interpretation line by line from the program window?

The inference, of course, is that just because the simulator says you will get a certain tool-path this is not necessarily true because the g-code created by the post-processor could command something entirely (or subtly) different.

Brian

[BobWarfield]

I can't speak to Dolphin, but many (most?) CAM programs simulate off the internal data structures that drive the post processor.

Because of this, they may not show you what your machine is actually going to do, either because your post is wrong for your machine, or because there is a bug that affects the internal data structures that the simulator doesn't see.

For that reason, a lot of machinists like to use a separate simulator to see what the g-code really looks like. Most g-code editors have a simulator built in, for example.

Of course your machine controller will also show you what it looks like in most cases too, and that's really the horse's mouth, though the machine may not be sitting next to your CAM program.

Cheers,

BW

[andre-dolphin]

BW is correct, the toolpath is driven from the CL (cutter location) data. This is an APT based intermediate data file that contains the info needed to drive the post. A post will read this file then apply the instructions contained within the it.

If you're really curious you can see this by choosing the advanced tab when post-processing and checking the "Include debug information" box. You'll need to post it again without this option to get a clean gcode file.

ATB
Andre