Building My Own Tool Scanner — Part 15: Sometimes I Actually Want the Holes

For a storage pocket, filling internal holes is often useful.

If a tool has an opening through its body, I don't necessarily want a matching island of plastic left inside the pocket. The outside silhouette is usually the geometry I need.

That doesn't make internal geometry useless for every other purpose.

On 24 October, a second scan option was added: preserve the visible internal details and holes instead of always producing the simplified pocket silhouette.

Make it a choice

Up to this point I'd mainly wanted the outside of a tool. For a storage pocket, that makes sense: the tool drops into a recess, and I generally don't need a collection of little plastic islands standing up through every opening in its body. But there are other jobs where those internal features are exactly what I want to measure. A hole, a slot or an opening can be important geometry in its own right. I didn't want to build a second scanner just to keep information the first one had deliberately thrown away.

The option appeared in both the web scanner and Gridfinity's scan dialog. Unchecked retained the existing outline-only behaviour; checked kept detected internal contours through the measured and Fusion outputs.

That required more than changing an export label. Earlier processing filled or removed holes, and selecting only an exterior path would discard them even if the original mask contained them.

The chosen mode had to be carried through the processing and recorded in the report.

“Preserve details” also needed a sensible definition. It meant visible contours detected in the image, not hidden surfaces, engraving depth or a complete mechanical model of the tool.

The rectangle nobody asked for

The sensible answer was a choice in the interface. Keep the normal outline-only behaviour for the Gridfinity pocket workflow, and add a mode that preserves detected internal contours when I ask for them. That sounds like a checkbox job, doesn't it? Unfortunately, a checkbox on the screen doesn't guarantee the processing behind it is doing anything different. The option had to survive the trip through the mask, tracing, export and report.

The first full-detail live comparison exposed an unwanted rectangle around the image.

The Python tracing path had the foreground polarity reversed. Selecting the exterior tool result in the old workflow had hidden the consequence. Keeping all contours made the image boundary an obvious extra feature.

The export wasn't accepted just because it now contained more paths.

Polarity was corrected and a known-hole pattern tested. The web service also failed to return during its automatic restart and needed a manual restart before the live checks could continue.

Two separate failures, neither improved by pretending the checkbox itself was the difficult part.

Same photo, different purpose

The surprise rectangle was a good demonstration of how an old assumption can hide for ages. When the pipeline only kept the outside path, an incorrect foreground convention could go unnoticed because the unwanted result was discarded. As soon as I asked for all the contours, there it was: a lovely outline of the image boundary that nobody had requested. More detail had exposed a bug rather than created a new one.

The first accepted saved-image comparison produced zero internal holes in outline mode and nine in detail mode, with matching exterior dimensions. A detail-profile insert then passed STEP round-trip and closed STL checks.

The next controlled comparison used a fresh photograph through both modes. That removed a camera recapture as a possible explanation for any dimensional difference between the outputs.

The maximum exterior difference between the two imported profiles was about 0.01635 mm, within the stated 0.1 mm comparison tolerance. The measured SVG bounds matched exactly at the reported precision.

The earlier nine-hole result and this ten-hole result came from different photographs. Combining them into one definitive count would make the story tidier and the evidence worse.

The small inter-mode difference also isn't a scanner accuracy specification. It tells me that these two processing choices produced consistent outer dimensions from that input.

More detail changes the manufacturing decision

I particularly wanted the two modes compared on the same photograph. Otherwise any difference could be blamed on the camera, focus or a slight change in where the tool was sitting. Process one fresh image both ways and the question becomes much cleaner: does keeping internal holes alter the outside dimensions? The recorded comparison showed the exterior staying effectively the same while the internal paths changed as intended. That's the behaviour I was after.

Retaining a hole in a cutting profile can leave material inside the opening. Clearance offsets can also reduce or remove small internal regions.

The detailed SVG may therefore be useful measurement geometry while being the wrong cutter for a simple storage insert. That is precisely why the default outline mode remains useful.

The latest recorded full software runs reached 192 Gridfinity tests and 18 A3 tests. The digital export check was successful, but it wasn't a new physical print-fit test for every internal-detail arrangement.

Another useful boundary

And just because the scanner can preserve ten holes doesn't mean the generator should automatically cut ten holes into every storage pocket. That is a design decision, not a measurement decision. The scanner should tell me what it sees. The generator should let me decide what I want to manufacture. Keeping those jobs separate makes both programs more useful.

Titan could now intentionally provide either the exterior pocket profile or a more detailed visible contour set, with the choice made explicit rather than buried inside cleanup code.

It had also produced two more reminders that broadening a feature can reveal an old assumption: the tracer's foreground convention and the distinction between “more geometry” and “the right geometry for this job”.

That brings this section of the development record up to date.

There is a useful system here now, along with a much clearer account of what its results do and don't establish.

Before following the next development problem, it's worth taking stock of how much machinery ended up between a ratchet and its drawer.

Next: Part 16 — All This, So I Could Put a Ratchet in a Drawer