FreeCAD Forum

Thanks, that's a great tip. In fact having "skip recomputes" at a higher level makes sense since if you could disable for one path, you would effectively disable the entire job from recomputing anyway since it would never be up to date. This top level option also prevents triggering potent...

yeah , these 3D paths, nice as they are, are incredibly slow to recompute. Especially if you use small intervals to get a good finish. That makes machine time pretty heavy too. Best to turn off the auto recompute on the path you are working on until you have set all the settings you think know you n...

then right-clicked and chose the 'Send to Python Console' option Ah, that is something I had no idea about. Very useful trick. Thanks. This will probably be useful in another mod I was working to get milling holes and spirals to use the path feed rate as the actual tool speed, not the speed of the ...

Hi Russ, happy Easter ! Sure , passing the object is trivial to add, however I'm not sure of the structure and how to get to the Tool object. I spent some messing with dump(obj) earlier it kept throwing exceptions and gave up. Where can I find the definitions of these objects , so I can go straight ...

I made something like this a few years back. I was mainly let down by the alternating cut directions which degraded the finish. I don't know whether there is a fix for that now.

https://catking.net/cnc-img/degree-disc-assy.jpeg

CAM doesn't reuse preference settings of Path. Is this worth a regression bug report? IMO effort should be made to make life hard for users and constantly break stuff. Broken backwards compatibility happens far too often in FreeCAD. Mostly in avoidable circumstances. It can't be much work to get it...

Hi Russ , good to hear from you. I haven't seen you around here in quite a while. That tip about parse() if very useful. When setting the default rapid depth for each stage of peck I wanted to use fraction of the drill diameter but it did not seem to be available, so I settled for basing it on drill...

Hi, Wolfgang pointed out in another thread that grbl_post.py was not expanding G73. I'd never noticed this because I tend to use peck rather than chip-break. Since this is very close to G83, without the retraction to R-plane it was easy to implement. I also liked his idea of adding --chip-break para...

Here grbl_post.py with G73 added and a --chip-break parameter as you suggested.

Test and let me know if you think it is working correctly.


PS don't forget to take the "G73" out of the file name.

Current implementation already has a chip break in G83. It is trivial to let G73 take the same path. I'll look at skipping the retraction move and we'll have G73. This NIST standard is very fuzzy about the retraction distance literally saying "a bit". Your idea of adding a post-proc argume...