Wednesday, 11 September 2019

Fusion 360 probing - first working postlet!

Where are we?
Having got a simple probing macro working (see previous post), the next step is to knife and fork the embryonic "Centroid post with probing" to cause Fusion 360 generate the correct g-code to run some sort of probing event. I managed this - almost - previously, albeit with some manual edits required to weed out troublesome code that the Centroid controller disagreed with. In particular, it generated an M3 (spindle ON) command. Although the set speed was 0rpm for the Renishaw probe, it was right to question (override) the M3 request. I also had problems with the retract height which was somewhat excessively high (60mm). Of course, that's really down to the settings in the CAM that generated the operations rather than the post itself.

So, having managed to butcher the probing_bore.cnc macro to the point of functioning, along with the probing_update_x.cnc to make the results stick, let's try to implement that in my evolving post processor.

Probing post additions / changes to enable the "Bore" probing moves:
I made the following changes / additions to the post code:

    case "probing-xy-circular-hole":
      // move slowly always from clearance not retract
        gFormat.format(65), '"c:/cncm/system/probe_get_modals.cnc"'
        gFormat.format(65), '"c:/cncm/system/probe_bore.cnc"'
        gFormat.format(65), '"c:/cncm/system/probe_update_x.cnc"'

and this last bit ("if (spindleSpeed != 0)..." etc to prevent outputting M3 when the set speed is 0 (ie probe tool etc):

if (insertToolCall ||
      isFirstSection() ||
      (rpmFormat.areDifferent(spindleSpeed, sOutput.getCurrent())) ||
      (tool.clockwise != getPreviousSection().getTool().clockwise)) {
    // changed spindleSpeed < 1 to "< 0"
        if (spindleSpeed < 0) {
      error(localize("Spindle speed out of range."));
    if (spindleSpeed > 99999) {
      warning(localize("Spindle speed exceeds maximum value."));
    if (spindleSpeed != 0) {
      sOutput.format(spindleSpeed), mFormat.format(tool.clockwise ? 3 : 4))

This is what it generates. Looks good to my semi-trained eye.
O00010 (Test Fusion probing functions)
(T10  D=6. CR=3. - ZMIN=-6. - probe)
N10 G90 G94 G17
N15 G21
N20 G28 G91 Z0.
N25 G90
(Circ hole)
N30 T10 M6
(Renishaw probe)
N35 G54
N45 G0 X55. Y20.
N50 G43 Z30. H10
N60 G65 "c:/cncm/system/probe_get_modals.cnc"
N65 G65 "c:/cncm/system/probe_bore.cnc"
N70 G65 "c:/cncm/system/probe_update_x.cnc"
N75 G80
N80 X0. Y0. Z30.
N90 G28 G91 Z0.
N95 M30

And yes, it works - sort of. The output is still full of my debug messages but the functionality is there. It's only proof of function at this stage and there are a few logical errors, such as line N80 which originally told the machine to go to X55 Y20 again after probing. Having reset the G54 origin to ~X55 Y20 at line N45 before probing, this would end up taking the tool to ~X110 Y40. I need to save the original coordinates somewhere and use those to set the corrected offsets so that the WCS tool position is "X55 Y20" in the current WCS at the end of the sequence. It should be close to the original X55 Y20, with only a slight movement due to the probing correction.

No comments:

Post a comment

4th axis action - wrapped 2D Adaptive test

Let's try this thing out! There are only 3 simultaneous 4th axis operations available in Fusion (2D Adaptive, 2D Contour and 2D Pocket...