Freesteel Blog » Feature detection compromised

Feature detection compromised

Sunday, January 22nd, 2006 at 10:33 pm Written by:

Thanks for the comments on the last post… Barry: if there is a setting that crops length of comments on this blog, I can’t find it. I may need more background from you.

Further to my posting: One factor that makes someone like me reluctant to make a hole detector into a CAM system, apart from laziness/other-things-to-do and the hope that this problem will sort itself out of its own accord, is the long term situation that when you do build a function of this nature you effectively create a barrier against the proper solution.

Recall that the proper solution would be for the CAD system to explicitly tell the CAM system where higher level features such as drill holes are, rather than leaving them implicit-only in the way that the surfaces and triangles are laid out in whatever petrified data exchange format is being accepted. Recall also that this solution hasn’t happened because cooperation of any kind between the designers of the CAD systems and the CAM systems that someone might buy is practically and inexplicably non-existent.

Let’s suppose the proper solution can solve the problem with 100% reliability. Unfortunately, the CAM system programmer caves in to the management, the sales-team, and the will of the market as it latches on to the quick-and-dirty incorrect solution, and he writes a hole detector that works with 95% reliability. That is to say, there would be an error rate of 5% of holes it would be missing or mislabelling on average. People get numb to the idea that they shouldn’t have to double-check the output of a computer, and they will have to. Perhaps they learn to take account of weaknesses in the algorithm and avoid designing holes across the boundary between two free-form surfaces, for example.

Okay, now someone wants to solve the problem properly. Unfortunately he finds it difficult to justify because he’s only going to make an improvement of 5%, from 95% to 100%, not from 0% to 100%. The gain is less. Even if you observe that 100% reliability means you don’t have to double-check the results anymore, no one’s going to believe you. The sub-optimal solution is going to be locked in forevermore.

There is a way round this, however.

What you do is build the hole detector as a self-contained unit which you do not embed into the CAM system. It’d be a program that runs from the command line, takes, say, an STL file, and writes out a simple text file that lists the location of all the drill-holes.

Normally, running modules this way is ugly and unfavourable because it requires setting off external processes in the operating system and passing information around in temporary files, when it is far cleaner to compile and embed a module directly into the system. However, this would mean that, firstly, such a program could be developed as a fully free open source product under the GNU General Public License, and yet everyone in the commercial world could use it.

And, secondly, the format of this temporary file would be visible and available to anyone who cared.

Suppose all the CAM vendors started borrowing, using, and debugging this module because it’s cheaper and easier than writing their own, kind of like the way we use zip module rather than write one (for many years Machining Strategist/Depocam has piped its data-files through zlib to make them smaller).

Suppose all they had to write in order to latch on to the power of this free module that detected the holes was something that read its simple output files.

Suppose a CAD system developer could see that they could get their holes imported perfectly into every single CAM system at once if they wrote out a version of this hole file at the same time as their geometry file so that the 95% reliable hole detector no longer had to run.

Then that would look like a plan for reaching the correct goal one step at a time. The goal being to overcome the deficiencies of our exchange formats by sending small scraps of information alongside them.

I don’t have any experience with hole detectors or drill cycles myself, so I have simply made all this up.

If I had to write a hole detector, I’d build it in three stages.

(1) Use a Hough transform to find collections of parallel lines in the model. Holes and pockets tend to have edges parallel to their axes to form the walls, at least in the way that they are conventionally triangulated. This is pretty obvious.

(2) Take each orientation in turn and consider all the edges parallel to that orientation so that they become points in that plane of projection. Apply a Hough transform to detect arcs and circles between these points. This is standard science.

(3) Now with a large set of candidate cylinders test each one in turn for interference against the model to calculate the depth of each hole. This function exists in all CAM systems — it’s the depth of cut for a particular shaped tool at a given location.

That’s how I’d do it. Of course, any extablished software company is free to publish their own algorithm and software to do it. This would not be unprecedented, as something similar appears to have been done by Rhinocad with their open nurbs initiative.

Alternatively, if someone wants me to look more deeply into it they’ll have to mail me some CAD files I can read and an outline of the format for the data in the holes file. I think it would be an interesting side project if someone was willing to do the other half of actually using it.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>