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

Thank you for the in-depth explanation!
I still have a few questions and comments.


I knew about the new syntax but thought the old method was still valid. There are many routines which were created before 2020R2 and the old syntax still works.
Are we discouraged to use the old way? If so, I think this method should be removed or auto-converted.


Regarding the extracted value - the numbers still don't add up though.
In the report, I also evaluate the Z-distance from the plane and from each of the four points (after aligning to datum B).
The Z-value of the plane is 43.857548mm which is still around 0.045mm away from the extracted value.
In fact, the extracted value, is nearly identical to the "best" distance of the 4 individual points. How can this be?


Even if PC-DMIS is extracting the centroid value, that would still be unfortunate behavior.
There are multiple reasons why one would expect the worst deviation to be extracted:

1. What you see is what you get / Consistent behavior
   If PC-DMIS lets the user extract a value of an evaluation, most users will expect to get what is shown on the report and not some value which is nowhere to be seen.
   In fact, for most other feature/evaluation/axis combos, you will actually extract what you see in the report.
   As an example, I evaluated the position (X&Y-values) of a cylinder. There, the extracted values are the same as in the report. (see on second page of the attached report)
   These values are the worst deviations of the cylinder and not the centroid deviations.
   This leads to believe that you will also get the "correct" value when extracting from a position evaluation of a plane.
   
2. Standard compliance / Usefulness
   The standard expects the worst deviation to be evaluated. That’s why in the evaluation itself, it's reported this way.
   So when extracting an axis data, in my opinion, the only useful value is the worst one and not the centroid.
   If one would want the centroid one could just report the distance between two planes or the Z-value after aligning to the datum plane.
   
3. The report doesn't always gets looked at
   Many companies don't print the report but collect the data in another way.
   We for example collect our data in a .CSV file using the file write command.
   The current behavior makes getting the "correct" axis data extremely difficult.
   And makes the data that we collected so far invalid.
   

Because of this, I kindly ask that Hexagon could change the current behavior.
Last year I already wrote an idea to let us easily extract axis data:
https://ideacenter.hexagonmi.com/communities/40/topics/1216-easy-access-to-axis-data-of-geometric-tolerance-commands
But this was before I found out that using the old syntax extracts the "wrong" value.
With this information, it is even more important to get an easy to use way to extract axis data.

Expression.PDF

​

My apologies I mislead you slightly, the returned measured value from QA1637.Z.MEAS is actually the first point of the plane. If you turn on the textual analysis you can see the data
​

You can see the (1) 43.810238 represents the value obtained from ASSIGN/V_QA1637=QA1637.Z.MEAS

The issue as you have identified is that this not the worst point, point number (3) is the worst value and this is what you wish to extract. This will change for each part obviously.

I did reach out to the developers and the syntax QA1637.Z.MEAS is the old way to use expressions. It may work with single features and single segments but not multi feature/multi segment. For example if you report position of 4 holes the dimension_name.X.meas would only return the first hole in the pattern.

With the geometric tolerance command because it supports multiple segments and features you use the QA1637.SEGMENT[1].FEATURE[1].MEAS. This does return the measured value of the true position. The expression builder lets you create QA1637.SEGMENT[1].FEATURE[1].MEAS but not QA1637.Z.MEAS unless you type it into the program. Where we are lacking is the ability to pull more data than the measured, deviation, nominal etc

For the measured value of the individual axis in your example we could not identify a way in which to obtain this other than as I indicated in my previous mail.

Your suggestion in the ideas centre is a good one and I will discuss this with Neil when he is back from holiday. Thank you

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

​