Creating CNC roughing and finishing passes

[chrisb]

The Sample Interval property seems to influence this. I'm afraid opencamlib is doing this because it is a 3D-Surface. Where at each point the Z component might change.

Some of the post processors are aware of modal commands, i.e. they suppress a component if it is the same as before. There would be the place to optimize redundant movements. It should not be too difficult for straight moves.

[prius06]

The Sample Interval property seems to influence this. I'm afraid opencamlib is doing this because it is a 3D-Surface. Where at each point the Z component might change.

Some of the post processors are aware of modal commands, i.e. they suppress a component if it is the same as before. There would be the place to optimize redundant movements. It should not be too difficult for straight moves.

OK I will write a small script... most likely Perl (sorry my Python skills are a bit rusty) and publish it here. It would identify series a G1 commands going in the same direction (either X or Y) without changing the Z, we could simply skip all commands in the middle leaving only the first and the last one. Should be simple enough to translate into any other language...

[chrisb]

OK I will write a small script... most likely Perl (sorry my Python skills are a bit rusty) and publish it here. It would identify series a G1 commands going in the same direction (either X or Y) without changing the Z, we could simply skip all commands in the middle leaving only the first and the last one. Should be simple enough to translate into any other language...

At first sight I was repelled by having a post processor to the post processor. I would have liked it to be integrated into the existing code so that it suppresses the unneeded commands.
But thinking further it doesn't seem so bad, because such a function could easily be reused in different post processors.

[prius06]

At first sight I was repelled by having a post processor to the post processor. I would have liked it to be integrated into the existing code so that it suppresses the unneeded commands.
But thinking further it doesn't seem so bad, because such a function could easily be reused in different post processors.

Attached is the Perl script. I had to change the extension because the forum software rejected it.
My newest project using 3D Surface generated a 5.4MB gcode file with 145892 lines.
This script skipped 118071 redundant lines reducing it to 1MB of gcode with 27842 lines.

I am sure there is more that could be optimized but I am happy with these results.

[roivai]

Great! I had this in mind when I last time used 3D Surface, but as LinuxCNC was happy to swallow the huge G-Code, I forgot the whole thing. I think I'll try to find some time this week to implement that on Python so we can add it straight to the operation.

[schnebeck]

If I use Path simulation feature do I see gcode optimization or is a post processor add-on for simulation out of scope?

Bye

Thorsten

[chrisb]

Would it be sensible to slightly extend the script in order to make it more general by extending the equality condition so that it can optimize in Z-direction as well?

[prius06]

Would it be sensible to slightly extend the script in order to make it more general by extending the equality condition so that it can optimize in Z-direction as well?

I needed it faster and skipped the Z axis for two reasons:
1) Those are less common on the Z axis, at least as far as the 3D Surface processing is concerned
2) I ignore the feed rate and there are cases when you want the machine to go to certain point at higher speed (before entering the material) and then slow down which if eliminate could cause a crash

If it can be done but more care is needed, I was in a hurry when I wrote this.

[herbk]

Hi Guys,

just a few thoughts about roughing and finishing and the involved OPs...:

Atm, if i need a roughing, i do this steps:
For the roughing path i set the tool diameter to 4mm if i use a 3mm tool, a Ramp Entry Dressup and the final depth a bit higher.
With this thetting i remove the unneedet material, mostly with Poket OP.
For finising i remove the rest of the material with "real" tool settings and surface and contour OPs.

But i run in Probs if a not vertikal or horizontal part is involved, for parts like that 3D Surface should work better.

3D Surface has one big wrong starting point in my mind: It works allways with the whole object.
As written above, most areas of a part can be done verry well with existing OPs. It should be possible to reduce the working area of 3D Surface of the area where it's needet.

Atm i do that manualy, i just keep the base object of the "spherical or not vertikal part" as copy and use it with a own Job.

If i need a "Waterline" OP around a spherical part, i make cuts at diferent Z levels and use Profile by Face OP to create a "one level path", make the cut at a bit lower level, a one lvel path, and so on...
If i need to do that, i work with the old FC 0.16, because there i don't have to setup a new Job before i can get a path.

If i need a "Waterline" OP around a spherical part, i make cuts at diferent Z levels and use Profile by Face OP to create a "one level path", make the cut at a bit lower level, a one lvel path, and so on...

In my mind, thats a work what could be done automated or by a slicer...
I try'd to automate it, but i have no thought about python programming and the macro recorder don't work at the Path WB...

[roivai]

Hmm, said I'd work on the optimization some weeks ago, but finding spare time turned out to be harder than expected, once again. But I finally managed to make a trial on optimization of the OCL DropCutter output in 3D Surface OP. Still some polishing to do but I'm well past my bed time, so thought I'd call it a day and publish the intermediate result:
https://github.com/pekkaroi/FreeCAD/com ... 81b202526c

Initial testing with some simple model and flat end mill, the optimization was quite effective: from 30k points to 85 points. And this optimization is totally lossless, the removed points are really redundant points in the middle of a straight line of cut. Of course now it is done by comparing equality of floating point values directly, which is never a good idea, right? So adding some tolerances to the comparison would make sense, but then some accuracy may be lost as well.. I'll think about that later. Good night.