Freesteel Blog » Automatic feature detection

Automatic feature detection

Thursday, January 12th, 2006 at 12:08 pm Written by:

Neel wrote:

I guess whats required here is feature (hole,pockets,etc) recognition from surface models

Ah, yes. This old one. This is important enough to bring to the front. I’m going away on holiday for a week, so won’t be able to follow up on any comments.

Most software developers ignore this feature-request because they expect the problem to go away/solve itself when people start using a decent CAD translation format.

We can understand the point of feature recognition from scanned parts and X-ray images, but recognizing features from a pure CAD model where one would assume the CAD operator had typed those numbers (eg diameters of holes) in themselves and the CAD system has recorded seems crazy.

On short, the only reason the CAM system doesn’t know the diameters of all the holes/pockets that were designed in the CAD system is because the data has been transfered in too primitive a format.

And once users and systems designers start transfering the data in a more appropriate format such that it carries over the existing information the users require for machining, the problem would go away.

Even without this, most CAD systems could easily run an automatic script/macro to print out a short ascii file that simply told the CAM system where all the holes were, one per line of text. Not a big deal.

Unfortunately, we can’t account for the mindbogglingly conservative nature of CADCAM users and organizations which must rest on some very shallow understanding of what a file format is. It’s as baffling as a bureaucrat who requires all forms be posted to him in the “correct” sized envelope, no questions asked, because the contents might change in transit. Sure, if you have a special envelope that is inked on the inside, or can be opened and resealed without people noticing, or requires the forms to be folded too many times to fit, he’d have a point. But it depends on the envelope. It can’t just be “wrong”; there has to be something wrong about it in particular. And if they can’t say what it is so we can check it out, then we’re not going to get anywhere.

I’ve had this experience of persuading people to use PNG files for bitmaps rather than TIFFs, and they don’t want to consider it because they think TIFF is the “professional” format for saving images that without “crappy” loss in compression which PNG’s might have, even if they’ve not heard of the PNG format before. For reference, JPG is the lossy image file format which compresses well, PNG always preserves the image completely but compresses it like zip, and TIFF isn’t really a single file format, it’s several rolled into one and sometimes can be lossy like JPG. But TIFF is thought — wrongly — by many people as the one true loss-less format. They don’t know where they got this idea, but they are sure it’s right.

If general understanding about image files can be that wrong even though the the results can be tested directly, understanding CAD file formats is going to be a lot worse. People are going to stick with the formats they rely on for 50 years at least. The only formats that do change are the proprietary formats owned by their CAD system suppliers who give them a new one with their new version of the software whether they like it or not.

What about that idea of writing out a separate file of hole locations to go with the CAD file which the CAM system can use? This should be easy, so why doesn’t it ever happen? The fact that it doesn’t is evidence that cooperation between the developers of a CAD system and a CAM system is zero. They don’t even know about each other’s products.

The way it could work is if you got with your new CAM system a little module that you installed into the CAD system that made it save out these files of additional feature data. Since many software suppliers sell both systems at once to a user, I am not sure why I’ve never seen this solution around. It may exist somewhere. But it feels like there may be a cultural barrier, even though there shouldn’t be. Whenever you buy a new printer you get a CD with the driver which you have to install on your computer to make it run properly.

Anyway, suffice to say that none of these obvious ways through appear to be happening, so we’re left at the point where the CAM system designer/programmer is getting ridiculous requests to write functions to recreate the data of where the holes and simple pockets were cut into a set of triangulated surfaces that was created an hour ago by someone typing in those same holes and pockets. I mean, why not just print out the design on paper and scan it in using OCR to transfer the data instead of sending it electronically? In another world this would be happening, and it’d be locked-in by the peculiar dysfunctional integration within the market and the way that the separate products are sold on the basis of people’s misunderstanding and lack of control over the whole process keeping them trapped in a local minima of inefficiency.

There are techniques for detecting holes and pockets, such as the Hough transform, which one would have to implement. But you don’t want to do it. The holes in the surface/triangulated model are not going to be perfect, so you need to allow a tolerance for detecting them.

