yeah I noticed the 0.4" fusion weirdness and I think I detect that correctly now
Before:
After:
Before & After screenshots of the camotics view of the optimized gcode from @rmonroe 's test files
the red vertical lines are retracts or plunges in a place the bit previously has been
7 Likes
oh duh lol, the answer is “keep a list of all the places that tool has previously been. full speed plunge is OK if the tool is revisiting at a height that is greater or equal to the previous height”.
well played.
makes a HUGE difference during cutting
like for basic carbide create pocketing… it will enter for the multiple layers always in the same places… so the plunge can go fast upto the previous point and then go slow for the last “depth of cut” distance
so a small tweak to your sentence “and if the target depth is deeper than the previous, split the plunge in two so that the first part can still go fast”
nice. Good job fixing the retract thing too.
good catch on the correction to my plunge logic btw.
I’m going to abandon my python script since your interface is so much more usable for the average joe.
Want the extra test files? (you’d be getting them tomorrow, about to be busy)
might as well… sample size of 1 is a bit on the thin side for heuristics 
psssssh when I write code, if it works once, it’ll work every single time. What are you doing over there 
1 Like
Plunges should be rapid to the “working height last used above the current working height”, not just arbitrarily set to a rapid. Whether this will “just work” without extra work depends on the specific post, some post already do this, some do not (the older meshcam post for grbl doesn’t, but I think the more recent one does)
yeah absolutely the plunge has to be split into two parts… that’s what the tool does.
(at some point Rob mentioned that carbide create is getting post processors, and even in javascript. if/when there;s some information about that I’ll make one that does the plunges better
1 Like
Wonder if they’ll be close to the meshcam ones - same guy, different software.
Here we are:
@wmoy generously gave permission for me to release a number of posted files from his projects, which I prepared before and after the fusion change.
File format is as such:
/<#>_<good/bad>.nc
where
<#> = nc file within op, or “all” if it is the entire setup in a single operation (“good” only)
= tool number
= human readable opname
<good/bad> = “good”: before the fusion change | “bad”: after the fusion change
Not all files have a matching good/bad file: there were some errors in the toolpaths on the first/second time in a few cases
Once the diff thing is nailed we can review the results!
with current git the diff should be much much smaller than before.
it;s not zero yet, but very targeted to places where work needs to happen at least
hey that’s what we want
This topic was automatically closed after 30 days. New replies are no longer allowed.
Hey @rmonroe and @fenrus, was there ever a conclusive finish to all this work? It looks like you did a lot of work so I’d love for myself and others to be able to use it.
it works… is it pure optimal? that’s a different question.
the curious mind in me is wondering if a bigger picture optimizer for gcode is possible… but that’s outside of the scope of adding some rapids back
1 Like
Optimal is subjective depending on how much of a perfectionist you are. 
I’m glad it works so I’ll use it on some upcoming work. Thanks for putting in all this time and effort.
@WillAdams - I looked through all those options and didn’t find one that specifically added rapids back in based on the descriptions next to them. Which ones are you thinking of?
1 Like