hexagon logo
Register Sign in
  • Replies 20 replies
  • Subscribers 222 subscribers
  • Views 203 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/
​
  • My understanding is that the software is behaving exactly as expected.
    If you are taking hits for a line that is rotated past 90 degrees using the same physical positions on the part then the direction of that line is now in the opposite direction to the machine coordinator system.
  • Thanks for your quick reply, UKCMM! My understanding has been the following----and please correct my if any of this is wrong:

    If you measure an unbounded two-probe-point line (with the correct workplane for the scenario), you should end up with a line whose actual anchor point is the first probe point and whose actual directional vector is a unit-length vector pointing from the first to the second actual probe point. This should always be the case----even if the workpiece is rotated by more than 90° around the vertical axis with respect to its theoretical values. In fact, this is exactly what has been happening for me all along in cases described by my first numbered list up above.

    But in the case described by my second numbered list, it's different. If the workpiece is rotated by less than 90° around its vertical axis, everything is fine. If however the rotation is more than 90°, the resulting measured unbounded line's directional vector is pointing from the second actual probe point to the first!

    So my two main questions are:
    1. Why is there a difference in the behaviors described by my two numbered lists? (I should mention that I'm also using the first case inside a subroutine, so I don't think the use inside of a subroutine has anything to do with the problem.)
    2. Why are the point and the line features used for the alignment displayed in red in the alignments edit dialog even though they are clearly being measured?
    In case it's relevant: We're using PC-DMIS 2020 R2 SP1.
  • Yes, but please keep in mind that I'm writing a generic subroutine which needs to work reliably in many different scenarios----in this case many different locations and orientations of the workpiece which are unknown at the time of writing the subroutine. So it's not your common well-controlled inspection of a workpiece. We're dealing with very delicate optics so that a CMM crash would be catastrophic (very expensive and many months of work down the drain with the schedule of a satellite mission on the line). So, at the very least I need to understand the problem well enough to know why and under which circumstances it's happening. Hence my two questions up above...
  • When you are recalling the external alignment, is the origin ever in between the hits of the new line?

    HIT1 ----------------------------------------recalled ORIGIN------------------------------------------Hit2

    if so, that's a very common error. if your workpiece is rotated positively to existing rotation, it will produce correct vector, if your workpiece is rotated negatively to the existing rotation, it will flip your line vector 180 on you.

    Resolve? There's a few:
    -Don't orgin in the middle of the line.
    -Don't take linear hits on both sides of an origin.
    -Construct a plane instead of a line.
    -Physically restrict positioning of sample parts, so the existing origin doesn't encroach inboard of the line hits.
    -Physically sample your initial origin so it's never in the middle of the secondary alignment component.
  • in reply to Daniel P
    so you're attempting to write programs using subroutines with the assumption that they are perfect programs without checking the pathlines and collision detection?
    are you guaranteeing that the CAD models are perfect?
  • so you're attempting to write programs using subroutines with the assumption that they are perfect programs without checking the pathlines and collision detection?
    are you guaranteeing that the CAD models are perfect?​

    We're building quasi-monolithic laser interferometers. They usually consist of a glass-ceramic baseplate oriented horizontally to which we need to bond a number of fused silica components with an accuracy of a few microns. The components are of just a few standardized shapes, their positions and orientations will only ever vary within the horizontal plane, and we're using standardized equipment to aid in this task. Furthermore, we have support equipment to measure the position and orientation of laser beams which also needs to be probed by our CMM to get the result into a common reference frame. So I'm writing subroutines for each of these individual subtasks, which can then be called by our main construction program. The main construction program offers a menu to let the operator decide what they would like to do next (input target parameters for components or laser beams, probe components or measurement equipment, and so forth). Everything is designed in a way that there is no danger of collisions while any of these subroutines themselves is running. The critical part is only what happens between those subroutine calls. This can in theory be solved by making sure that the subroutines always start and end with a forced probe position which leaves a clear vertical path upwards to a common clearplane. Having said this, there is another problem I ran into with respect to clearplanes to which no-one has commented yet. Wink
  • When you are recalling the external alignment, is the origin ever in between the hits of the new line?

    HIT1 ----------------------------------------recalled ORIGIN------------------------------------------Hit2

    if so, that's a very common error. if your workpiece is rotated positively to existing rotation, it will produce correct vector, if your workpiece is rotated negatively to the existing rotation, it will flip your line vector 180 on you.

    First of all, thanks so much for your detailed reply!!

    You might be correct with your assumption about the location of the origin----still need to double-check though. OK, so let me get this straight:
    1. By "origin in between the two hits" you mean that the origin lies between two planes with normal vectors collinear to the line's directional vector and each of the planes going through one of the two hits, right?
    2. What do you mean by "positive and negative rotation"? Do you mean a right-handed rotation around the workplane's normal vector of less than 180° will produce the correct directional vector for the measured line whereas a left-handed one----however small it may be----will result in a directional vector flipped by 180°? (That would be a very unstable situation even for common inspection-type CMM tasks, which is why I would have assumed the problem only ever arises if the rotation is more than +90° or less than -90°.)
    3. In your first sentence, you explicitly mention my recalling an external alignment. Do you mean to say there would be no problem if I had recalled an internal one or none at all (which of course isn't feasible in my subroutine)? If the answer to either one of these options is yes, then what is so special about recalling alignments?
    Why this flipping business of the directional vector could ever be considered a desired behavior is beyond me----just like the problem with planes I briefly described in my first post. Speaking of which, could this normal vector flipping in planes also be influenced by where the origin lies?

    For me, it would be very tempting to just test in my subroutine if the origin lies in between the two hits and, if so, to flip the line's directional vector. But the question then arises what will happen if the origin lies on one of the two planes going through the hits. I'm also curious to know what would happen if I create a new line out of the two hits of the first. You definitely gave me enough food for thought, but I'm a bit afraid of missing more problems like these. So I'm not just trying to get around the problems but to really understand their root causes and any additional explanations would be much appreciated. Thanks!!
  • in reply to Daniel P
    oh well why didn't you just say that in the first place.
  • in reply to Daniel P
    Sorry, I was trying not to blow my first post up more than necessary in order to reduce the amount of text people need to dig through. Thanks for your reply over in my other thread!
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement