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

​

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

​