hexagon logo

Diameter of a Cylinder -> Size Feature vs constructed cylinder

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
Parents
  • 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?
Reply
  • 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?
Children
No Data