hexagon logo
Register Sign in
  • Replies 20 replies
  • Subscribers 222 subscribers
  • Views 206 views
  • Users 0 members are here
Options
Related

line measurement inconsistancies depending on workpiece orientation

Daniel P
Dear CMM gurus!

You might or might not be aware of a nasty behavior of PC-DMIS when measuring planes. If the actual plane you're measuring has a normal vector that's pointing into a direction more then 90° different from the plane's theoretical normal vector, the measured normal vector flips such that it's pointing into the workpiece instead of out of it. (I should probably add here that we're not using PC-DMIS for inspection purposes per se, but rather for precision adjustments of components, which is why it is very common that our workpieces are located and oriented a lot differently than the corresponding features' theoretical values.)

With lines, however, I have not yet encountered a similar problem----until last week. According to my tests, the following alignment procedure for a cuboid-shaped workpiece will yield consistent results:
  1. measure a plane (theoretical normal vector <0,0,1>, actual normal vector anything as long as its Z component is positive)
  2. level and Z-translate to the plane
  3. measure a line on the workpiece's side (side perpendicular to the plane measured before,workplane = ZPLUS, apart from that no restrictions to how much the side surface's normal vector may differ from the actual one)
  4. rotate XPLUS and Y-translate to the projected line
  5. measure a point on the third side (side perpendicular to the previous two with a consistent approach vector)
  6. X-translate to the projected point
In particular, with this strategy the line's directional vector has consistently been pointing in the correct direction no matter which way the workpiece was oriented. However, I did run into a problem recently under the following circumstances:
  1. start a subroutine
  2. reload an external alignment of which the Z axis and the origin's Z component are to be left unchanged
  3. measure a line under the exact same conditions as above
  4. rotate XPLUS and Y-translate to the projected line
  5. measure a point under the exact same conditions as above
  6. X-translate to the projected point
I would have expected this to behave exactly the same as the scenario listed before, but this is not the case. Here, the line all of a sudden becomes dependent on the orientation of the workpiece. If the actual line vector is pointing into a direction more than 90° different from the theoretical one, the actual line vector flips and is pointing into the opposite (wrong) direction. Furthermore, I noticed that the line and the point used for the alignment become red in the alignment's edit dialog. However, I did confirm that they are getting measured by outputting the measured directional vector through an operator comment----including the directional flipping.

Can you give me an explanation for this weird behavior and the red features in the alignment?

Thanks a lot in advance! 

STARTUP =ALIGNMENT/START,RECALL:USE_PART_SETUP,LIST=YES
ALIGNMENT/END
MODE/MANUAL
PREHIT/1
RETRACT/1
MOVESPEED/ 100
MANRETRACT/1
FORMAT/TEXT,OPTIONS, ,HEADINGS,SYMBOLS, ;NOM,TOL,MEAS,DEV,OUTTOL, ,
LOADPROBE/KU_5X50
TIP/T1A0B0, SHANKIJK=0, 0, 1, ANGLE=0
SUBROUTINE/BS_LISA22_FULL,
=
MODE/MANUAL
RECALL/ALIGNMENT,EXTERNAL,BASE_FINE
AM_LIN =FEAT/LINE,CARTESIAN,UNBOUNDED
THEO/<18,0,3.5>,<-1,0,0>
ACTL/<18,0,3.5>,<-1,0,0>
MEAS/LINE,2,ZPLUS
HIT/BASIC,NORMAL,<18,0,3.5>,<0,-1,0>,<18.032,0,3.494>,USE THEO=YES
HIT/BASIC,NORMAL,<4,0,3.5>,<0,-1,0>,<3.842,0,3.494>,USE THEO=YES
ENDMEAS/
AM_LIN_P =FEAT/LINE,CARTESIAN,UNBOUNDED,NO
THEO/<18,0,0>,<-1,0,0>
ACTL/<18,0,0>,<-1,0,0>
CONSTR/LINE,PROJ,AM_LIN,,14
COMMENT/OPER,NO,FULL SCREEN=NO,AUTO-CONTINUE=NO,
"AM_LIN: " + AM_LIN.IJK
"AM_LIN_P: " + AM_LIN_P.IJK
AM1 =ALIGNMENT/START,RECALL:BASE_FINE,LIST=YES
ALIGNMENT/ROTATE,XMINUS,TO,AM_LIN_P,ABOUT,ZPLUS
ALIGNMENT/TRANS,YAXIS,AM_LIN_P
ALIGNMENT/END
AM_PNT =FEAT/POINT,CARTESIAN
THEO/<0,1,28>,<-1,0,0>
ACTL/<0,1,28>,<-1,0,0>
MEAS/POINT,1,WORKPLANE
HIT/BASIC,NORMAL,<0,1,28>,<-1,0,0>,<0,1.745,27.279>,USE THEO=YES
ENDMEAS/
AM_PNT_P =FEAT/POINT,CARTESIAN,NO
THEO/<0,1,0>,<0,0,1>
ACTL/<0,1,0>,<0,0,1>
CONSTR/POINT,PROJ,AM_PNT,
AM =ALIGNMENT/START,RECALL:AM1,LIST=YES
ALIGNMENT/TRANS,XAXIS,AM_PNT_P
ALIGNMENT/END
COMMENT/OPER,NO,FULL SCREEN=NO,AUTO-CONTINUE=NO,
BS: after AM
SAVE/ALIGNMENT,BS_manual.aln,MACHINETOPARTS
...
ENDSUB/
​
  • A quick update from my side: According to my tests it actually doesn't matter if the origin lies between the two hits or not. It seems as if the orientation of the workpiece is the only relevant factor, but I'm still trying to analyze what's really triggering the flip. and I still don't have a clue why the features used in the alignment are displayed in red even though they clearly do get measured.

    The good news is that I was able to write a very short subroutine dedicated to fixing the directional vector. It takes the line's pointer as a parameter, checks if the directional vector is pointing from hit 1 to hit 2, and flips it in case it's pointing the wrong way. However, until I really understand the root cause of the problem, I don't feel comfortable enough yet to fully trust this solution...
  • I hope this visual helps to answer your questions. This error will repeat regardless of internal/external alignment being recalled.
    ​
    ​
    Attached Files
  • Thank you very much for taking the time and preparing this diagram for me. VERY much appreciated! I've been busy these last 10 day programming and testing and (as far as I can make out) your suggestion of an alignment recall before the measured line indeed seems to be the culprit whereas there is no problem if a plane is measured before the line. Needless to say that this behavior is weird to say the least.

    However, there is a difference to what I believe you described: the line's correct directional vector needs to be rotated by more than 90° either way from its theoretical values for the flip to happen----so it doesn't seem to be a matter of a positive or negative rotation. To me, it actually makes a lot more sense this way because otherwise the bug should have surfaced in many much more common inspection scenarios as well.

    As mentioned above, I wrote a super simple subroutine dedicated to fixing the directional vector for two-hit lines and I'm going to share it in case anyone else runs into the same problem: 
    LIN_DUMMY1 =GENERIC/LINE,DEPENDENT,CARTESIAN,$
    NOM/XYZ,<0,0,0>,$
    MEAS/XYZ,<0,0,0>,$
    NOM/IJK,<1,0,0>,$
    MEAS/IJK,<1,0,0>,$
    DISTANCE/0,0​

