"Tertiary axis/plane is parallel to Primary axis/plane." ERROR

  • Filter
  • Time
  • Show
Clear All
new posts

  • "Tertiary axis/plane is parallel to Primary axis/plane." ERROR

    Hey all, I've lost about half a head of hair on this one.


    So I programmed this lovely part and everything was going fine until I got to the dimensions. First dimension I tried to create gave me the Error message, "Tertiary axis/plane is parallel to Primary axis/plane." After doing some digging here on the forum I thought I had found a solution relating to the fact that my Alignment is rotating off of a Constructed Line from Datum -B- and Datum -C-. So far I think I have eliminated that as a possibility, and I think for once the error message is pretty self explanatory.

    My datums are, the flat underside of the part for -A-, in the ZMINUS vector. -B- and -C- are two holes in the XMINUS side of the part both pointing in the XMINUS vector. PCDMIS is automatically making the angle of the two Datum holes the same as my Datum -A- angle, in the Z vector.

    I tried changing my alignment around to be 100% sure that all Degrees of freedom are constrained in all of my alignment in case that might have caused an issue. NO CHANGE.
    Next thing I tried was just manually changing the Angles of the holes were so that they would not be Parallel to -A-. NO CHANGE.
    Lastly I recreated the Datum features manually entering the vector and angle that I wanted. NO CHANGE.

    I also made a new program just to test and make sure that it wasn't just a glitch in the program I had started and I got the same results.

    From this and what I've attached are you guys seeing any red flags in what I'm doing/not doing? Or is this possibly an issue with the model?


    Capturegs.JPG Last images shows the angle value I currently have assigned to -C- that didn't seem to change anything.
    Attached Files

  • #2
    In ISO world, the tertiary datum should define the last translation.
    Here, A is a plane, so it constrain a translation and two rotations. (Z translation + rotations around X and Y)
    B and C are circles in X minus plane, the line between them is along Y (becarefull in datum_B, angle_vec is X-, so it's a bad def for a circle !), and theoriticaly parallel to Z plane.
    It can't be a good definition, because it depends on the depth of circles, so It can't constrain the Z rotation or the X translation accurately.


    • #3
      We can't see all the code that derives the alignment rotation (Xminus_PLN is missing), and we don't know the FCF print spec (maybe your FCF is [TP][0.010][B][C][A] for all we know).
      Please let us know how your dimension in question is called out, and please post code of XMINUS_PLN

      From what I see in the code you posted, you have a couple issues.
      1. no code changes in current workplanes when working in Xminus
      2. as jefman said, although the vector direction is in Y, the B-C line is parallel to your A plane (both 0.705 in z).
      3. not sure of how you made the XMINUS_PLN, so can't really provide input until we see the code on that.
      4. from what I presume your alignment should be:
      Level Z to A,
      Rotate Y minus to xminus_pln (presuming it's the planar surface where b and C are),
      Origin Z to A,
      Origin X to xminus_pln
      Origin Y to B datum.
      Last edited by louisd; 05-08-2019, 01:36 PM.


      • #4
        The Datum Reference Frame you describe has several problems and cannot constrain all 6 DOF. If this is how they actually call it out, I would tell the customer that their callout doesn't work and ask them what they want to do about it.


        • Loon4ever
          Loon4ever commented
          Editing a comment
          That's what I've been leaning towards and the edge of said lean is rapidly approaching.

      • #5
        Crap I would say ignore the XMINUS plane since that was just from me experimenting, forgot I hadn't changed it back, but it's just an Auto Feature.
        The Missing workplane changes...whoops thanks for pointing that out.

        JEFMAN The angle_vec for the circle I manually input. Originally it was aprox "I-0.0 J-.02744 K.99966"
        does this look more correct? I agree on the fact that this ABC alignment the engineers are telling us to use doesn't constrain all 6 degrees of freedom. So were you trying to say it's more of an engineering issue?

        louisd If I rotate the xminus_pln to Y minus that rotates my part 90 deg the wrong way. And the Profiles I am trying to measure are to ABC.

        Thanks again for your past, present and future help guys. I am an Inspector first and foremost and CMM Programmer/Operator second but we've got a bunch of Boeing parts coming through that all require CMM reports so you might be seeing more of me on here. It's been almost 2 years since I had my CMM 101 class so things have been forgotten, like the missing workplanes so your help is immensely appreciated.


        • louisd
          louisd commented
          Editing a comment
          yeah, print definition makes for location along X uncontrolled, no matter how you setup the alignment, my bad.

          --although rotating and origin-ing to the face that has the B C holes on it would enable 6dof control, and enable you to measure the part; it's not per the drawing.

        • Loon4ever
          Loon4ever commented
          Editing a comment
          Yeah that's the final conclusion I came to. Exactly what I recommended our Point of Contact tell the engineer in fact. Nice to know I haven't forgot everything.

      • #6
        Angle_vec defines where the measurement begins.
        If the workplane is X-, then you can begin on Y or Z, or whatever vezctor with I=0.
        It can sometimes give strange results if I<>0 in this case.


        • Loon4ever
          Loon4ever commented
          Editing a comment
          Good to know, Thank You.

      Related Topics