hexagon logo

program getting errors

We have been checking parts with a short program. We have checked about 8 parts and then we started getting "out of limit 10" errors when taking a point on a circle.
So we tried to figure out what happened. I started taking point in an opposite pattern and the machine took the points but the results were way off. Why is this machined acting this way when we did not change anything in our work and point taking sequence and pattern before we started getting errors?
We do not know why all of a sudden the machine changed the point pattern. Now we can not continue because the results are way off.
Has anyone seen this behavior on their ARM before?
If so, how do we recover from this without creating a whole new program?
  • I noticed a lot of viewers but no comments.
    I was thinking my message is not clear or no one has had errors of this sort before????
    I am thinking this issue might need addressing with the PCDMIS or Hexagon support group.
    Any comment is welcomed.

    Thank you in advance for comments.
  • I noticed a lot of viewers but no comments.
    I was thinking my message is not clear or no one has had errors of this sort before????
    I am thinking this issue might need addressing with the PCDMIS or Hexagon support group.
    Any comment is welcomed.

    Thank you in advance for comments.


    Need more info. Can't picture what you are working on.
  • Turns out that when running a program that gets stuck and you chose to do the short cut control U, this will create errors in your program.
    I was told the control U goes into a buffer and when the buffer is filled the machined gets lost.
    The way to recover is shut down everything for some time then restart.
    That seemed to work for us. THe advice was from tech support.
  • We have been checking parts with a short program. We have checked about 8 parts and then we started getting "out of limit 10" errors when taking a point on a circle.
    So we tried to figure out what happened. I started taking point in an opposite pattern and the machine took the points but the results were way off. Why is this machined acting this way when we did not change anything in our work and point taking sequence and pattern before we started getting errors?
    We do not know why all of a sudden the machine changed the point pattern. Now we can not continue because the results are way off.
    Has anyone seen this behavior on their ARM before?
    If so, how do we recover from this without creating a whole new program?


    You haven't turned off your Any Order Execution.

    Hit F5.

    Go to the bottom of the dialog box. Change "any order execute tolerance" to 0.

    Problem goes away.
  • Clementine, as an aside:

    You need more training. 6 of the top 8 threads in this forum are yours, and they are very, very basic issues that get sorted out in the first or second day of training.

    One can't be trained over the phone, or over the internet. Please consider how many issues that you are falsely reporting on, or falsely passing on, and how that might impact your customers or the users of the products you're inspecting. Contact our training department and get set up so you can get the most out of your portable CMM -- it's a great product, and you shouldn't have to wait on people's responses in this forum to get the most out of it.
  • I checked out your suggestion and found that my machined was already programed as you indicate and still got those error.
    Thank you for your input. Always good to check out all options that I did not think of.