I have 2 planes, PL1 is datum A (primary using minimax), and PL2 constructed from 7 basic scan/circle/plane. (least square, but it shouldn't change anything !)
Using geotol, it gives 7,1 µm
using legacy, it gives 35,1 µm
using assignments (ASSIGN/V1=DOT(PL2.HIT[1..PL2.NUMHITS].XYZ-PL1.XYZ,PL1.IJK) , then ASSIGN/V2=MAX(V1)-MIN(V1)), it gives 36,1 µm.
Then, constructing 7 planes from scans and construct a plane from their centroids, it gives about 8 µm (so I'm wondering if geotol uses them to calculate instead of hits ?)
The [..] trick has actually existed for a long time - it was just never documented. I'll have to get my developers to investigate what is happening for your case. Are you able to send me the program?
Of course, just shoot a filedrop link my way. I have changed it to the old syntax now, but will revert to [..] and test again prior to sending it to you.
I tried this as well [..] and it did not work, you can see that when you use the [..] with out the numhits the Theo and Actl do not populate with values ?
vpt.se and
Mike Rivard I finally got chance to take an initial look at this problem and it looks like the reason the feature doesn't update is because it has a space in the feature name rather than anything to do with the .. syntax. In VPT's screenshot, his feature is named PLAN MOTSATT A3 (notice the spaces). Similarly, in the routine he shared with me, his plane is named PLAN B (again, notice the space). If I add an ASSIGN/V1=PLAN B.NUMHITS assignment to VPT's routine, it turns red because it doesn't recognise the feature. As soon as I edit the feature name (either delete the space or replace it with an underscore) the plane updates, the numhits assignment returns a value and the error messages from the associated geometric tolerance commands disappear.