Here’s what I see (paraphrased here, gcode is toward the end of the post):
Rapid retract,
rapid y->29.612
Linear z->14.224 (at plunge feed)
YadaaYadaa…
Linear y->29.612 <- Note that this is last move on the layer, doing depth first waterline
Rapid retract <- Silly - It’s retracting to start the next layer (?)…and move y for no reason.
rapid Y->29.612 <- Silly - it’s already there.
Linear z->14.224 (Plunge) <- we just wasted a retract, then slow plunge. Across a ton of already cut space.
YadaaYadaa…
Linear y->29.612 <- Here we are again.
Rapid retract <- Silly - it’s about to move y for no reason.
rapid Y->29.612 <- Silly - it’s already there.
I want to post process out the unnecessary retract + rapid. Wouldn’t be quite so bad, but it does the whole plunge at the plunge rate. It should know that it’s already gotten through the above layer, so should be able to at least rapid back to, say, z- 2 depths, and only plunge the last two depths. Otherwise, you spend a lot of time waiting for a slow plunge through an inch of air that just gets worse on every layer. The better fix is just not do it, and just linear z+ at plunge rate to start the next layer.
Meshcam is annoying me. I’m looking for any tools that already exist to postprocess g-code. I’m well aware that I could probably throw some RE/Perl at this…but would like a little more elegant solution that didn’t need to be tweaked for every case. I can’t seem to google-fu myself to something already rattling around the interwebs for this sort of thing. Anyone know of tools that already exist for this sort of thing that might be modifiable? (gcode-optimmizer is…not something I want to break open again. I would have to teach it about Z, which is more than I really want to take on)
Simple Real Example (this goes on for a a bunch of cycles)
In this example, plunge and linear speeds are both 10in, so it looks like there is a redundant G1Fxxx, but it normally wouldn’t be.
MeshCAM wastes a LOT of time on useless motion or overly slow motion, like you pointed out. Have you considered trying one of the Vectric products? I assume they do much better based on all the feedback I’ve seen so far.
I’m on OSX, and would like to avoid a windows-only tool if I can. Not because I hate windows, just because mixing them is kind of a pain. If I’m going to go that far, I’ll just work on getting good at using Fusion’s CAM, something I already have. I suspect it doesn’t do some of the wasted motion but probably has other issues. All that said, maybe I’ll give vectric a shot at it and see how it goes.
While I recognize a lot of effort has gone into creating MeshCAM, toolpaths algorithms aren’t trivial, I’m getting kind of frustrated with it’s lack of polish (or even finish sanding in some places).
In that case, I must have mis-remembered. My apologies.
I’d think there would be some tools for doing this sort of thing — I’d really like to see a physics-based CAM / simulator which would adjust toolpaths and feeds / speeds on the fly (or a CAM tool which would do this).
I gave up looking for something that was close enough to hack up to do what I wanted. I kind of needed the distraction, so I’m working on one. Would like to know what other optimizations people would like to see. Side effect is that you could probably use what I’ve got to build a simulator too.
I’ve got these now:
linear/rapid to the same place the carriage already is
Retract/plunge in same location (not compatible if you’re doing programmed peck drill cycles) - still working on this one
Redundant G0/G1 (doesn’t make a difference in movement, but shortens what has to be sent to the buffers on GRBL)
Planning to do (but haven’t quite figured out how it will work)
Reorder to reduce rapids by layer (turn left, right, left, right, middle on the same layer into into left left middle right right)