Program won't repeat without DCC alingment

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Program won't repeat without DCC alingment

    I have a fixture with datum pads that we use for the manual and DCC alignment. The fixture is heavy and secured. Unless we do a DCC alignment before each part it won't repeat within .0025. If we do the alignment it repeats within .0002. Has anybody else ran into this issue?

  • #2
    Originally posted by Roadkill View Post
    I have a fixture with datum pads that we use for the manual and DCC alignment. The fixture is heavy and secured. Unless we do a DCC alignment before each part it won't repeat within .0025. If we do the alignment it repeats within .0002. Has anybody else ran into this issue?
    Assuming you have rock-solid alignments, it looks like you're got a hard number on how well those pads locate the part.

    Unless you're measuring a part whose tolerances zones can be seen with the naked eye and measured with a tape measure, it's best practice to ALWAYS do a DCC alignment.

    Comment


    • #3
      What exactly are you aligning? The fixture or the part?
      Are you using an external alignment or is it part of the check program?
      Is it an iterative alignment? If so, executed or not, IT RE-CALCULATES every time (I hate this, and unless they have changed it in newer version, YES IT DOES SO re-calculate the iterative aligment).
      sigpic
      Originally posted by AndersI
      I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

      Comment


      • #4
        FWIW, CMM's tend to hit harder when you take manual hits, and some machines won't give you a decent manual alignment. ANY experienced CMM programmer ALWAYS does a DCC alignment, even if it's exactly the same as a previous manual alignment.
        I'm upping my standards........

        Up yours!

        Comment


        • #5
          Originally posted by Matthew D. Hoedeman View Post
          What exactly are you aligning? The fixture or the part?
          Are you using an external alignment or is it part of the check program?
          Is it an iterative alignment? If so, executed or not, IT RE-CALCULATES every time (I hate this, and unless they have changed it in newer version, YES IT DOES SO re-calculate the iterative aligment).
          Please expand on this. If you don't re-run the DCC features, the alignment associated with it shouldn't change. Am I misunderstanding what you are saying here?

          Originally posted by Alex B-shift View Post
          FWIW, CMM's tend to hit harder when you take manual hits, and some machines won't give you a decent manual alignment. ANY experienced CMM programmer ALWAYS does a DCC alignment, even if it's exactly the same as a previous manual alignment.
          This is true, but isn't what is being asked. When working with fixtures, once you've run the DCC alignment, you should be able to mark the features from the manual and DCC, and start off after the alignment. I do this on a semi-regular basis.

          I think there is something else going on here. I think the numbers are showing the gage is not repeatable.
          "This is my word... and as such is beyond contestation."

          Comment


          • #6
            Originally posted by VinniUSMC View Post
            Please expand on this. If you don't re-run the DCC features, the alignment associated with it shouldn't change. Am I misunderstanding what you are saying here?



            This is true, but isn't what is being asked. When working with fixtures, once you've run the DCC alignment, you should be able to mark the features from the manual and DCC, and start off after the alignment. I do this on a semi-regular basis.

            I think there is something else going on here. I think the numbers are showing the gage is not repeatable.
            I do NOT know if this has changed or not, still using 3.7 here.....

            For a manual iterative alignment, I will generate the features without measuring them, but for a DCC iterative alignment following any manual alignment (3-2-1 or iterative), I will execute them when I generate them.

            Most of the time, the fixture base values are close enough to 'correct' that the iterative alignment features are within the tolerances I use (0.5 target, 0.05 fixture) and there is no issues seen. SOME TIMES, the base numbers are NOT close enough and it will give an "ERROR" for the alignment. Note: I always use MEASURE ALL ALWAYS for DCC iterative alignments. So, it pops up the error and asks if I want to measure all alignment features now. I tell it no, as I want to SAVE the program before it starts running on it own, if-ya-know-what-I-mean! So, since it is "measure all always" it wants at least TWO 'run throughs' of the features. It will give an error, show the amount of the error of all the features that are not within those tolerances. I click OK, then it re-calculates, pops up a second error WITH ALL NEW VALUES for the error and asks again if I want to measure them all now. Again, I tell it no, so I can save the program before it does it's thing. If I then save and CLOSE the program and re-open it, a third set (and 4th) set of error values will pop up when I open the program. All the sets of numbers are different. I can keep closing and opening the program and get NEW ERROR VALUES each and every time I open the program, over and over and over.

            So, Pcdmis re-calculates the iterative alignment each and every time, even when it has NOT BEEN RUN. Again, unless they have changed it. Notice that you can NOT un-mark an alignment, features yes, the alignment, no. And anything that is marked is "executed" in the program......

            This is why IF the iterative alignment is part of the program that measures the part, it gets run every time. Otherwise, it is in it's own program with the alignment saved to an external file that is recalled in the check program. Rarely do I have to include an alignment in a check program since 99% of my parts have dedicated certified fixtures that hold the parts.
            sigpic
            Originally posted by AndersI
            I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

            Comment


            • #7
              I think if some code was posted we'd better understand what is going on here. If you are looping a program, where does the loop start? This could be a factor in what is happening here. Something doesn't make sense....Are you recalling ??? alignment at the end of the loop? Really need to see some code...
              Jesse Krook

              Comment


              • #8
                Originally posted by Matthew D. Hoedeman View Post
                I do NOT know if this has changed or not, still using 3.7 here.....

                For a manual iterative alignment, I will generate the features without measuring them, but for a DCC iterative alignment following any manual alignment (3-2-1 or iterative), I will execute them when I generate them.

                Most of the time, the fixture base values are close enough to 'correct' that the iterative alignment features are within the tolerances I use (0.5 target, 0.05 fixture) and there is no issues seen. SOME TIMES, the base numbers are NOT close enough and it will give an "ERROR" for the alignment. Note: I always use MEASURE ALL ALWAYS for DCC iterative alignments. So, it pops up the error and asks if I want to measure all alignment features now. I tell it no, as I want to SAVE the program before it starts running on it own, if-ya-know-what-I-mean! So, since it is "measure all always" it wants at least TWO 'run throughs' of the features. It will give an error, show the amount of the error of all the features that are not within those tolerances. I click OK, then it re-calculates, pops up a second error WITH ALL NEW VALUES for the error and asks again if I want to measure them all now. Again, I tell it no, so I can save the program before it does it's thing. If I then save and CLOSE the program and re-open it, a third set (and 4th) set of error values will pop up when I open the program. All the sets of numbers are different. I can keep closing and opening the program and get NEW ERROR VALUES each and every time I open the program, over and over and over.

                ...
                I see what you're saying. Why don't you let the program run at least 1 DCC iterative after the initial error?

                I program the manual and DCC alignment "offline" before I do any probing. If you are running from tooling balls, you could be significantly off target (2 decimal rounded tooling ball locations suck) before the program even starts. If you don't let the program run through at least one full DCC iterative, you don't know if you're seeing error in the location of the manual items, or something else.
                "This is my word... and as such is beyond contestation."

                Comment


                • #9
                  Because I don't trust Pcdmis (do you?), programs get saved after each "milestone" before letting it run, KWIM?

                  I don't know if it only does that re-calc thing if the alignment is out of tol or not, but, the thing is, I DO NOT KNOW, so, does it re-calc ALWAYS or only when OOT conditions exist? The point is, I do KNOW that it WILL re-calc (sometimes at the very least) even when you do not run that part of the program.

                  Oh, and it will also do some "funny stuff" sometimes if you let it do the extra iterative run-throughs after you make the alignment instead of actually executing the program.
                  Last edited by Matthew D. Hoedeman; 03-30-2015, 09:20 AM.
                  sigpic
                  Originally posted by AndersI
                  I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

                  Comment


                  • #10
                    We have repeatable fixturing for every part we run. Every program has a manual alignment and a dcc alignment. We run through a manual alignment and then let the entire program run. After that, we turn off the manual alignment and with the repeatable fixturing, we get good results every time within a couple .0001's.

                    Comment


                    • #11
                      Originally posted by VinniUSMC View Post
                      I see what you're saying. Why don't you let the program run at least 1 DCC iterative after the initial error?

                      I program the manual and DCC alignment "offline" before I do any probing. If you are running from tooling balls, you could be significantly off target (2 decimal rounded tooling ball locations suck) before the program even starts. If you don't let the program run through at least one full DCC iterative, you don't know if you're seeing error in the location of the manual items, or something else.
                      Just ran into another situation where this same thing pops up.

                      I have a fixture, for a "non-normal" part. To measure the 2-way non-removable pin, I have to use edge points, can't use a circle. The fixture was screwed up in the design & build, so it had to go back and get fixed (hole is NOT normal to surface, it is normal to 'body lines'). It came back. The height of the pin has changed DRASTICALLY, so I have to change the "Z" height at which these points are taken. I change the value (in the edit window), it asks if I want to update the targets (YES!), then it asks if I want to update measured values (yes), then it asks if I want to measure all ITERATIVE features now. NO, I do NOT as there are 3 more that I have to change. So I tell it NO. I get this message:
                      Feat ID=LHA1_2 Datum=Y Error=0.078
                      Feat ID=LHA1_4 Datum=Y Error=-0.064
                      Feat ID=LHA2_2 Datum=Y Error=0.08
                      Feat ID=LHA2_4 Datum=Y Error=-0.089
                      Feat ID=LHA3_1 Datum=Y Error=-0.052
                      Feat ID=LHA3_2 Datum=Y Error=0.102
                      Feat ID=LHA3_3 Datum=Y Error=0.054

                      Click OK or Cancel, no difference in effect

                      then the infamous "UPDATE COMMAND WITH NEW PART ALIGNMENT" NO!!!!!!!!!!

                      As soon as that window closes, the "measure all ITERATIVE features now" window pops back open. I again tell it NO! (I still have 3 more features to change)

                      Then I get a NEW datum error window

                      But this time, ONLY 2 datums are listed, and the values are NOT THE SAME as they were before.

                      I now change the second one, and I get a list, shows the same datums as the first list, but again, with different values (and NONE of the 'error' datums are the ones I am changing!). and it again goes through the 'double' calculations, double set of errors, and the ones (in this case) showing up are NOT the ones being changed, but each time, double calculations, and different error values each time. and the changes being made are NOT in the 'iterative' direction of the feature and the re-calcs are being done in a direction perp to these features.
                      sigpic
                      Originally posted by AndersI
                      I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

                      Comment


                      • #12
                        Originally posted by Matthew D. Hoedeman View Post
                        Just ran into another situation where this same thing pops up.

                        I have a fixture, for a "non-normal" part. To measure the 2-way non-removable pin, I have to use edge points, can't use a circle. The fixture was screwed up in the design & build, so it had to go back and get fixed (hole is NOT normal to surface, it is normal to 'body lines'). It came back. The height of the pin has changed DRASTICALLY, so I have to change the "Z" height at which these points are taken. I change the value (in the edit window), it asks if I want to update the targets (YES!), then it asks if I want to update measured values (yes), then it asks if I want to measure all ITERATIVE features now. NO, I do NOT as there are 3 more that I have to change. So I tell it NO. I get this message:
                        Feat ID=LHA1_2 Datum=Y Error=0.078
                        Feat ID=LHA1_4 Datum=Y Error=-0.064
                        Feat ID=LHA2_2 Datum=Y Error=0.08
                        Feat ID=LHA2_4 Datum=Y Error=-0.089
                        Feat ID=LHA3_1 Datum=Y Error=-0.052
                        Feat ID=LHA3_2 Datum=Y Error=0.102
                        Feat ID=LHA3_3 Datum=Y Error=0.054

                        Click OK or Cancel, no difference in effect

                        then the infamous "UPDATE COMMAND WITH NEW PART ALIGNMENT" NO!!!!!!!!!!

                        As soon as that window closes, the "measure all ITERATIVE features now" window pops back open. I again tell it NO! (I still have 3 more features to change)

                        Then I get a NEW datum error window

                        But this time, ONLY 2 datums are listed, and the values are NOT THE SAME as they were before.

                        I now change the second one, and I get a list, shows the same datums as the first list, but again, with different values (and NONE of the 'error' datums are the ones I am changing!). and it again goes through the 'double' calculations, double set of errors, and the ones (in this case) showing up are NOT the ones being changed, but each time, double calculations, and different error values each time. and the changes being made are NOT in the 'iterative' direction of the feature and the re-calcs are being done in a direction perp to these features.
                        I understand this situation, and I say 'NO' to "Do you want to measure the iterative features now" question all the time. This is different than when creating a new program however, which is how I had interpreted your initial posting. My question was about your assertion that the alignment recalculated every time. Which I took to mean every time, and is seemingly untrue.

                        If you run the manual and DCC alignment and then mark the manual and DCC features and run the program (Ctrl+Q), your manual and DCC point locations will not change. Thus, no recalculation.

                        If you change a feature that is used in an alignment, it will certainly change the alignment. That makes perfect sense. I don't know how that relates to the OP's question though. Or to the scenario I presented.
                        "This is my word... and as such is beyond contestation."

                        Comment


                        • #13
                          My initial posting was about a new program, thus "another situation when this occurs" statement.

                          I was not talking about when changing features before, I was talking about a new program. The only time I can SEE that it IS re-calculating is when the features are not in the specified tolerance, since if they are in the tolerance, no warning window. And, closing and re-opening a program, (new program, new alignment) will give new calculations (new error values), but you can only see this of it is OOT. Does it also do this when it is IN tolerance? I don't know, there is no 'warning window' when it is in tolernace. However, that does prove that SOME TIMES (at the very least) it DOES re-calculate the iterative alignment when you don't measure it.

                          As for how it relates to the OP, he says if he doesn't run the alignment, he sees 'a shift' but not if he runs it. If it IS recalculating the iterative alignment, even when not run, it could very well be causing the shift that he sees.
                          sigpic
                          Originally posted by AndersI
                          I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

                          Comment

                          Related Topics

                          Collapse

                          Working...
                          X