hexagon logo

"Failed to detect a focus position for feature <featurename>"

What can cause this?

Tried
- new probe files
- different Z-heights
- different lightning
- different backgrounds
- different surfaces

I can visually "see" that it does focus very well, during the autofocus phase - however, it does not seem to "lock" or "detect" this...
CMM-V (HP-C-VE) in 2016.0 SP1.

Ideas?

  • One of our engineers was able to see this issue and we are researching the cause. . . .
  • , you're with windows 64 ?
    With x86 version, I'm unable to start 2016 nor Sp1 with vision dlls...
  • I already have a ticket in for this from back in July and talked to Doug at Hexagon. I saw this in an earlier build in Technical Preview (there is a thread on it) and it has come back. SP2 did not solve this issue.

    In addition, because of this issue, calibration doesn't work either. Bryan S is also aware of the problem too. I talked with him during the tech preview when this issue arose.
  • Thank you all, I am very grateful that it isn't a local issue (just me). It saddens me though that the quality of the software is moving backwards - again.
    Why wasn't this detected during the testing of the software? I don't mean the technical preview - I mean the "rigorous testing" Hexagon is mentioning in the readme's that accompany each released version? If there really was a rigorous testing, issues like this should not pass by unnoticed. Let's sprinkle this with the fact that reported this very same error during the 2016 TP. At that point, this very error/issue should have been included in the internal testing routines! I think we have different dictionaries when it comes to the definition of "rigorous"...

    I think I speak for everyone using PC-DMIS when I say that I'd rather wait longer for a "more working" version than forcing two releases/year that are below standard.

    Shape up, ffs.
  • .............. I saw this in an earlier build in Technical Preview (there is a thread on it) and it has come back.


    Let's sprinkle this with the fact that reported this very same error during the 2016 TP. .



    It is true that it was reported in the technical preview. We were not able to repeat it at the time, and apparently neither was Bfire85 apparently, based on this post in the T/P forum


    Update: Build #866 works with calibration on my end. At the time of error, Hexagon tested calibration with build #854 and it worked.



    It was not a case of the issue getting fixed and then breaking again. It is just not one of those that is not easy to pinpoint. We do test for this sort of issue, but as already reported, it is not always evident. Regardless, we are focused (no pun intended) on this now. Once we understand the logic behind it, we will work to make sure it does not re-appear.


  • I agree completely . I understand that this a big piece of software, but to basically break a main component (like focusing and calibration) and NOT catch it in testing is ridiculous. For the price our employers pay for maintaining the machines and software, these things should not be missed.





  • It is true that it was reported in the technical preview. We were not able to repeat it at the time, and apparently neither was Bfire85 apparently, based on this post in the T/P forum



    I was unable to repeat it in a later build than what I had at the time it showed up. I would like to assume that all builds are archived so if when we saw this arise in Build #851, Hexagon can try replicating in that build. But they didn't try that build, they tried to problem solve the issue in a later build, which the problem didn't show up in that one. If all previous builds are scrapped once a new one is released, maybe the revision process needs to be reformated to archive previous builds.

  • Regardless, we are focused (no pun intended) on this now.


    Even with no intention of it, it made me LOL! Sunglasses