hexagon logo
Register Sign in
  • Replies 34 replies
  • Subscribers 225 subscribers
  • Views 362 views
  • Users 0 members are here
Options
Related

2022.1SP6 Parallelism issue

JEFMAN
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 ?)

Don Ruggieri , neil.challinor
  • in reply to Mike Rivard
    I'm working offline on 2020 r2 initial release. This still doesn't work.
  • in reply to Mike Rivard

    I'm working offline on 2020 r2 initial release.

    I'd strongly advise you upgrade. If you're not able to move to the most recent version, you should at least move to the most recently available 2020 R2 Service Pack. We made a number of significant functionality improvements and updates to the underlying GD&T library over the course of 2020 R2. The most notable would be to allow 2D features (lines circles and slots) as datums so as to better support our vision systems (since you are typically limited to only being able to measure 2D features when using a camera). We also changed the way in which slots are handled. In the initial release of 2020 R2 and in older versions using XactMeasure, slots were treated as circles - meaning that only the centroid was considered, not the orientation of the slot. From 2020 R2 SP1 onwards, slots are treated as pre-resolved widths and there is an additional toggle in the dialog to decide whether you want to consider the slot length-wise or width-wise.
  • in reply to Mike Rivard
    neil.challinor But the spaces are in the "destination" feature (the feature created from the NUMHITS features), there are no spaces in the NUMHITS source features. So, if you change the syntax to [1..FEATURENAME.NUMHITS], there will be no issues, but if you keep the syntax as [..], it will not work (while keeping the spaces in the feature name).

    I'd assume that removing the spaces in the feature name would make it work too.

    As always, thanks for the update!
  • in reply to vpt.se
    I ran quite a few tests on this issue. The construction HIT[..] will be the same as HIT[1..feature.NUMHITS].
    The no points issue comes into play when the constructed feature is used for the GEOMETRIC TOLERANCE (maybe just as a datum).
    During program load the GEOMETRIC TOLERANCE requests the hit information from the feature. The feature checks to compare the number of inputs it had during the last run or last user typed input change. If the number of hits last used does not match the current amount of hits that will be used the constructed feature will tell the GEOMETRIC TOLERANCE that there are no hits.
    This mismatch can happen if a parameter for the input feature has changed and the constructed feature is not executed. Or possibly if the input feature was executed and a different amount of hits was generated.
    Re-typing an input for the constructed feature (just backspacing on one of the . and adding it back in will trigger an update of the information on the constructed feature (which is why changing from HIT[..] to HIT[1..x.NUMHITS] would work. But so would backspacing on the .. and adding it back in.

    I loaded a PRG which contained the HIT[1..feature.NUMHITS], modified the number of hits of that feature, saved the PRG, opened the PRG and the GEOMETRIC TOLERANCE displayed the "Feature xx does not have measured data".
    It is not related to the HIT[..] entry.
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement