XACTMeasure Position

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • XACTMeasure Position

    I am trying to measure Position in XactMeasure. I have MMB on primary and secondary datum. I run the part, it says Position is bad. I take MMB off, it says Position is bad. I turn MMB on, it says Position is good. How?

    I understand the Datum Shift/MMB relationship, but I am translating and rotating in all three X, Y, Z. How complicated is this fitting algorithm? As far as I am concerned, the shift values that I see are computer mumbo-jumbo that I cannot decipher whether or not the part is good.

    It'll tell me that the position of the feature is good, but the "position of the datum" is bad? Shouldn't it only shift to it's max allowable limit, not shift OOT?

    I have looked through a lot of posts on this forum, none that ever came to conclusion. This cannot just be turned off as it is a customer req't. Any clues?

    hex.jpg

    For those wondering, I am fixing part as in top image. Measuring -D-/Leveling X+. Measuring -E-/ Rotating Z+. Translating YZ to D and X to E.

    I am concerned about the Position of E to C and D.
    Last edited by JacobCheverie; 09-10-2019, 11:05 AM.

  • #2
    Try measuring it in Legacy and see what you get.
    Darroll
    2018R2

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      Darrollh I have tried Legacy but I cannot accurately use MMB with Legacy according to this forum. Some parts are failing without MMB and management is requiring it.

  • #3
    You can check out the two search result for more info on this issue. I don't think a solution ever came out of it and it remains one of those unsolved mystery today.

    Search result for datum out of tolerance

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      But is the part OK if the datum is reading OOT, or does nobody know?

  • #4
    If you look at the posts Sora linked, Josh Carpenter explained what is going on, although he did not have a reason for why it does it. His linked picture that really explained it well is now unlinked in that thread though From my understanding, IF it is ONLY the DATUM POSITION showing out of tolerance, then the part should be good, because these numbers have to do with the amount of datum shift that was used/available, not with whether or not the part meets the print.

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      That's why I mentioned that I have looked at the posts. On one, Carpenter states he doesn't know, he's just a CMM guy. On the other, there is a link to Carpenter saying it's a bug/shut it off/it's not important/only engineers with too much time on their hands care.

      I don't see an explanation there.

  • #5
    I am concerned about the Position of E to C and D.
    Well, for datum E TP, your FCF calls for datum C as primary, and D as secondary datums.
    Your alignment is not per FCF. How are you constructing Datum C and Datum D features?
    --Hopefully they are both very well defined cylinders, with axis lines as long as physically possible.

    -I am presuming in xact you defined the datums as C and D, yes?

    If you click on the "Custom DRF" box, what is Datum C controlling? what is Datum D controlling?
    First: C datum definition should be u,v,x,y
    Second: D datum definition should be z and w
    If not, you don't have your alignment per the print.

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      Xact should create the alignment for me. And yes, C is controlling u, v, x, and y. D is controlling z and w as they should.

      Datum D is a cylinder formed from two circles at each end. C is a cylinder of two levels.

    • louisd
      louisd commented
      Editing a comment
      Ok, so everything is correct. Must be the same bug Josh explained.

      You could locate and extract possible datum shift manually, to affirm your xactmeasure output is actually capturing true pass/fail if you are concerned with the red output line, I presume

  • #6
    Wait it sounds like, from reading the posts, that if datum/s shifts out of allowable boundary the part is good? How will the part fit in assembly? Anything that shifts far away from intended targets, too far, most likely won't play nice with mating parts... you'll need a big hammer.
    PcDmis 2015.1 SP10 CAD++
    Global 7-10-7 DC800S

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      Right, that would be my understanding. So now I am back to square 1. Neither Calypso NOR PC-DMIS can accurately handle MMB. We just renewed our SMA too..

  • #7
    I've had this issue before except my parts would check good even without MMB. I just removed it from the report per below.

    http://www.pcdmisforum.com/forum/pc-...datum-features

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      I saw this, I just want to know if this is truly a bug or if the part is bad before I start hiding things. Thank you

  • #8
    I researched the issue before as well, I don't have links to all that I found. But I made myself notes summarizing what I found.
    Note what I was researching was the tertiary showing RED...not bad, but RED, and yes Josh called it a bug, but another tidbit I found was that the root of the problem was reporting of this datum's position upstream of feature Xactmeasure reporting.
    I listed two solutions...I can't tell you I confirmed them, I think I did but...as I made the notes sometime last year.
    1) Either cast a feature (from the datum) for reporting (the datum's position) upstream, So positions downstream in program do not calculate MMB based position of that datum (particularly for tertiary as there are no brackets to enter MMB).
    2) Specify MMB (in brackets) next to datum in FCF in Xactmeasure.

    Hope this helps.

    Comment


    • JacobCheverie
      JacobCheverie commented
      Editing a comment
      Thanks Zero_micron_filter

      The issue I'm having is with the secondary datum showing OOT, not just red. Specification of the boundary size did not help me. I will try casting the feature.

  • #9
    Josh's ears are probably ringing! That guy was alright...
    PcDmis 2015.1 SP10 CAD++
    Global 7-10-7 DC800S

    Comment


    • #10
      If I were in your shoes, I'd do the following:
      1: Check without mmb.
      1a: If passes phuuuck it. it's a good part without shift.
      1b: If fails, start #2
      2: I'd be creating an alignment to reflect the FCF, then I would report xyz and diam's of both datums and the measured feature (datum E)
      I'd also create intersect point between C and D and report those xyz's (as that's your actual variation for D shift if you are level to D)
      trig it out on paper from there.
      3: Compare results,
      3a: If your trig'd data shows the part passes, and MMB shift would support passing the part, i'd start automating your math in assignments and generics.
      3b: if your data shows the part fails and isn't aligned with xact, i'd be calling hex, opening a ticket and making a big fuss.
      3c: if your data shows the part fails and is aligned with xact, you just confirmed that the demon is actually doing something right!

      Comment


      • JacobCheverie
        JacobCheverie commented
        Editing a comment
        louisd I will give it a shot in the morning. Very logical, thank you.

    • #11
      Let's ping Rob Jensen on this one.

      I am with JacobCheverie on this one, having the fitting algo only to use the max available bonus from the datum, making the datum in tolerance and the feature OOT - never the other way around (fitting the feature to it's best position which could make the feature in tolerance, but rendering the datum OOT).

      I think the general consensus is to have it reversed from the way it is today.
      PC-DMIS CAD++ 2o19 R1 SP4

      Comment


      • #12
        Going further with what louisd mentioned, I'd like some verification to make sure that I am doing this correctly. I set my alignment per the FCF (level Y+ to [C], Rotate X+ about Y+ to [D], Origin X,Z on [C] and Y on [D]). Correct?

        I dimensioned [C], [D], and [E] per my FCF alignment and found the following.

        [C]: dx = 0, dz = 0, dy is irrelevant as is expected, I.D. size is .00023 over MMC size. This allows motion inside the walls of a hollow cylinder of wall thickness .00023, correct?

        [D]: dx is irrelevant, dy = 0, dz = -.00061. O.D. size is .00451 under MMC size. This allows motion inside the walls of a hollow cylinder of wall thickness .00451, correct?

        [E]: dx = .00015, dy = -.00188, dz is irrelevant. I.D. size is .00034 over MMC size. This implies that [E] is .00015 off center in X and -.00188 off center in Y of a cylindrical tolerance zone of size .00234 (Position tolerance of .002)

        Now 2*sqrt(dx^2 + dy^2) for [E] implies a position of .00377 - OOT by ~.0014


        BUT WAIT: Datum Shift.

        [C] can slide over .00015 to eliminate dx for [E]. [C] is still OK, nothing out of bounds here.
        [D] can slide back .00188 to eliminate dy for [E]. [D] is still OK, nothing out of bounds here.

        Now [E] position is 0 and part is OK.

        Now why is it telling me [D] is OOT?


        Then I shut MMB off for both datums, part is still bad (by about .0014).
        Then I turn MMB on for both datums, everything is A-OK.

        Something is wrong.

        Comment


        • louisd
          louisd commented
          Editing a comment
          Considering the functional interface of the D datum: It seems like it has threads on the end? Almost like a swingarm or rod end, correct? The D datum shaft as it approaches the C datum seems like it's just a span from the threads, correct? Try rotating about a line you construct from a circle as far down towards the end of D that you can, to the center of C. See how that works out.

          C datum is your primary datum and XZ origin, you should be rotating about the centroid of C, radially outward to D. not orthogonal to the whole D datum, if that makes more sense.

        • JacobCheverie
          JacobCheverie commented
          Editing a comment
          louisd no threads, no rod end. Just a shank with two bores at each end perpendicular to one another. I will try rotating about a line constructed from D to C but that should only do two things:

          1.) Alleviate the error in Z between C and D
          2.) Shorten or lengthen the position of E relative to C

          And I think you may have misinterpreted my alignment scheme. I am leveling (Y+) to C. Then I am rotating D (ABOUT Y+ (C)) to X+.

      • #13
        If datum D is a plane - and OOT as datum in the TP - then something is very wrong.

        EDIT: Noticed that datum D has an OD, ergo not a plane. Weird dimensioning as the datum is connected to the surface of the cylinder - not the centerline...
        PC-DMIS CAD++ 2o19 R1 SP4

        Comment


        • JacobCheverie
          JacobCheverie commented
          Editing a comment
          D is a cylindrical shank. E and C are also cylindrical.

      • #14
        Something for you all to read
        Deleting Datum shift from FCF and Report Deleting Datum Shift(fcf) From Report Template.JPG
        Michael A Wildschutz Sr

        Comment


        • JacobCheverie
          JacobCheverie commented
          Editing a comment
          Thanks michaelwildschutz but I need the datum shift to pass the part and I need it to calculate correctly. I don't want to just eliminate/hide it.

        • vpt.se
          vpt.se commented
          Editing a comment
          ^^ this!!!!!!!

      Related Topics

      Collapse

      Working...
      X