§ 01 · Industrial · Software · Since 2019
CNC software at T&S Machines
Four years of writing the software that runs the Blockmaster.
Probing routines, cutting and boring and chamfering operations, screen merges against Mach4, refactoring legacy work for efficiency, customer support, and a Docker side-project for cleaner deployment. Started as a UNT student worker in 2019; the role became Digital Specialist in late 2023.
§ 02 - The work
The work
Most of what I do at T&S is writing and maintaining the software that runs the Blockmaster, our flagship CNC machine. The work breaks roughly into three buckets: new machining routines, refactoring of legacy code, and screen merges against Mach4 (the upstream CNC software we fork our UI from).
The new routines are what they sound like: programs that drive the machine through specific operations like cutting, boring, and chamfering. These get written to customer specifications, alongside probing routines for setup. UI changes ride along, since the operator needs a way to invoke each new routine.
The refactoring work is harder to describe in one sentence because each piece is its own small story. The clearest example is the coolant toggle: the legacy implementation had a hacky branching solution to handle on/off state, and I replaced it with a single check at the top of the cutting process. That's the shape of most of the refactoring - finding the load-bearing condition that the legacy code danced around, and writing it once where it belongs.
Screen merging is a recurring engineering problem more than a one-time project. Mach4 ships UI updates, we maintain a forked version with our own screens and customizations, and every Mach4 release is a merge that needs careful reconciliation. It's not glamorous work but it's the kind of work that has to be done correctly or the next release breaks for every customer.
Customer support is occasional. Mostly remote sessions to fix a unique bug on a specific customer's setup, or sometimes a math issue I didn't catch in testing that's faster to patch on their machine first and then port back to the main codebase.
§ 03 - The Docker side-project
The Docker side-project
Separately from the main work, I containerized the application with Docker as a personal side-project. The motivation was practical: most employers are moving CI/CD toward Docker or Kubernetes, and I wanted real hands-on experience starting with Docker on a codebase I knew well. T&S didn't prioritize it as a deployment path; the existing manual installer process works for current customers, and switching would be a significant operational change. So the Docker work has lived as my own initiative on a low-priority track.
What I built is mainly the base image: a Windows container with the application and its dependencies bundled, built through GitLab CI on each commit. The setup follows Docker's get-started guide closely; the value for me wasn't the architectural novelty but the experience of taking a real production codebase from "ships as an installer" to "runs as a container." I'd start a future Kubernetes effort from this foundation when applicable.
§ 04 - My role
My role
I've been the primary developer on the Blockmaster software since 2019, originally as a UNT student worker and currently as Digital Specialist. The work is mostly mine on the software side, though other developers have contributed; coordination happens with mechanical engineers, the customer support team, and customers directly when remote sessions come up.
Specifically:
New machining routines. Wrote and maintain the cutting, boring, chamfering, and probing routines that drive the machine through its operations. UI changes ride along with each new routine.
Refactoring of legacy code. Replaced hacky branching solutions with cleaner conditions at the right level of the code. The coolant toggle is the clearest example, but the pattern recurs across the codebase.
Screen merges against Mach4. Reconcile T&S's forked UI with each upstream Mach4 release. Recurring work, has to be done correctly.
Documentation. Authored and maintain the customer-facing technical documentation, distributed via GitLab.
Customer support. Remote sessions to fix unique bugs and deploy patches; usually port the fix back to the main codebase after the customer's installation is stable.
Docker side-project. Built the base image and GitLab CI pipeline for the containerized version. Personal initiative, not part of T&S's deployment process.
The mechanical and electrical engineering on the Blockmaster is owned by other team members; my scope is the software that runs on it.
§ 05 - Current state
Current state
The Blockmaster software is feature-complete and stable in production. Most of the active work now is small additions: a new routine when a customer needs a specific operation, a UI tweak, a Mach4 merge when an upstream release lands. The cadence is "occasional requests" rather than "constant feature work," which is the right shape for a mature codebase running on real machines.
The Docker side-project is also feature-complete in its own scope. The base image works, the GitLab CI pipeline builds cleanly, and I keep it current as the application evolves. Whether T&S adopts containerized deployment as a real path is a leadership decision that's outside my scope; the technical groundwork exists either way.
What I'm thinking about next is Kubernetes. Most of the deployment patterns I'd want to learn from in industry are using Kubernetes for orchestration, and a future Kubernetes effort would build naturally on the Docker work. Not a current T&S priority, but a logical next step for me personally.