PC-DMIS 2021.2 - Possible bug with variable of position evaluation

Hello

I think I found a bug with the extraction (in a variable) of the z value in a position command.

I have a position of a plane to datum B (also a plane). The nominal distance is 43.64mm.
The measured TP value of the feature is 0.518015 and the measured z-value of the feature is 43.899007.

When extracting the z-value via a variable I get a totally different value of 43.810238. A difference of approx. 0.09mm

To verify the result of the position feature, I aligned to datum B and evaluated each z-value of the plane.
The worst z-value of the individual points is 43.899024... so nearly identical to the position evaluation.
So the error must be in the extracted value.

I don't have any special characters in the name of the features.
PC-DMIS version is 2021.2 SP8 (Build-Nr. 524).

neil.challinor Don Ruggieri

May I send the routine to one of you guys to investigate?

Parents

Aaron Baldauf over 1 year ago

And again my reply:

I have to apologize for the late answer. We had a long weekend here (because of Easter) and it is quiet busy here at the moment.

Thanks again for reaching out to the developers and clarifying this issue in such detail!

With the textual analysis it makes sense now what value gets evaluated.
Unfortunately this now also confirms that all our extracted data since changing to the geometric tolerance command can be wrong.
This wasn't noticed from our side because, depending on the feature used and depending on where the worst value is located, the extracted value can still be correct.

For now we will be unfortunately be forced to get back to the legacy reporting as they provide an easy to use way to extract all the axis data.

I still see this behavior as a bug (even if working as designed) because it is not what the user expects to happen when using this "old" syntax (that PC-DMIS still accepts).
What makes it even more confusing is that in all my examples just one feature got evaluated (one plane or one cylinder respectively). I think nobody would expect that just a subset from this feature would get exported.

Because of all the reasons mentioned in this and the last mail, I want to ask Hexagon to escalate this topic internally and change the current behavior.

further tests.PDF
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Reply

Aaron Baldauf over 1 year ago

And again my reply:

I have to apologize for the late answer. We had a long weekend here (because of Easter) and it is quiet busy here at the moment.

Thanks again for reaching out to the developers and clarifying this issue in such detail!

With the textual analysis it makes sense now what value gets evaluated.
Unfortunately this now also confirms that all our extracted data since changing to the geometric tolerance command can be wrong.
This wasn't noticed from our side because, depending on the feature used and depending on where the worst value is located, the extracted value can still be correct.

For now we will be unfortunately be forced to get back to the legacy reporting as they provide an easy to use way to extract all the axis data.

I still see this behavior as a bug (even if working as designed) because it is not what the user expects to happen when using this "old" syntax (that PC-DMIS still accepts).
What makes it even more confusing is that in all my examples just one feature got evaluated (one plane or one cylinder respectively). I think nobody would expect that just a subset from this feature would get exported.

Because of all the reasons mentioned in this and the last mail, I want to ask Hexagon to escalate this topic internally and change the current behavior.

further tests.PDF
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Children

No Data