Probe WCS angle - weirdly shifts

[pulcik]

Hi guys,

I am playing with F360 WCS probing and tweaking PP. But when I reach the Angle WCS measurement I can not wrap a head around one movement F360 does. Maybe it is a bug, may be it is a feature. Either way, I would like to understand it.

I will try to describe it on situation, so you can replicate it.

Lets say, we have a block, with some angle feature on top, like one on this picture. 

And you are trying to probe that angle on the feature. The probe itself have some Diameter, and probing strategy have Approach, Spacing and Overtravel options filled out. F360 will generate "toolpath" or attributes for the probe macro should I say, as it is more precise description.

For my understanding, for Renishaw macro, we need Overtravel, Angle (of the feature we are probing on), Spacing (between two probe points - parallel to axis) and X or Y position (of the feature surface in midpoint / starting position). This picture from Renishaw manula helps to clarify:

I added a question mark where the shift happens in fusion. The way, how PP for Fanuc calculate the Y attribute = Yorigin + Approach + 1/2*Probe Diameter. For simplification we can say Y coordinate is 0. It means, the "?" size is determine by those Approach and Probe Diameter attributes and thus is fixed.

But I noticed, that this "?" size is shifting if I change the angle of the feature.

When the angle is  80° it has smaller size than 45° which have smaller size than 10°. But Approach and Probe Diameter is the same.

Why is that happening?

My issue with that is, Fanuc PP doesn't compensate this movement at all. I think it is not crucial, as the importance is the angle, which we are measuring. But anyway, If I want to calculate how far should I probe in desired axis,  I am calculating the distance by Y or X attribute compared to my starting position. And this distance will be wrong / shifted by this shift. This issue can be hidden in overtravel distance which is 10 mm by default, but if somebody put smaller overtravel, it can happen that probe doesn't reach the feature and rise an issue.

Or am I missing something?

[DarthBane55]

Hi, is everything your described happening within Fusion itself, or some of this is in real life?

Asking because if it's all inside Fusion, when you change the angle of the feature, and regen your probing toolpath, the toolpath will align itself to the new angle, so the approach distance will be the same, always.  If I am not understanding correctly, could you put some pictures of various angles and the toolpath result here, so we can picture it a bit better?

[pulcik]

It is within F360.

It is hard to describe, I know. I think exactly as you said: 

so the approach distance will be the same, always. 

But it is not. That is why I made this post. I think it should be the same, too.

Here I tried to make a prove of that shift. I stack two pictures together. One with 40% opacity. Everything is same except the angle of the feature. For better visualising the issue, I align the pictures by bottom probe point. 

So it is visible that approach distance is different.

Is that good enough?

[pulcik]

I might find where this is coming from.

When I rotate the same pictures, so I can align them by the feature angle, then the distance is correct. It is just extended by trigonometry. But, I still think it is wrong way. Don't you think?

[DarthBane55]

well, looking at your pictures, it looks kind of correct to me...  but, it creates some sort of "illusion" because of the angles.  Would you be willing to share this file here so we can look at it properly?

[pulcik]

What files you have in mind?

Fusion f3d? You can make that example in one minute in F360.

The pictures? I think it is pointless.

But I still think it is the wrong approach from F360 to that topic.

I will describe two cases, and you can tell me which seems correct to you. Might be just differences in point of view.

Case 1)

The Approach distance is distance the probe have to travel from starting of G31 to the touch point on the feature surface where G31 triggers and stops. It means, it is exact distance on the G31 axis.

Case 2)

The Approach distance is distance on normal vector to the feature surface (perpendicular to the feature surface) from starting position. It means, the G31 have to be calculated accordingly to the angle of the feature, as the G31 moves will be bigger on X or Y axis (depends on which axis we are probing) than this normal vector itself.

Both cases seems to be legit. I just think, the case 2 have unnecessary calculation and is not straight forward compare to what F360 visualise as toolpath. The approach distance is just (cos(anlgeoffeature) * approach) bigger. But for what reason?

May be it is just my way of thinking...

[DarthBane55]

Yeah, I meant the fusion file.  I don't spend my day recreating people's files, just to be sure I get exactly what you mean I thought using your file was the best way.  I'll leave others to help now.

[pulcik]

Yep, no worries.

With the file, it wasn't meant to be rude. I just did not realize, it can be helpful as it is just a box with angled surface.

The "issue" lays in process of generating the the toolpath, so it is not visible at first sight and is more of a question for developers.

You actually helped. As I realized how are those numbers created and thus I can work with them. The process just seems to me overcomplicated, than as a bug. So, thank you for your time.

If anyone want the file, I attached it to this post.

[pulcik]

As I am trying to construct a macro, I found another hint, that it was not meant to be like that.

The "quick tip' for the Approach option is nicely descriptive and states that Approach is indeed distance from contact point at which the probe starts to approach the part for measurement.

In reality it is not, actually. On the following picture, the black lines are 30 mm lines (same as Approach distance) but green lines are 43.8 mm (Approach / (cos(angle)).

And why am I so laud about that? I don't think that Renishaw macros compensate that and working incorrectly in that manner.

[rengfx]

Well my default values for approach etc are tied to tool diameter, and certainly don't know of 15mm dia probes for 2*dia approach distance etc.

I've read this post several times and I don't understand what the real world impact of how the approach angles are visualized or managed behind the scenes change how 2 points in space found by G31 skip contact with a known distance traveled in a single axis isn't just a simple trigonometry problem. You can do this with an indicator mounted in your spindle and some math

I've also repeatedly used the Probe WCS for angle on Setup2+ parts with amazing success, not needing to sweep any axis parallel to X or Y throwing the part in I've had opposite face features like Chamfers come right on perfectly using these cycles.

Where are they failing you?

[pulcik]

I moved this to support board, because I realize, it might be small error.

https://forums.autodesk.com/t5/fusion-360-support/angle-wcs-probing-approach-doesn-t-seems-to-be-cal...

But as you mention, the impact on real life is almost non.

It is more about the information, that it might be a small misunderstanding in process generating / outputting data in PP. And is completely fine, as the nature of probing is searching the points rather than confirmation. There is just tiny probability, that probe fails in certain situation, because of that.

As I am coding my own macro, I just compensate this, so the calculations are correct 100% time.

[rengfx]

Okay I think you've not fully realized the difference in using a referred datum to probe an angle, and probing what SHOULD be a 0 angle surface for WCS to update it.

Here is a picture example with the G code, note how the Probe Geometry features in 1001.nc have A values outputted, from the referred datum?

And now in 1002.nc that the Probe WCS exact same Renishaw macro callout, has an A angle of 0, because that is what is it is supposed to be, according to the CAM layout setup WCS an expected surface.

BUT because perhaps someone knows they can run this cycle and not specifically align a part to the X or Y axis (making it 0 reflecting exact CAM setup) they're not throwing the part in at huge off angles like 20+ I wouldn't think, so the approach distance etc are sufficient to always contact the part  and get the desired result

Now Probing an angle midpart, if your machine ball bars out correctly, and makes 90 degree angles + interpolates circles well, is well what exactly are we checking here? It would be inherent to machine performance / setup so doing that mid cycle on a part to confirm an angle seems counter intuitive to me. However since in the this REFERRED DATUM scenario it has an A value output to control it still approaching in single axis, you can see in my picture I deliberately made 2 angles to show how one approached only in X or Y

Your concern from my reading seems to be there wouldn't be contact or the Probe would "fail" meaning not contact the part? I think this is all inherently accounted for in the cycles approach + overtravel value, also inherently managed by the desired approach angle.

Also an operator would just hand edit these values to be larger if somehow there was an issue reaching the part, I do this all the time on SMALL features with low clearance, typically the approach distance is too great, so I lower it on the fly in situation 

Hope some of this helps

[pulcik]

---

@rengfx wrote:

Okay I think you've not fully realized the difference in using a referred datum to probe an angle, and probing what SHOULD be a 0 angle surface for WCS to update it.

I am fully aware about that difference. Actually that is the reason, why my potential error doesn't really have a big impact on real life. If the angle probing can export even X / Y coordinate, then it will be significant error and probably fixed right away.

I think the issue has tendency to occur when you probing big parts with big Spacing between probes. With bigger numbers the difference in cos / sin gets bigger and thus might get out of overtravel range. Overtravel is the hero who saves the day in this case.

Here is my picture. I recreate your setup, export the probing sequence as you did. So far, it is same as yours. But then, I reconstruct the movements from gcode back to the model. Take a look at the dimensions. You will find out, that one dimension (red boxes) is not matching. In this particular case, the G31 moves should be G31 y26, which still have around 1.4 mm overtravel and thus probably trigger. But it is getting close to not trigger, if the angle on the feature will be significantly lower. 

 

If you want, try to reconstruct the step backwards in your F360. From your G-Code to fusion. I am curious, if I am correct.

It is still hard for me to describe it. But the "error" is more visible if you are familiar with PP coding. Would be actually very helpful, if somebody from developers team can share their point of view.

 

 

[dwilliamsFM6K4]

You haven't recreated that setup, you're still trying to probe a random angle relative to your Referred Datum, if you haven't already probed your WCS prior to running the code you just posted, the machine wont find anything

How exactly does your Gcode have an A value when you haven't probed your WCS yet? Oh yes because you are REFERENCING a datum

Your setup WCS has nothing to do with the angle you're probing, again what is the real world issue of where this process has resulted in continuous fails output from Fusion that needs to be addressed?

Demonstrate the failure you're so certain is plaguing users of this process

[pulcik]

Sorry, I still do not understand exactly, what you are trying to say.

You haven't recreated that setup, you're still trying to probe a random angle relative to your Referred Datum

Yes, I am trying to probe random angle relative to my Referred Datum. But that is how it works in core, no? By probing WCS, you are just finding the real position of that datum on machine coordinate system. The correlation of that numbers outputted for O9843 macro to datum doesn't change, by probing WCS before. But yes, angle should be probed as last.

If you haven't already probed your WCS prior to running the code you just posted, the machine wont find anything

I don't think so. I think the machine will find an angle defined in Renishaw manual as "The nominal angle of the surface measured from the X+ axis direction positive angles (counter-clockwise). " But that is all. Just an angle. No WCS, that is right.

How exactly does your Gcode have an A value when you haven't probed your WCS yet?

Are you asking, how the javascript in PP exactly do that? PP put that number (angle) there from the datum you are specifying during the setup (Stock point). But for the angle, the vector of positive X axis is crucial. The datum can be wherever in 3D space. When the F360 know where the X+ is, it can export the angle. Lets say, the angle it exports, is just reference to the angle you want to measure. You can output that macro call without A value and measure the angle. But than, you can not use Tolerances option in Probe WCS setup.

Your setup WCS has nothing to do with the angle you're probing...

I don't agree. The macro O9843 need this for necessary calculation of the movement you see as Toolpath in F360. That is the reason, why it is exported by PP at the first place. As you see on gcode export, there is not gcodes related for those motions. The macro have to construct them when it is called. That is why it needs some inputs, like Spacing, Overtravel, and "mid-point surface position" as Renishaw manual call that X/Y coordinates. But yes, the WCS doesn't influence the angle itself. Just the motion for finding it.

[rengfx]

Look at your picture my friend, you're trying to leverage a WCS setting feature but don't understand it

What is the point of probing an angle that ISNT parallel to your X or Y or Z WCS vectors? The typical workflow here, is on non Setup1 to Probe in the following order to create a proper datum

Z Touch -> XY Touch -> "Angle along" (either) X or Y

The reason for this is it allows the MACHINE CONTROL to utilize the stored read Angle (#189 / #193) to either leverage G68 on a 3Axis machine, or set axis angle on a 4th / 5th to ALIGN the part face with the machine

Your posted picture above, is checking an ANGLE that isnt, any of your WCS vectors, so until you're actually talking about REFINING the angle of a datum, none of this makes any sense.

Here is my example in 2 Setups again, you probe "Angle Along Axis" to REFINE a previous acquired work plane to either leverage G68 or set (in my case) C Axis angle for 5 axis work

As soon as you either Single Touch an XY Face or do a Web setting center, then have the next operation, be along the desired axis to "set" the angle (really just have G68 activated by the PP and read #189 on HAAS or on 5 axis set C axis angle) and you'll find the overtravel / approach more than adequate

I've literally not had this cycle fail, I've used it on VM-6 size machines on 48+" parts with success

[pulcik]

First of all, thanks for your time, guys and help. I appreciated. I am reading your posts many times so I am not misunderstand.

But it seems to me, that I understand what you are saying. But you do not understand what I am trying to describe. 

Z Touch -> XY Touch -> "Angle along" (either) X or Y

Absolutely agree with that. That is the right way to start the job. There is no question about that.

The reason for this is it allows the MACHINE CONTROL to utilize the stored read Angle (#189 / #193) to either leverage G68 on a 3Axis machine, or set axis angle on a 4th / 5th to ALIGN the part face with the machine
Yes, of course. Agreed with that and want to add, that (#189 / #193) are not impacted by that miniscule error, if the probe trigger. 

Your posted picture above, is checking an ANGLE that isnt, any of your WCS vectors, so until you're actually talking about REFINING the angle of a datum, none of this makes any sense.

That is where we our opinions splits. The O9843 doesn't need your WCS to be aligned. This macro is actually responsible for the alignment. That is why you have in Setup 1 > Probe Angle Along X. Even though, you put the stock to the fixture, which is probably already aligned by previous calibration. Imagine, you put your stock in the fixture but the fixture move from whatever reason. Then Probe Along X will give you that skewed angle, so you can align the angle to machine axis by G68 or 4th/5th.

When you have 4th/5th axis, you can indeed align measured angle to WCS axis and then measure it. In that case, the error I am trying to expose, is gone. Because there is no trigonometry involved. Everything is perpendicular it that time. But on 3 axis machines, routers especially, you can not rotate 4th/5th axis an you can not probe with g68 active. It is even mention in Renishaw manual "The Renishaw probe cycles cannot be used while co-ordinate rotation is in force, i.e. cancel code G69. ". So, at those machines, you have to probe the angles as they are on the part itself. You can not rotate the part in fixture. But that is OK, as the O9843 can work in +- 180 degrees. That is why we have A value in the macro call.

As soon as you either Single Touch an XY Face or do a Web setting center, then have the next operation, be along the desired axis to "set" the angle (really just have G68 activated by the PP and read #189 on HAAS or on 5 axis set C axis angle) and you'll find the overtravel / approach more than adequate

Agree with you. That is why, I am saying, the error is meaningless. Especially, when your workflow is setup in a way you are describing. Then the error is not involved at all. So it is non existent. But you truly do not have to align the angle to the WCS axis.

I truly apreciace your time and help. But it seems, you are misunderstood what I am trying to describe. And that is OK, as it is quite difficult to describe it, especially to someone who did not code PP and macro from it. I will be on a same page with you in that case.

Plus everything works for you correctly. And I completely understand why. Everything works for me correctly, too. I just know about tiny error / misleading code in PP core. So, we can leave it like that, guys. Till someone from inside of  F360 team will be discussing this it is pointless, I assume.

Once again, thank you guys.