True Position Calculations

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

  • True Position Calculations

    I have a part that has 5 bores of different sizes sharing the same axis (all around 6 inch diameters each getting smaller in diameter as they go deeper). 2 of the bores are called out as Datums (J & P). The top bore is J, P is the 4th bore down (approximately 8.25 inches deep). I'm scanning all the bores with auto cylinders using adaptive cylinder spiral scan. The top 2 bores I use a 3by50mm stylus. The rest I measure with a 8by75mm stylus with a 150mm extension (yes pushing the limit). Bore P has a size tolerance of +.002 -.000 & .001 mmc TP to J mmc. The deepest bore (approximately 8.5 inches deep) has a size tolerance of ± .001 and .001 TP mmc to P mmc. If I use the default Datum Math, each TP measures around .06. If I change the Datum Math to Least Squares, it improves to around .015 still out of tolerance. When I look at the measured X & Y values from the status window and put the deviations to a TP calculator, it says it measures .002. I checked the parallelism of the bores to one another and I get less than .001. So why am I getting such a discrepancy in my numbers? Does it have anything to do with my scanning parameters? Since my probe build is so long, I'm using a 2 points/mm density, 5mm/s scan speed, 5mm/s^2 acceleration, and .06N offset force. With the short probe I change to 10 mm/s and scan speed 10 mm/s^2 acceleration.
    I'm programming on a Global S 15.30.10 with a HP-S-X1H Scanning Probe, and using 2020 R2.

  • #2
    A few questions.

    1) You're scanning - what probe type is it? LSPX, SP25 etc?

    2) How long is Datum J bore?

    3) How are you reporting - Legacy or Xact?

    4) Are your probe properly calibrated in respect to each other? If they weren't you could end up with them showing parallel but not concentric.
    Automettech - Automated Metrology Technology

    Comment


    • #3
      It's an HP-S-X1H. Datum J bore is about .5 inch. I'm reporting with GeoTol in 2020 R2. How to you mean calibrated in respect to each other? I have them both calibrated I do not know if they're calibrated in respect to each other. That might be my problem. Comparing the concentricity of the bores I'm measuring with the same tip are much better than the concentricity between bores with different tips. How do I calibrate them in respect to each other?
      I'm programming on a Global S 15.30.10 with a HP-S-X1H Scanning Probe, and using 2020 R2.

      Comment


      • #4
        Okay - a 0.5 inch bore isn't a very long datum axis to project over 8"plus! You might struggle to hold that tolerance even if the bores were truly perfectly concentric.

        You need to use one probe as your 'master' probe. When you calibrate you say Yes the sphere has moved. When you calibrate the second probe, you say 'no the sphere has not moved'.

        In effect you when you say Yes the sphere has moved you are teaching the ref sphere location on the CMM with that probe. When you say 'no - sphere has not moved' you are calibrating that probe in relation to the one which defined the sphere position.

        Watch this (sorry about both the accent and the sound quality), but it should explain how different probes & different angles relate to each other.

        https://www.automettech.com/master-probe-calibration
        Automettech - Automated Metrology Technology

        Comment


        • Mike Ruff
          Mike Ruff commented
          Editing a comment
          Dang, beat me to it!

      • #5
        Projecting a short datum over a long distance (long relative to the length of the datum) is always going to make it harder to get repeatable results. Have you tried running it several times and compared results?

        To answer your calibration question, calibrate the first tip and click "Yes" when it asks if the qual sphere has moved. Do NOT move the qual sphere and calibrate the second tip, except this time answer "No" when it asks if the qual sphere has moved. This will ensure that they are calibrated relative to each other.

        Comment


        • #6
          I agree, these tolerances are ludicrous. I didn't even mention the .002 TP on Datum J back to ABC which is a plane, dowel, dowel on the bottom of the part 11+ inches away. And the kicker... drum roll please.... it's made of aluminum!!!! Anyway, thank you so much for your help. I've never set a master probe other than in training. I don't believe they explained the "why" to set a master or I just wasn't listening haha.
          I'm programming on a Global S 15.30.10 with a HP-S-X1H Scanning Probe, and using 2020 R2.

          Comment


          • #7
            Sounds somewhat similar to the "long probe problem" I had...

            https://www.pcdmisforum.com/forum/pc...res-off-center
            PC-DMIS CAD++ 2o19 R1 SP11

            Comment


            • NinjaBadger
              NinjaBadger commented
              Editing a comment
              Good point!

            • Fradders
              Fradders commented
              Editing a comment
              Ditto that and with the same probe set up as us and as of yet still unresolved, though we have had to park the problem due to workload

          • #8
            I designated a master tip and recalibrated. My numbers are better but still far from in tolerance. To me it seems the print just wants the center each cylinder to be within .001 of each other. Using a TP calculator with just the measured centers, the TP is .003 which is much closer to tolerance. The cylinders are just so short. I built a circle from P back to the top plane datum H and I can see why the TP checks way out with default.
            Attached Files
            I'm programming on a Global S 15.30.10 with a HP-S-X1H Scanning Probe, and using 2020 R2.

            Comment


            • Matthew D. Hoedeman
              Matthew D. Hoedeman commented
              Editing a comment
              yeah, if you have the travel on the machine, use that long sucker for all of them, eliminate as many possible errors as you can.

          • #9
            If you're questioning the results from the probe, a nice trick is to measure the top bore (which you measured with the short probe) with the long probe.

            Check the concentricity - if the probes relate properly to each other the results will be very good. If there are issues with the probe cals you will see a big difference.

            Automettech - Automated Metrology Technology

            Comment


            • #10
              I checked the concentricity measuring datum J with each tip and it measured .0005. That's pretty good but I thought it would be smaller considering the contact path was the exact same. I'm now using the big SOB to measure all the bores and the fixture. The numbers were better but still out of tolerance. I re-ran all parts (6). Today's results got better than yesterday's but were fairly close. I just made a program using default measurement strategies instead of scanning and I changed all the short bores (except for datum J) to circles. Now everything is checking good!
              I'm programming on a Global S 15.30.10 with a HP-S-X1H Scanning Probe, and using 2020 R2.

              Comment


              • vpt.se
                vpt.se commented
                Editing a comment
                This was not the case for me, both adaptive scanning and default strategy showed the same errors. You sure you have calibrated the scan radius deviation?

              • S_Cliff
                S_Cliff commented
                Editing a comment
                I'm not sure if I did calibrate the scan radius deviation (I did it this morning). That might have been my problem too.

            • #11
              Originally posted by S_Cliff View Post
              I checked the concentricity measuring datum J with each tip and it measured .0005. That's pretty good but I thought it would be smaller considering the contact path was the exact same. I'm now using the big SOB to measure all the bores and the fixture. The numbers were better but still out of tolerance. I re-ran all parts (6). Today's results got better than yesterday's but were fairly close. I just made a program using default measurement strategies instead of scanning and I changed all the short bores (except for datum J) to circles. Now everything is checking good!
              Long ago when I started in this game I was told that a scanning probe is most accurate when used as a touch probe. I've found this to be the case, they can be infuriatingly slow but when you're faced with tricky measurement it's often the way to go.

              It's the diameter to length ratio of the datum feature that's the issue here (combined with the projection distance for the other bores) so it's worth doing everything possible to get the absolute best measurement you can of the datum feature.

              Glad you got it sorted.

              Automettech - Automated Metrology Technology

              Comment


              • #12
                out of curiosity what was your scan offset force set to? That needs to be adjusted for different probes.
                sigpicTAU ALPHA PI INDIANA DELTA CHAPTER
                "Due to the highly confidential nature of my job, I am not allowed to know what I am doing" - author unknown

                Comment


                • S_Cliff
                  S_Cliff commented
                  Editing a comment
                  I kept it per the probe & controller recommended .06N

              • #13
                The ghost in the machine is back for me again...
                PC-DMIS CAD++ 2o19 R1 SP11

                Comment


                • S_Cliff
                  S_Cliff commented
                  Editing a comment
                  I hope you/they get your machine exercised soon!

                • vpt.se
                  vpt.se commented
                  Editing a comment
                  Did a low level matrix calibration, preliminary results looks promising, calibrating all tips now...

                • S_Cliff
                  S_Cliff commented
                  Editing a comment
                  Great! Fingers crossed!

              Related Topics

              Collapse

              Working...
              X