Probe WCS behavior for surfaces non-coincident with WCS plane

[wooded-bailout-0i]

So … riddle me this. I'm doing an update for the Carvera post-processor to handle probing operations for touch probes. We have the stock Makera firmware which is limited to setting the WCS via G38 + G10 L20. Then we have our community firmware in which proper probing cycles have been implemented.

The case I was considering was a setup with the WCS at the center of the part. Fusion will happily let me do an X or Y surface probe on this part. But … what is the expected behavior if you tried to do this?

From turning on debug output in the post-processor vscode plugin, I cannot find any hints in any of the parameters that Fusion might want me to attempt to compensate for this. Similarly there is nothing I can use to flag this as potentially being a disastrous thing to try.

Am I missing something here? As far as I can tell, such a probe operation would mean all subsequent tool paths would end up shifted in X by "-(stock_width/2)". 

If that's the case, this feels like a condition that should be fairly easily caught and prevented when choosing a surface, i.e. you are attempting to Probe WCS on a single surface that is not coincident with one of the WCS planes.

Ideally the parameters set for the cycle in post should also contain some hint so it can be caught there too. I just joined the insider program so maybe there's a way I can file a feature request?

I *guess* you might argue one behavior would be to pass in the offset between the two planes and compensate for that when setting the WCS. I'm fairly new to this but that would strike me as being, if a good idea at all, probably a separate type of probe operation to distinguish it.

Or, perhaps I'm somehow fundamentally misunderstanding how WCS Probing works, which is entirely possible and I'd welcome corrections 🙂

[a.laasW8M6T · Accepted solution]

Hi

You can quite easily probe surfaces other then those "coincident with the WCS"

Fusion will output a cycle that will se that surface as the distance from the WCS

I'll try and explain in this video.

[wooded-bailout-0i]

Haha! Don't I feel like an idiot, I was extending code that was assuming we were touching off to find zero on the surface and it didn't occur to me that I'm getting positions relative to that WCS. Thank you for turning on that light bulb!

However!! There's a reason my brain wasn't realizing this: how I got to this place was that I was already confused by the real problem I was having. I'm actually testing code that handles override driving WCS. For my first setup I have G54 set to that point you can see in the screenshot off to the left. This represents anchor point 1 on the bed.

So for my second setup, I set the WCS offset to 55, and I'm actually using the front/left/upper corner of the block. I then do probe operations setting driving WCS to 54.

But what I'm seeing in the post processor is all my coordinates being relative to setup 2s' origin which is WCS 55. Showing tool path data also shows the probe tool path being given coordinates relative to WCS 55.

Which kind of led me into thinking I have no idea how this works, haha. So then I tried something in the center and got more confused. I'll make your solution as accepted because I *definitely* had no idea how that worked and that was a big problem that I need to fix. But right after that I'll have to figure out what is going on with G55.

Here are two z-height probes. G54 is on the "bed" but I probe the top of the stock, so it will get set to that height. This is fairly common on the Carvera, normally you would use the built-in Z probe. Then I probe Z again but with override driving WCS set to G55 which is on the corner. You can kind of ignore the probe cycles since they're likely incorrect now anyway. What would have expected is for the G0 moves prior to the cycles to have the same coordinates. In the second probe it should move to X121 Y76 which is the center of the top face of the part.

I am pretty sure at this point either override driving WCS doesn't work the way I think it works, or we might have something fluffing things up in our post processor.

G54
G0 X121 Y76    (<-- center of part relative to WCS54)
G0 Z83
(begin probing-z - makera firmware)
(first z-probe for WCS 1 - starting probe from clearance height)
G38.2 Z-93 F500
G91 G1 Z2
G90 G38.2 Z-3 F100
G10 L20 P1 Z0
G1 Z33 F1000
(end probing-z)
G0 X121 Y76 Z83

(snip)

(probe-z-for-55 2)
M5
G0 X31 Y31 (<-- center of part relative to WCS55? Why not G54?)
G0 Z59
(begin probing-z - makera firmware)
G1 Z9 F500
G38.2 Z-19
G91 G1 Z2
G90 G38.2 Z-3 F100
G10 L20 P1 Z0
G1 Z9 F1000
(end probing-z)
G0 X31 Y31 Z59

[a.laasW8M6T · Accepted solution]

Hi

you cannot use override Driving WCS in the manner you describe unfortunately

Both G54 and G55 must be in the same location.

The idea behind override WCS is to use a "Master" location that is set on the machine and then use it to correct a parts location that may vary slightly from where it should be without overwriting the "Master WCS"

The way you are hoping to do it is not possible in Fusion but it sure would be nice if we could probe from one location and set a new WCS in another location.

You could do this by manually writing code but not with Fusion

[wooded-bailout-0i]

Got it! I would never have thought it worked that way, haha. I think one point of confusion is that so many videos and blog posts (aside: I think Barrett goes on to write the code you describe?) all have pictures that look like this:

That to me screams "two WCS in Fusion"! There are two right there in the picture, lol. If I can restate my understanding: it could actually be called "store probe result in offset". Conceptually we're just making a copy of the WCS and shifting its location based on whatever geometry we select.

I think another thing that has been confusing me, using the Carvera but reading about other machines, is that only G54 is kind of a protected WCS, but also the only one saved on power reset. The machine config actually stores MCS coordinates for anchor1 (and an offset from anchor1 to anchor2), and during job setup you have the option of setting your own origin. If you set it, G54 gets blasted with G10 L2 to the stored anchor1 (plus any offset). Every time you start a job you can see if your origin has been shifted since last time and correct that by setting the offset to 0,0 again.

Override driving WCS would be a lot more useful for us if we could (and we can in our own firmware) let someone set, say, G55 in a similar way so it's stored in MCS. But I can still document this as a way of probing your origin without causing G54 to be moved around. Otherwise if you're doing repeated parts you need to remember to set its offset to 0,0 every time.

Super appreciate your help on this!