hexagon logo
Register Sign in
  • Replies 30 replies
  • Subscribers 19 subscribers
  • Views 586 views
  • Users 0 members are here
Options
Related

Validate my method is fine please (programmers differ in opinion)

Lord_Warfield
Good Morning Interweb,

So I have a simple alignment. Plane A, circle B, circle C. I Leveled to the plane A and origin Z to it. Translate XY to circle B. Rotate to a line made from B to C. Done.

A different programmer believes I must rotate before translating.... I totally disagree on this simple alignment. Using Legacy btw.

Without being degrading... please reply.
  • ONE: You should have one alignment that locks all 3 DOF. It was proven in the past that if you don't have that, Pcdmis could (randomly) change nominals on you.

    Myself, I've always done LEVEL, ROTATE, ORIGIN, ROTATE OFFSET (if needed) and ORIGIN OFFSET. In that order.
  • I dont think it matters either way. It will still be rotated correctly.
  • in reply to Matthew D. Hoedeman
    Interesting on the nominals... Ive never had this happen as long as all 6 DOF were locked... Ill keep and eye on it though. Anyway, will the alignment work as I have. I did it in order of precedence... A's DOF then B's DOF and finally C's DOF
  • It seems like a divisive matter. I have worked with a very knowledgeable person that insists that you must Level - Rotate - Translate in that exact order. They said they have had problems with feature nominals in the past when they translated before rotating. I have not observed any such issues myself. However, I have only worked with the software since 2006, so maybe those sorts of problems had been fixed before my time.

    Personally, I don't think the order matters. For years I would typically select my alignment features, click the Auto-align button, quickly check that everything looks right, then go with whatever order was auto generated. Then offset if necessary. A plane with two holes would mean that the rotation is done last. I always program with displayprecision set to 6 so I can check for any wonky positions/vectors out to the millionths place and have not seen anything funky happen that I could trace back to the order of operations in my alignment.

    Then, I worked for a boss that gave me a long lecture every time I did not Level- Rotate - then Translate (the afore mentioned "knowledgeable person"). Now I still use the Auto-align button, but I have the habit of cutting and pasting the rotation line of the alignment and placing it right after the level line. It only takes me a few seconds to do that and who knows, maybe it has prevented a problem from happening. Or maybe it has future proofed my programs against some new obscure bugs that won't get discovered because the testers assumed everyone does their rotating before translating.
  • ONE: You should have one alignment that locks all 3 DOF. It was proven in the past that if you don't have that, Pcdmis could (randomly) change nominals on you.

    Myself, I've always done LEVEL, ROTATE, ORIGIN, ROTATE OFFSET (if needed) and ORIGIN OFFSET. In that order.

    Way back, when I took the Hexagon CMM 101 course, they really drove the LEVEL, ROTATE, ORIGIN order into us. We never got into offsets, but I have used them since.

    I currently work with a guy that uses a manual CMM and GeoPack. He will measure a plane and level and z origin to it. Then measure a 2nd feature and rotate and origin that, and so on. I worked with a guy years ago that did the same in PC DMIS, probe a feature and align to it, probe the next feature and align to it, and so on. Seemed odd but it worked. The same guy would also probe nothing but points and construct all his features from those points. He did not trust the measured features tab.

    In your example, I don't think either order of alignment is wrong. The best thing to do is to ask the other guy to elaborate as to why one is better than the other and objectively examine both. Maybe this person knows something, maybe they are just parroting a method they were trained to do and not question. I always inquire about programming different than mine for the same thing. Sometimes I find a better way of doing something.
  • I often rely on:

    Measure plane
    - Align: Level and origin Z
    Measure circle 1
    - Align: Recall previous: Origin XY
    Measure circle 2
    Construct line between cir1 - cir2 centroids
    - Align: Recall startup, then Level, Rotate to constructed line, Origin

    Doing this makes sure the rotation vectors that you take for the circles are normal to your component's level plane.
    Also, if your initial origin is perhaps dead-nuts centered between the two circles, you have a chance of flipping vectors as the polarity of your rotation can shift from centroid super easily, and 180 your entire routine.
  • I often rely on:

    Measure plane
    - Align: Level and origin Z
    Measure circle 1
    - Align: Recall previous: Origin XY
    Measure circle 2
    Construct line between cir1 - cir2 centroids
    - Align: Recall startup, then Level, Rotate to constructed line, Origin

    Doing this makes sure the rotation vectors that you take for the circles are normal to your component's level plane.
    Also, if your initial origin is perhaps dead-nuts centered between the two circles, you have a chance of flipping vectors as the polarity of your rotation can shift from centroid super easily, and 180 your entire routine.

    This method I have had internal issues with. never anything i have documented or researched in any way but i believe (again just a mental simulation no proof) creating multiple alignments when creating your final alignment would incorporate deviation from the previously measured features. thus changing the location of the part with each alignment.

    vs measuring the entire alignment features from one single alignment whether it be a manual alignment or the CMM startup alignment.

    Just an opinion.

    i would also like to state that in this example of plane circle circle i dont think it would have too much of an impact. however on a plane line point alignment or anything with more chance for deviation during measurement would have a greater impact on the alignment.


  • This method I have had internal issues with. never anything i have documented or researched in any way but i believe (again just a mental simulation no proof) creating multiple alignments when creating your final alignment would incorporate deviation from the previously measured features. thus changing the location of the part with each alignment.

    vs measuring the entire alignment features from one single alignment whether it be a manual alignment or the CMM startup alignment.

    Just an opinion.

    i would also like to state that in this example of plane circle circle i dont think it would have too much of an impact. however on a plane line point alignment or anything with more chance for deviation during measurement would have a greater impact on the alignment.

    I guess you could say the same about the relationship of the startup alignment to the part vs the other method. but i cant convince myself that its a safe bet. not saying your wrong at all.... just my own programming "do not do" list
  • I personally always level/origin, rotate and origin my alignments, mainly for consistency if nothing else. I align each feature after measuring it and then recall at the end of the string as well. Not sure if that matters much as I've come across several programs not of my own design that have the alignments after the datums were measured. In the end I don't know if it really matters but I felt that it ensured everything was as accurate as possible for defining datums. Management just cares about good numbers on a report that they could show the customer...lol Rolling eyes
  • Ran a test... with the Plane, circle, circle I saw no difference. With a Plane. Mid Plane, Mid Plane... Error occurred that was corrected by rotating 1st... I assume its a cosine error of some sort but, it happened and I will change the method for this and future program to form a habit. It actually created .008 inches of error. Astonished

    This was a case of and old dog showing and old dog new tricks.
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement