Rock Creek Granite · Project Brief · Draft for discussion
Feasibility assessment and build plan for automating program preparation from templator DXF to reviewed, machine-ready programs — splitting work between the Sasso K-600 saw and the Park Industries TITAN Fabcenter.
This is feasible, and the architecture is unusually favorable for automation. Everything already flows through one CAM hub (Alphacam) that exposes a documented automation API, the input is a consistent machine-generated DXF, and both output paths (K-600 NC, TITAN G-code) already work through existing post-processors. Nothing here requires inventing new CAM technology — the build is orchestration, rules, and glue around tools the shop already owns.
The single biggest unknown is not whether Alphacam can be automated (it can), but how much of the Sasso and Park custom toolbars' behavior is reachable through the API, versus locked inside their add-ins. That question is answerable in weeks, cheaply, and the plan below is structured to answer it first — before any serious code is written.
Marked throughout: verify = a claim to confirm with the vendor before relying on it. K-600 and TITAN tags follow the two machines through the document.
For contributors new to the trade, here is the world this project lives in. Rock Creek Granite makes custom stone countertops. Every job is one-off: a customer picks a slab of granite or quartz (roughly 5×10 feet, 2–3 cm thick, several hundred pounds, brittle, and expensive), and the shop turns it into finished counters that must fit that customer's cabinets precisely. The production flow is: measure the customer's kitchen, lay the pieces out on the slab, cut them free, shape and polish the visible edges, and install. Two machines and a polishing crew do the physical work; everything before that is software.
A laser measuring device taken to the customer's home. It captures the exact geometry of the cabinets and walls and produces a DXF — a standard CAD drawing file containing the precise outlines of every countertop piece to be made. This drawing is the input to everything downstream.
A 5-axis bridge saw: a large diamond-coated circular blade on a gantry over a table that holds the slab. “5-axis” means the blade moves in X/Y/Z and also tilts and rotates, so it can cut angled edges (miters), not just straight lines. The diamond blade is the fast, efficient way to cut pieces out of a slab. The K-600 can also swap the blade for a fingerbit — a cylindrical milling bit that machines shapes a blade can’t, like curved sink openings — but that is far slower than blade work. Today the K-600 does both jobs for every piece, which makes it the shop’s bottleneck.
A computer-controlled router: a fast-spinning spindle that automatically picks up different diamond tools from a rack. It cuts interior openings (sink and cooktop cutouts), machines decorative edge profiles, and — critically for this project — polishes: it runs a sequence of progressively finer abrasive heads along the edges until they shine, work the shop currently does by hand. The TITAN is newly installed; putting it to full use is what this project is about.
Machines don’t read drawings; they read instruction files (generically G-code, or NC files — long lists of “move here, spin this, cut that”). Alphacam is the CAM (computer-aided manufacturing) program that bridges the gap: a programmer imports the templator’s DXF, decides which tools do what and in what order, and Alphacam’s post-processors translate the result into each machine’s dialect. Both Sasso and Park Industries supply custom toolbars inside Alphacam for their machines. Separately, Slabsmith keeps a photographic inventory of every slab in the shop, so pieces can be arranged on a slab’s photo — matching the stone’s veining across seams and steering around flaws — before anything is cut. Arranging pieces to waste as little stone as possible is called nesting; leftover usable stone is a remnant.
With that vocabulary, the rest of the document reads plainly: today a human does all the translation from drawing to machine instructions, and one machine does all the cutting. The project automates the translation and splits the cutting.
Today the K-600 does everything: blade cuts, rough shaping, and the precision fingerbit millwork. A crew of hand polishers finishes every piece. The programmer builds each program manually in Alphacam from the LT-2D3D templator's DXF, using the Sasso toolbar.
The target state moves the K-600 to what a 5-axis bridge saw does best — blade work and rough shaping — and hands profiling and polishing to the TITAN. Program preparation for both machines happens automatically as soon as the DXF lands, with the programmer's job compressed to a single review-and-approve step inside Alphacam.
The wins compound: programming hours per job drop, saw time per job drops (blade work only), polish labor drops (the TITAN polishes profiled edges), and total shop throughput rises without adding headcount. The K-600 and TITAN can also run concurrently on different jobs once the pipeline stages work — the saw is roughing job B while the TITAN finishes job A.
Five facts about the existing setup do most of the work. For the developer reading this: the stone-industry specifics are new, but the shape of the problem is not — it is a document-processing pipeline with a CAD/CAM engine in the middle and a human approval gate.
Both machines are programmed from the same Alphacam seat. Alphacam exposes a COM automation API: the application object model covers opening drawings, importing DXF, creating and editing geometry, managing layers, applying machining operations and styles, nesting, and running post-processors. It is scriptable three ways: VBA inside Alphacam itself, .NET add-ins (C# is the natural choice), and any COM-capable external language — which includes Python via pywin32, squarely in the development partner's wheelhouse. The API ships with its own help documentation in the Alphacam install. verify — confirm with the Alphacam reseller which API features the shop's license tier includes, and get the API help file into the developer's hands in week one.
Hexagon offers an Alphacam module called Automation Manager, built for exactly this pattern: batch-ingest CAD files, apply machining rules by layer/geometry conventions, nest parts onto stock, and emit NC — drawing in, program out, unattended. Whether or not the shop licenses it, its existence matters twice over: it proves the vendor supports this workflow on this product, and it may cover a chunk of the pipeline off the shelf, shrinking the custom build to the parts that are unique to Rock Creek (the two-machine split, slab logic, and shop SOPs). verify — get a demo and pricing; evaluate build-on-top vs. build-alongside.
The DXF comes from the LT-2D3D, not from a human freehanding in CAD. Machine-generated files have stable layer names, closed polylines, and predictable structure — which is what makes rule-based automation reliable. Layer conventions are the contract of this whole system: this layer means finished edge, this one means seam, this one means sink cutout, this polyline is the countertop perimeter. Tightening and documenting that convention (in the templating SOP) is cheap and pays for itself in every later stage.
Slabsmith (Northwood Designs) provides calibrated slab photography, a slab and remnant inventory database, the Perfect Match layout module for vein and color matching, and DXF export toward CAD/CAM. Park Industries' own ecosystem (Park EZ buttons in Alphacam, SlabSmith, tMatch, Slab Inventory, SPEEDlabel) is explicitly built around this digital workflow. The pipeline should integrate slab imaging, not reimplement it. verify — what programmatic access Slabsmith offers (database access, file exchange, command line, or API) for automated layout-into-slab placement.
The shop already produces working K-600 NC and TITAN G-code through vendor-supplied post-processors and toolbars. The pipeline never has to understand either machine's dialect — it has to reliably drive the same Alphacam machinery the programmer drives by hand today. Post-processors are the most dangerous thing to rewrite and the best thing to leave alone.
Naming these now is what makes the plan credible. Phase 0 exists to convert each one from unknown to known before significant money or code is spent.
The Sasso toolbar and Park EZ buttons are themselves Alphacam add-ins. Their internals are not publicly documented, and it is unknown how much of what they do (tool selection, canned cycles, machine-specific setup, post configuration) is invocable from the API versus only from a human clicking the button. Three mitigation paths, in order of preference:
The proposed system is a staged pipeline with exactly one human gate. Each stage is independently testable, fails loudly into an exception queue rather than guessing, and writes its state to a job record — so a job is always inspectable ("where is the Hendersons' island top and why is it stuck?").
| Component | What it does | Likely tech |
|---|---|---|
| job intake | Detects a new templator DXF (watch folder or LT3Raptor cloud hub export), pairs it with the work order, opens a job record. | Python service, SQLite/Postgres job DB |
| validator | Audits the DXF against the layer contract: expected layers present, profiles closed, dimensions within sanity bounds, radii not smaller than smallest tooling. Rejects into the exception queue with a human-readable reason. | Python + ezdxf |
| slab select | Chooses candidate slabs/remnants from inventory by material, size, and (for veined material) photo-based match; produces the placement constraints for nesting. | Slabsmith DB/exports verify depth |
| Alphacam driver | Drives Alphacam through COM: import DXF, assign machining styles per layer, split operations between saw and router, apply oversize allowances, nest into the chosen slab, save the prepped drawing. | Python (pywin32) and/or a thin C# add-in |
| human gate | Programmer opens the prepped drawing in Alphacam — full native tools available — adjusts if needed, and approves. Approval is an explicit action (a small add-in button or a marker file), never a timeout. | Alphacam UI + tiny add-in |
| post & release | Runs the existing posts, drops NC and G-code into per-machine folders with setup sheets and labels; archives everything against the job record. | Alphacam posts (unchanged) |
| agent layer | Watches the queue, explains exceptions, drafts fixes for known failure patterns, checks SOP rules, and writes the per-job review summary. Interface for status questions. | LLM (e.g. Claude API) over the job DB |
One workstream in this project has nothing to do with code, and it will make or break the two-machine split: how a rough-cut piece is located on the TITAN's table. When the K-600 hands a blank to the TITAN, the TITAN's program assumes the piece sits at a known position and orientation. That requires decisions the programmer and operators own:
These rules, once written down, become parameters in the Alphacam driver — the software encodes them, but the shop decides them. Budget real time in the pilot phase for cutting test pieces and dialing this in.
A design principle worth agreeing on early, because it determines what kind of software gets built: the core pipeline should be deterministic, and the AI should live at the edges. Toolpaths, nesting, offsets, and posted code must come from CAM math and explicit rules — the same input producing the same output every time, diffable and testable. A language model should never be in the loop that decides where a blade goes.
Where an agent adds real leverage:
This split also derisks the project: if every AI component were deleted, the pipeline would still run — quieter and less helpful, but correct.
Five phases, each independently valuable — the project can pause after any phase and the shop keeps the gains. Durations assume the developer part-time and Ryan/programmer available for domain questions; treat them as planning shapes, not promises.
exit criterionA one-page go/no-go memo: what the API can drive, what the toolbars require, what licenses to buy. If the answer is "no-go," total spend was a few weeks of conversation.
exit criterionTen real jobs where the prepped drawing needed zero or trivial correction, and a measured drop in programming time.
exit criterionA real kitchen runs the full path — saw roughs, TITAN shapes and polishes — with hand-finishing reduced to touch-up.
exit criterionVeined-material jobs flow through the same pipeline with layouts the programmer accepts at the same rate as plain material.
exit criterionThe default day: DXFs arrive, jobs prep themselves, the programmer approves a queue each morning, operators run both machines from their folders.
Ryan / programmer own the domain: the layer contract, machining styles, SOP rules, allowances and datums, acceptance of every phase. This knowledge is the project's actual moat; the code is its expression.
The developer owns the pipeline: services, the Alphacam driver, integrations, the job database, tests. An honest note on languages: C++ is not needed here. This is a Windows-automation and glue-code project, and the right stack is Python for everything possible (services, validation with ezdxf, COM via pywin32, agent layer) plus a thin C# add-in only where living inside Alphacam's process is required (the approve button, anything the COM boundary handles poorly). Backend experience matters far more than the specific languages — queues, state machines, and "never lose a job" reliability are the actual skills this needs.
Plan on a standing weekly session where the developer watches the programmer work in Alphacam. Most of this project is transcribing what an expert already does into rules; there is no substitute for watching.
| Risk | Level | Mitigation |
|---|---|---|
| Sasso/Park toolbar behavior not reachable or replicable via API | High | Phase 0 experiment before commitment; vendor engagement; fallback scope in §04 still captures most of the win |
| A bad program reaches a machine (crash, ruined slab, safety) | High impact, controllable | Nothing posts without explicit human approval; posted code diffed against known-good jobs during pilots; operators keep first-article checks; simulate in Alphacam before release |
| Automation licensing costs or seat constraints | Medium | Priced in Phase 0 before any build; Automation Manager evaluated as buy-vs-build input |
| Templator DXF less consistent than assumed | Medium | Phase 0 audit; validator quarantines rather than guesses; templating SOP tightened at the source |
| Saw→router registration can't hold tolerance | Medium | Test-piece campaign in Phase 2; ask Park how other dual-machine shops register blanks — this workflow is their sales pitch verify |
| Slabsmith integration shallower than hoped | Medium | Phase 3 is isolated; fallback is human slab choice feeding an otherwise automated pipeline |
| Key-person dependency (one programmer, one developer) | Medium | Rules and SOPs live in versioned, readable config — not in anyone's head or hard-coded; document as built |
| Crew adoption | Low–medium | Nobody is replaced by a robot overnight: the pilot runs alongside the current process, operators keep authority to reject any program, and polishers shift to QC/touch-up as volume grows |
The Phase 0 homework, phrased as questions to ask. Answers to these convert most of this document's verify tags into facts.
Pick the numbers now so every phase can be judged against them. Suggested baseline metrics to start recording immediately, before any automation exists: programming minutes per job, jobs completed per week, saw hours per job, hand-polishing hours per job, and material yield per slab. The project pays for itself when programming time per job drops by more than half and polishing labor shifts measurably to TITAN spindle time — both of which Phase 1 and Phase 2 respectively should show on their pilot jobs, not at some distant end state.
For the two of you, the immediate next steps are small: Ryan books the reseller conversation and pulls six months of DXFs; the developer reads the Alphacam API help file and writes the DXF audit script. Everything else in this plan waits on what those two moves reveal.