hexagon logo

Portable flips the part 180° in alignment

This is getting ridiculous, sometimes when running alignments on planes, PC-DMIS flips the part 180°, despite the
fact that all my vectors are correct, theos and whatnots. We have to remeasure the part several times and hope
to hit the correct millisecond PC-DMIS uses to create the alignment correctly...

This is unacceptable and needs to be fixed - is it just me that suffers from this? We are burning daylight because
of the software at this point and not because the parts are incorrect - because we never get to the point where
we can see that...

 It doesn't even work with bestfit alignments as the primary plane used for alignment gets flipped.

If this is a "thing" in PC-DMIS that can't be fixed, please tell me that so I can find another software that works...

Is there anything in the settings editor or the general settings that can cause this behaviour?

EDIT: Pardon my tone, but we have higher-ups whipping our behinds.

PLAN_A     =ELEMENT/PLAN,REKTANGULÄRA,KONTUR,NEJ,GAUSS
            TEOR/<0,-312.819,-170.147>,<-1,0,0>
            MÄTT/<786.374,-681.37,-725.283>,<-0.0237684,0.999715,-0.0022286>
            KONSTR/PLAN,BA,PKT_A1,PKT_A2,PKT_A3,,
            TA_BORT_EXTREMVÄRDEN/AV,3
            FILTER/AV,VÅGLÄNGD=0
            REFDEF/A,ELEMENT=PLAN_A,,
A1         =UPPRIKTNING/START,ÅTERKALLA:START,LISTA=JA
              UPPRIKTNING/PRIMÄR,XMINUS,PLAN_A
              UPPRIKTNING/FLYTTA,X-AXEL,PLAN_A
            UPPRIKTNING/SLUT

This is the measurement and alignment that flips.

  • Changed the PLAN_A from BF to BFRE and that seem to have worked (for now) OR we hit that millisecond...
    If this is the way forward (using BFRE instead of BF) why is that?

  • You should always use BFRE if you are constructing a feature from actual measured points.  BF should only be used when the inputs to the construction do not have surface data (think intersection points / pierce points / generic points / cast points, circle centroids etc).  BFRE first fits a feature through the centroids of the raw hits, then applies the probe radius compensation whereas BF simply fits the feature through the already compensated hit locations.  Because BF is not considering the probe radius direction, it can sometimes flip the direction of the plane - as you are seeing.

  • This was unknown to me, so please file this under the user error category,   Grimacing

    It started working as soon as I changed it to BFRE and as you might recall, I have been hassling you about this "flip" a couple of times...
    I (most probably all of us) really appreciate your presence in these forums, you should be awarded the "lifesaver" trophy!

    This could mean that a huge headache has been removed from our portable endeavours! Heart eyes
    (doing a happy dance... and no, there are no images or videos from that dance routine so don't ask)

  • I've had issues with 3D best fit alignments if I'm not using enough features. For example, if I use 2 circles and do a 3D best fit, there is an occasion where it will flip the entire cad 180 degrees. What we have found that we need to use at least 3 features, as this essentially creates a 3 point plane of the features centroids. We almost never use BFRE as we usually just leave it on Auto because auto selects "BF", and that's what we use.

     Is Best Fit Recomp doing the same thing as Probe Compensation? Or are these two separate calculations? 

  • Similar but different.  Each hit has a radius correction value stored with it internally (based on whichever tip was used to take the hit).  BFRE then applies that radius correction value along the surface vector (based on the feature it has already constructed through the raw hit centroids).  "Normal" probe compensation applies the probe radius value along the probe hit direction which, depending on various factors, may or may not be approaching square to the surface.  If your probe isn't approaching square to the surface when you take your initial hits, you get cosine error.  Performing a BFRE construction on those same hits will correct the cosine error.

  • I have noticed that the arm defaults to machine vectors,.  If I use auto features with the part physically upside-down, I have to create a temporary upside-down CSY.  I don't see any settings to disable this helpful characteristic.

  • We feel your pain. We have many many programs for the Romer. The flippy trick they like to do is always fun! 
    The easiest way we found to prevent it is to align machine axis of the arm with the trihedron of the startup alignment for your part. Each of our Romers, and Leica have the axis clearly labeled for ease of use.  

  • This is one of those "helpful features" that really needs to be disabled.  Believe it or not, I'm perfectly capable of figuring out on my own that I intentionally place a part on its side or upside-down. 

  • Here I was, thinking it only occured to me...

      Is there anything that can be done in the underlying PC-DMIS code to prevent this phenomenon from happening? I mean, we don't want the flip to happen. I have seen it happening when aligning on cylinders picked from CAD. No matter what I did, the flip occured anyway, when it clearly according to the program code should not happen... This surely has to be a "bug" since it shouldn't act like this?

  • You are not alone! We are here for you! 

    ....Have not noticed this behavior in PolyWorks though. Same arm, same parts, same datums. But to be fair the number of samples is vastly smaller, seems before my coworker and I started no one had even considered using PolyWorks for hard probing. We Googled it, then a few Yolos later its now our standard practice when scanning most parts. If only we had that Mesh license for the Demon, but my boss is dragging his heels. I would kidna prefer to scan most of our stuff with DMIS because you have WAY more control of things, such is life.