SUBROUTINE/FIX_LINE,
    LIN = {LIN_DUMMY1} : THE LINE TO BE CHECKED AND FIXED,
    =
IF/DOT(LIN.IJK, (LIN.HIT[2].XYZ - LIN.HIT[1].XYZ)) < 0
    ASSIGN/LIN.IJK=-LIN.IJK
END_IF/
ENDSUB/
​​

  • ASSIGN/LIN.IJK=-LIN.IJK
​​

    Does this work for you? I would assign a variable with the vectors and create a new generic line using these variables if I were you.
  • don't know this helps but it could be your work plane.

    I have found inconsistencies with some features if I'm not in the correct work plane. specially lines



  • in reply to constadin
    that would work in the instances that the vector will be incorrect/flipped. recurrence varies based upon position and condition of the new sample on the machine. sometimes it can be positive, sometimes negative. the real fix is to just don't program a rotation datum when the origin is in the middle of the rotation line. or don't use a line. as i have already mentioned.
  • in reply to constadin
    As mentioned above, the location of the origin (between the hits or outside to either side) did not influence my results at all. It's only the orientation of the line (more than 90° off in either direction) and only if there was a recalled alignment before it. A plane is no solution either, by the way, because of the normal vector flipping bug I described at the very beginning of this thread. In case of a plane it's even worse because not only does the normal vector flip but PC-DMIS thinks the probe points were on the other side of the probe sphere, which results in an offset as well. Very annoying and just making everybody's lives more difficult than necessary...
  • don't know this helps but it could be your work plane.

    I have found inconsistencies with some features if I'm not in the correct work plane. specially lines



    Thanks for the suggestion, Donald, and you're right of course, the workplane is very important. In my case, I'm using the correct workplane though. It's orientation is such that if you think of the workplane of going through the probe sphere's center, its intersection with the probe sphere's surface is where the hits will take place----just as it's supposed to be. Slight smile
  • in reply to constadin
    Actually I was asking about the premise of changing a predefined feature's IKJ vectors with an assignment like so
  • in reply to constadin
    Sorry constadin, I was only replying to louisd's comment. Of course, you are right with your suggestion and if you look at my subroutine code above, that's in essence exactly what I'm doing. As louisd pointed out though, the IJK flip cannot be applied blindly all the time because it depends on the given situation, which in my case is unknown at the time of programming. The interesting part is that louisd and I seem to be experiencing different triggering factors though. So I tried to write my subroutine in a way that is actually oblivious to the situation at hand and just looks at the actual hit points. As long as those are stored in the correct order by PC-DMIS, it's rather easy to determine which way the directional vector should be pointing. Of course, my solution only takes the first two hit points into account since that's all I needed, but it should be easy enough to expand it to include all hit points.
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement