hexagon logo
Register Sign in
  • Replies 16 replies
  • Subscribers 221 subscribers
  • Views 319 views
  • Users 0 members are here
Options
Related

Diameter of a Cylinder -> Size Feature vs constructed cylinder

Alvaro
Dear PC-DMIS users, colleagues, and experts,

In the last months, in the company where I'm currently working, we've updated our PC-DMIS software to one of the newer versions (2018 R1), and have found a new possibility to report sizes with all the ISO modifiers integrated. For us this is great news, since now we can apply the modifiers directly on the measure rather than through the elements construction.


Doing so, we've found that using the "enveloppe" requirement, that for an external diameter should grant the GN for the USL, and LP for the LSL, gives the same result as demanding each modifier separately (which is good), however, the GN hands a different value than when constructing by Best Fit & Min Circumscribed cylinder (same points, same element, by scanning and then constructed).


and then demanding the diameter through the loc feature

We observed that the result is the same regardless of alignment, we also observed that the Mean Squares and GG modifier result on the same diameter (which is at is should be).
We tried the same idea with the GX diameter, and a Max Inscribed Best Fit Cylinder, and the problem is reproduced. The value for diameter is different in a magnitude close to 0.01 mm.

I'd like to know which of our assumptions is wrong, (that a min circumscribed best fit cylinder should be equal to GN for example, or maybe the diameter calculation through the localization feature), and why is it wrong. Or, if it may just be a problem of our programming that can be solved.

As a bonus question, I'd like to know if the size feature with modifiers that I show in the first screenshot will be available for two parallel planes (or it already is and we didn't find how to use it correctly, which is certainly possible).

Thank you very much for the time taken to read this far.

Best regards,

Álvaro
Attached Files
  • in reply to AndersI
    You are right, I forgot to say that we tried both BF and BFRE (since we don't change any hardware during the measurement), the new size feature always yields the same result, but BF and BFRE both yield a different result ( and the same between them ). Thanks for your time Slight smile
  • Hello Aaron,

    Thank you very much for the quick, concise, and perfectly understandable answer(s).

    I'll keep all this in mind! (probably the 0.01 mm difference is due to the diameter being with a huge & irregular shape defect.

    Best regards,

    Álvaro

    Glad I could help with your problem Slight smile

    Now that's a bit unfair - there are quite a lot of definitions of 'size', and not always a definition of the algorithm in the standards. The blue answer in post #2 - https://www.pcdmisforum.com/forum/pc-dmis-enterprise-metrology-software/pc-dmis-for-cmms/442930-diameter-of-a-cylinder-size-feature-vs-constructed-cylinder?p=442940#post442940 - explains it quite well, IMO.


    I think it's fair to complain a bit, not about the changed calculations but about the lack of communication or documentation regarding these changes.
    If it would be explained like above in the help files or even the release of the version with this new feature, we would have to put a lot less time into finding the reason for these differences.
    Especially with how many problems 2018R2 has, every changed result might be another bug. This makes us put more time into verifying if the results are actually reliable.
  • now that's a bit unfair - there are quite a lot of definitions of 'size', and not always a definition of the algorithm in the standards. The blue answer in post #2 - https://www.pcdmisforum.com/forum/pc...940#post442940 - explains it quite well, imo.

    {"alt":"Click image for larger version Name:\tSize.PNG Views:\t27 Size:\t76.2 KB ID:\t443015","data-align":"none","data-attachmentid":"443015","data-size":"full"}

    it is a different calculation by design. We are using constrained l2 math for maximum inscribed and minimum circumscribed in the size dimension but are still using the original max_inscribed and min_circumscribed math everywhere else in pc-dmis.

    The size dimension command is new so does not affect program migration but does causes confusion in the case you describe in this report (comparing with math from other commands). The results from constrained l2 are more precise and more repeatable, so we are planning on changing the math in other areas of pc-dmis beginning in 2019 r2.

    The software reports different results (and uses different algorithms) for calculating MAX_INSCR / MIN_CIRC...

    This is coming from people who are in the committee and decided not use the L2-way throughout PC-DMIS, so why implement one calculation for this function and keeping the old one for other functions, wouldn't it be better to implement it all over the scope when the STD's has been released?

    User A uses the older calculation stating the dimension is within tolerance, because PC-DMIS says so. User B states the dimension is bad as he uses the newer calculation in PC-DMIS. See a possible disagreement here? Which is the correct answer?
  • , there's actually some variance in commitee between "pro L2" and "pro minimax".
    ASME is going to validate L2, ISO ...? The new ISO5459 which should come in 2018 isn't updated now.
    I think L2 is more stable than minimax on some features, and I think everybody can use it (even if he's in ISO world) just explaining he's using it.
    For years and years, we used least squares on datums (with all softwares !), even if it was Chebychev the rule !
    The comparison between different results on the same part will be valid only when we are able to calculate uncertainty taking into account the method...and it's not for tomorrow Wink



  • In theory, you're right, 2 are enough (ellipse case), but on real parts, when you dimension the roundness (not the circularity !) of a max_inscr or min_circ, there are often (always ?) three points with a t_val=0.



    Just a thought : "in theory" works only if the number of hits is even, and the form perfect.
    I forgot that the constructed circle pass through the hits, whatevr the algorithm...
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement