Centroid Community CNC Support Forum

Muzzer wrote: ↑Mon Apr 26, 2021 3:24 pm I found that Peter Smidt doesn't cover dwell in G84, as it's not std in Fanuc Macro B. However, as pointed out, it's a parameter used in Centroid's G84. I played with this some time ago - and thought I had concluded that it didn't help much. This evening I've just played with a dummy file, doing some air tapping and sure enough, it's clear I was talking out of my backside - not for the first or last time I'm sure.

My machine takes ages to slow down and restart due to the large motor and reduction gears in low ratio, so I need about 2.5s pause to allow the tap to revert to where it should have been if it had stopped quickly. That's with no load of course - a large tap would stop almost immediately.

Here's the line that does the tapping:
(S250 M3)
G98 G84 X0. Y0 Z-10 R5. F500. P2.5

It taps to 10mm depth with a pitch of 2mm and pauses for 2.5 seconds.


What I think I DO recall is that the Fusion 360 Centroid post doesn't post the dwell (P) times, so you need to manually edit the code if you want one. Which might be the closest I get to an excuse here. I suppose, if Swissi hadn't decided to edit the post to include the P parameter, it might have been sensible to fix the issue by editing the macro executed at the bottom of the hole (specified in parameter #75) to autogenerate a pause. But indeed the best result would be a Fusion post that passes the pauses through. That way you could always create a parametric expression in Fusion to shorten the pause with larger taps for instance.

I'll get there in the end! Apologies if I talked down to anyone along the way.

IPGregory wrote: ↑Sun Dec 31, 2023 1:11 am Has anybody managed to use Swissi's PP with TIm Patterson's Fusion PostProcessAll plug in?

Edit - I think I am getting there. Looks like you need to edit Swissi's PP file and set the variables there directly as the plug in bypasses the PP in Fusion completely and only uses the file. So, any variables set in Fusion's PP dialogue are ignored.

Muzzer wrote: ↑Sun Dec 31, 2023 10:32 am There were certainly several issues with the plugin. The main aim was to get around some of the limitations of the free version of the Fusion CAM, namely the restriction to one tool (no changes) and slow rapids. The output files were pretty clunky and TBH I concluded that the benefits of the "paid for" version (£/$360 a year until recently) were worth the cost.

You can see some of the issues I encountered 3 years ago. Forgive the idiosyncratic style - the blog is mainly a diary of stuff I've done for my own record. The fixes required playing with the PP and some experimentation with the results(!). That's not to criticise Tim's work but you would need to decide if you want to go this route.
https://mightyshiz.blogspot.com/2020/12 ... n-360.html

IPGregory wrote: ↑Sun Dec 31, 2023 4:54 pm If I read it right, it looks like the issues you noticed were related to tool changing, rather than rapids? At the moment I am just going to try it with a single Op to see what it does with the rapids only.

Muzzer wrote: ↑Tue Jan 30, 2024 1:06 pm It's a bit of a hazy memory now but IIRC, the file names got all messed up too. Even if you ran one tool at a time, the output files were difficult to work with. As a technical exercise it was pretty cool but as the main benefit was reinstating the rapid moves, it didn't feel that benefit was worth the cost.

My Fusion licence went up 15% this year (£396 to £462 in the UK), although that included a discount for continuing an existing licence. They may well hike it a lot more next year of course......

Hopefully Swissi will help you with the PP files question.