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":
      forceXYZ();
      // move slowly always from clearance not retract
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_get_modals.cnc"'
      );
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_bore.cnc"'
      );
      writeBlock(
        gFormat.format(65), '"c:/cncm/system/probe_update_x.cnc"'
      );
       break;


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) {
    writeBlock(
      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.

Thursday, 5 September 2019

Fusion 360 probing - updating the current WCS

Updating the current WCS after probing:
I will attempt to get the current WCS updated (corrected) after probing, as a first step. From what I can see, this should be something like:

       #2501 = #5021 - for the x coordinate

       #2601 = #5022 - for the y coordinate

where #2501 is the (read write) current WCS x coordinate (read / write) and #5021 is the (read-only) current x coordinate. 


This seems to work:
It's full of debugging messages, created using the G10 command. Without that I'd have had a royal time of trying to figure out WTF was going on. They can come out later on if I can be bothered.

Here's the macro I've been using in MDI (by typing "M72") to do the probing and updating - it initialises the probing parameters, calls the bore probing macro, then runs the update macro:




It may seem like great progress - and I suppose it's a lot better than what I had a week ago - but I'm still a LONG way off having anything ready to go, even if we overlook the post processor bit (which will need to generate the g code to actually run these probing macros).
  • It doesn't check to see if there is actually a probe fitted, which could be a problem for the probe tip if you start probing with the tool inserted but forgot to plug the probe in. There's a loop back circuit for just that purpose, so that safety function needs to be added.
  • You don't necessarily want to set the WCS origin to the final probe position. In many cases, you want to preserve the existing origin location.
  • ....

Wednesday, 4 September 2019

Centroid post processor for Fusion 360 probing - update

Gnnng, oooph. Yes, this is truning into quite the workout. Figuring this out - and indeed implementing it - requires a lot of work on several fronts:

Javascript:
Various textbook sources for this, such as Peter-Paul Koch on Javascript and A Beginners Guide to Javascript by John Pollock.

Also a video tutorial on Javascript by Mosh Hamedani - "Coding with Mosh" which is pretty good for $15. There's a taster on YT for free, which in itself is useful stuff:

Javascript tends to be used by website designers but it's what Autodesk chose to use for their postprocessors. To be fair, it's not too bad but much of the JS content out there is focused on stuff like CSS and HTML which is of no relevance here.

Post processor development:
As mentioned previously, Visual Studio Code is pretty neat, being more like an IDE than a simple editor, although I've been held back on using this in anger by the need to focus on learning enough Javascript to get by. In the meantime, I've been trying to digest the various Fusion probing posts, so I can get a feel for what is involved. These are the probing posts from Fanuc and the Path Pilot (aka LinuxCNC) post that seems to have been created by David Loomes up in Jockland, the land of my forefathers.

The Fanuc posts make use of special Renishaw probing macros. Obviously these are no use to me, as the Centroid probing system is quite different in operation. Also, the Fanuc Macro B syntax is (naturally) different to Centroid's own macro dielect.

The Path Pilot / LinuxCNC post is written for LinuxCNC, so the macro calls are quite different from both Centroid and Fanuc.

Probing macros structure:
At first thought, you might believe that probing is a pretty simple matter of running the probe into a surface (at controlled speed!) and noting the coordinates where the probe input changes state. But you'd be underestimating the work required. Generally, the work is broken down into a series of common macros that are in turn called by the various top level macros. So there's a sort of hierarchy of macros at play here.
These are the 6 main operations supported by the in-built probing functions within Centroid CNC12:
  • Bore (4 way probing a hole to find the mid point)
  • Boss (4 way probing a boss to find the mid point)
  • Slot (2 way probing a slot to find the mid point)
  • Web (2 way probing a web to find the mid point)
  • Inside corner (2 way probing a corner to find the apex)
  • Axis (1 way probing to find a surface)

I've plotted them out and listed the macros they call in turn. There can be as many as 10 nested macros called by the first. Some are high level macros ("Level 1" in my terminology), which call lower level macros, most are lower level macros and some are both.



They usually require to be passed parameters such as the feedrate, direction of feed, target coordinates etc. And will generally output information in the form of system variables in the range 34000 onwards.

Thus, probe_boss.cnc macro requires parameters for clearance distance and height, feed rates for horizontal and vertical moves, axis number and initial direction (X = clearance dist in X or y; Z = clearance height; E = axis number; D = initial direction; F = traverse rate; B = plunge rate), in the following format:

                probe_boss.cnc X[x]  Z[z] E[e] D[d] F[f] B[b]


It returns the measurements in system variables #34574  =#5041 (current x position); #34575  =#5042 (current y position); #34576  =#5043 (current z position); #34578  =#34562 (width 1 from boss macro); #34579  =#34563 (width 2 from boss macro).

That's all very well, but while I don't want to reinvent the wheel that Centroid has honed over many years, the existing Centroid probing macros don't do exactly what is required by the Fusion probing functions. So what have we got and what do we need to come up with?

Here's the list of Fusion probing moves and the closest available in the Centroid macro ("system") folder:


It actually looks as if most of them are sort of covered. The angle probing may well be doable, judging by the Centroid macros such as probe_angle.cnc but I can come to them later. I seem to recall that Centroid have implemented angular correction in their probing functions.

The main missing feature is the requirement to update the WCS reference point / origin with the probed coordinates. This is where I got a bit misled....

Centroid have their own system variable numbering scheme. In places, it's the same as used in Fanuc Macro B - and in other places it has its own numbering. Here's a link to a listing for the Fanuc variables.

Centroid's table:

As you can see, Fanuc variables #5221 etc are numbered as #2401 etc in Centroid, yet #5021 (MCS) and #5041 (WCS) are the same in both. The #5221 vs #2401 thing threw me for a while. I was getting an "undeclared variable" message when I tried to reference #5221 but hadn't seen the #2401 hiding in plain daylight. Even more confusing is the way the WCS variable numbering differs between Centroid and Fanuc - for instance, x coordinates increment by 1 as the WCS increments from G54 to G55 etc, yet Fanuc correspondingly increments by 100. Similar but different...

The probed value needs to be written back to the WCS variables in order to correct the offset as a result of the probing measurement. As an example, I think this is how you would place the current X WCS number in variable #34831, which I will use to update the current WCS X coordinate offset:

       #34831 = 2501 + #4014 - 54

The X coordinate for WCS G54 is held in variable #2501. For G55, it is held in #2502 and for G56 it's held in #2503 etc. Similarly, the number of the current WCS is held in variable #4014, starting at 54 for G54. So subtracting 54 from that variable gives 0 for G54, 1 for G55 etc etc.

The corresponding expression for the current WCS Y variable number would be:

       #34832 = 2601 + #4014 -54

Of course, Fusion actually increments the WCS before updating the offset when doing in-program probing, leaving the initial WCS offset unchanged. For example, probing in G54 will create a G55 origin where the corrected G54 origin should be. I must figure out how that is handled at some point...

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 "Centroi...