Once you go down this route it all turns to bollocks. You have to guess what tolerance the circles are going to fit. This can change. When you get the hole detector working on one set of examples and let the users try it out, you can be sure it will start to fail because they use a looser tolerance. Instead of a hole being modelled by a polygon of a 100 sides, they do it with 50. It’s impossible to tell them to simply tighten up their tolerance, because this message won’t get through, or they know better; you see, files get too large if you triangulate them to a tighter tolerance and they’re not about to reconsider this opinion in light of the fact that computers have a 100 times more memory now than when that opinion was formed. Either that or they don’t know how to set the tolerance, and it’s one of the defaults in the file-writer.

While you can get lots of grief for not detecting the holes which the user can plainly see, it’s an absolute disaster if you get any false positives. That is when you mark as circular something which is not. Suppose the user really wants a 30 sided polygon, but you drill it out smooth. Suppose the designer wants a slightly elliptical hole, but now it’s not possible to specify it because the CAM systems knows better and forces it to be circular. To overcome these errors you need an interface so the user to mark as not-circular those holes the system has erroneously marked as circular. There are enough marginal cases that there is no theoretically right answer. The really “good” software will have been debugged case-by-case over years on the basis of user reports, and will be tuned to guess correctly from the habits they’ve come across. This is not good, because then habits get locked in and prevented from changing.

We have 30 different CAM vendors who have all written 30 different hole detectors. There is no competition between them because you have to change your whole CAM system to try a different hole detector. It’s time for some open software so we can all use the same one, and debug it collaboratively as we encounter the types of exceptions that users create. It can’t keep going on like it’s going now for the next 100 years.


  • 1. Neel replies at 12th January 2006, 1:32 pm :

    I agree that there are very few cad packages which write out holes which can be read by third party can package, and those who do ,the format is only read by their cam packages . Its like if you are using our design software use our cam software too however crap it is.
    Some of the data translator packages try to recognise the features, mostly for solid based modellers. The hole detection algorithm try to find cylinders and generally gets confused with half cylinders & fillets.
    There is a need for an open format where the features gets transferred to other cad/cam packages , which will definitely benefit the feature based jobs.Generally production shops which machine 2.5D features and drilling holes . 80% of the Job can be done by feature machining in producation shops.
    For mesh based cam packages its more difficult to recognise the features recreate the data of where the holes and simple pockets are from set of polygon meshes & would depend on many factor like triangulation tolerance & arc fitting tolerance.
    Hope there is standardisation and Iges & step files can store different hole types and simple pockets.

  • 2. Barry Dyson replies at 13th January 2006, 11:29 pm :

    To date I have only seen two AFR-MFR CAm products that work seriously well.

    1) An add on to Peps called “Mill Expert” written by an Australian (Russian immigrant) Mr. Mark Goldfeld.

    2) FeatureCAM

    Both of these products work exceptionally well.
    Both include user interaction for machining refinements.
    But both are dedicated to their respective CAM products.

    I would really like to get hold of a generic solution that could be added on to a generic Solid based CAD system
    As you know STS is the Australian Distributor for KeyCreator (formnerly CADKEY).
    KeyCreator works exceedingly well as a genberic CAD solution with the ability to import data from virtually and other CAD/CAM source and edit the imported data as though it was native to KeyCreator itself.
    However the CAM productoffered by KeyCreator (formerly VNC

  • 3. Barry Dyson replies at 13th January 2006, 11:37 pm :

    I had a whole lot more in the previous response but it seems to have been cropped off.
    Sorry guys, Barry

  • 4. Freesteel » Blog Ar&hellip replies at 22nd January 2006, 10:33 pm :

    […] Freesteel Machine tools don’t need friends « Automatic feature detection Feature detection compromised Thanks for the commen […]

  • 5. Julian Todd replies at 22nd January 2006, 10:34 pm :

    Follow-up posted as article at:

Leave a comment

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