Diagnosing repeatability issue

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

  • Diagnosing repeatability issue

    I'm trying to diagnose an issue. I'm running a program on repeat and currently checking one feature for perpendicularity and i'm now getting weird deviations without moving anything. around .015-.020 thou deviation between runs. This program before running on repeat could achieve .0001 or less in deviation between runs.

    Currently using a HP-S-X1H with a 1.5mm X 40mm styli
    The angles being used are:
    A0B0
    A90B90
    A90B-90
    A90B180


    What i've done so far i went through thoroughly cleaned everything i checked the probe for cracks along with checking the Qual sphere.

    I calibrated everything. The calibration checked good.

    i switch to another styli and achieved the same deviation errors.

    What are some checks i can do to determine if the scanning probe is having issues or if its the machine itself?







  • #2
    Decided to perform a lower matrix CAL. According to some research greater than .015 between the upper left and middle number is unacceptable i got a diff of .01797. What do you do in this situation?

    Edit making sure you read the correct decimal place makes a huge difference it's ".15" so i'm good for the lower CAL.

    I'm going to Re calibrate the probes again this time Resetting theos to see if my issue is resolved
    Attached Files
    Last edited by Jakep379; 03-26-2020, 06:56 AM.

    Comment


    • #3
      Other things to check...
      1. Is the part moving - do you have it fixtured / clamped down sufficiently or is it perhaps moving during measurement. This can also apply if you're using hot glue / blue-tac / double sided tape - the part can "creep" (move slightly) as the glue cools / clamping medium relaxes.
      2. Is the part orientated correctly to avoid the probe shanking out.
      3. In terms of the probe / machine - do you have a "known artefact" (ring gauge, gauge block, gold standard part etc) that you can run a similar repeatability study on?

      Comment


      • neil.challinor
        neil.challinor commented
        Editing a comment
        Looks like the LSPX1 is suspect then. To prove it - if you put that LSPX1 on a different machine, do you get the same repeatability issues?

      • Jakep379
        Jakep379 commented
        Editing a comment
        I'll find out tomorrow for sure. I'm going to swap the LSPX1 and report back here the findings. Thank you for assisting

      • BKulpa
        BKulpa commented
        Editing a comment
        Did you clean you ways and scales?

    • #4
      So after Swapping the LSPX1 out with another the same issue occurred. We had Fastprobe mode on after turning this off the variances in the hits stopped. What could cause FastProbe Mode to deviate so much? Some of these hits are deviating upwards of .070 thou.

      I've attached the Data I've Gathered and shows how much the hit deviations are.
      Attached Files

      Comment


      • #5
        Originally posted by Jakep379 View Post
        What could cause FastProbe Mode to deviate so much?
        FastProbe will always be less accurate since it basically turns the LSPX1 into a touch trigger probe. During the usual LSPX1 probing cycle, the probe would make contact with the part and continue driving in until the MaxForce setting is reached. It would then start to back off, during which time it senses which direction the probe is deflected and ensures it is backing away in the opposite direction. From the moment the MaxForce is reached until the moment the probe leaves the surface (zero force detected) it is streaming points to the controller which, once it has received all of the points, uses an algorithm to determine the optimum point. With FastProbe on, it is simply a switch and takes a point as soon as the probe is deflected and compensates along the Theo vector. You can see this yourself if you deliberately take bad hits that are not normal to the surface - for example by adjusting the target values to measure a circle way off centre. With FastProbe on it will compensate along the theo vector of each hit and give bad results, with FastProbe off, you should be able to see the probe adjust its vector to back away normal to the surface and the results should be better.

        Because of these differences the main causes of variance when using FastPorbe would be touchspeed and probing vector. The touchspeed for any of the LSPX range of probes should always be 2mm/sec and, as with all probes, you should ensure you calibrate with the same touchspeed setting as is used in your programs. Probing vector should always be normal to the surface, as is the case with all types of probe. Another thing that would work in conjunction with the touchspeed to affect results would be the prehit distance. Because the usual probing cycle takes the point on the way out, you can run with quite small prehit values - 0.5mm is not uncommon. In FastProbe mode, the point is taken on the way in so this prehit would be way too small and should be increased. I would set the touchspeed to 2mm/sec and then increase the prehit in 0.5mm increments until I saw the results stabilise - depending on the age and type of CMM this could be anywhere between 1.5mm & 8mm.

        Comment


        • #6
          Originally posted by neil.challinor View Post

          FastProbe will always be less accurate since it basically turns the LSPX1 into a touch trigger probe. During the usual LSPX1 probing cycle, the probe would make contact with the part and continue driving in until the MaxForce setting is reached. It would then start to back off, during which time it senses which direction the probe is deflected and ensures it is backing away in the opposite direction. From the moment the MaxForce is reached until the moment the probe leaves the surface (zero force detected) it is streaming points to the controller which, once it has received all of the points, uses an algorithm to determine the optimum point. With FastProbe on, it is simply a switch and takes a point as soon as the probe is deflected and compensates along the Theo vector. You can see this yourself if you deliberately take bad hits that are not normal to the surface - for example by adjusting the target values to measure a circle way off centre. With FastProbe on it will compensate along the theo vector of each hit and give bad results, with FastProbe off, you should be able to see the probe adjust its vector to back away normal to the surface and the results should be better.

          Because of these differences the main causes of variance when using FastPorbe would be touchspeed and probing vector. The touchspeed for any of the LSPX range of probes should always be 2mm/sec and, as with all probes, you should ensure you calibrate with the same touchspeed setting as is used in your programs. Probing vector should always be normal to the surface, as is the case with all types of probe. Another thing that would work in conjunction with the touchspeed to affect results would be the prehit distance. Because the usual probing cycle takes the point on the way out, you can run with quite small prehit values - 0.5mm is not uncommon. In FastProbe mode, the point is taken on the way in so this prehit would be way too small and should be increased. I would set the touchspeed to 2mm/sec and then increase the prehit in 0.5mm increments until I saw the results stabilise - depending on the age and type of CMM this could be anywhere between 1.5mm & 8mm.
          This is an older Sheffield Discovery III that has been retrofitted with a new controller to accommodate the LSPX1. This has been done since NOV 19. Right now it's current settings are 2mm/sec Touchspeed & Prehit is at .05in/1.27mm. It has been very repeatable up until this point which is why i'm asking the question what happened? I'm not sure i'll ever find that answer, but i'm going to do more tests today adjusting the prehit distance out and see if this makes a difference. Right now the Variance is so bad with Fastprobe ON that it will sometimes lose itself and error out, but it's been working since NOV 19.

          Thanks neil.challinor for the information!

          Comment

          Related Topics

          Collapse

          Working...
          X