CNC Machine Shop

A ten-machine CNC job shop read by one Litmus Edge over each controller's own protocol. Three controller families, five DeviceHub drivers, 300 tags, and no gateway in between.

Five scenarios, each injected on one machine, with the rest of the shop running normally beside it.

Aerospace machining reads its shop over MTConnect: one agent, one driver, tag names from the standard. That assumes the shop already runs an MTConnect agent or adapter in front of every machine.

This solution reads the controllers natively, the way most job shops actually have them: Sinumerik over S7comm, FANUC over FOCAS2 and Heidenhain over LSV2, on five different DeviceHub drivers, each controller on its own port. Each controller family speaks its own vocabulary (Sinumerik interface bits, the FANUC status structure, Heidenhain run-info strings), and the solution normalises all three into one view of the shop. A twenty-year-old FANUC 15i is read the same way as a 30i-B. It is the only solution in the set that runs three controller families at once.

Tool wear and cutting data are computed on Litmus Edge, not in the solution. The Cutting Data group carries each machine's tool table, the real tools with their diameter, teeth and lead angle and the handbook cutting data for the material they cut. From spindle speed, feed, load and tool number it works out the actual cutting speed and feed per tooth, chip thickness, removal rate, the load a sharp edge would draw, and from the gap between that and the measured load, the wear, the life left and a verdict.

It also says what it will not claim. A light finishing pass draws almost nothing over the spindle's own drag, so the Edge reports that load is not a wear signal rather than invent a verdict, and it judges nothing in the moment after a tool change while speed, feed and tool number still belong to two different tools.

Ten DeviceHub devices across five drivers, 300 tags. Six Digital Twin models, one per controller type (Sinumerik840D, Sinumerik828D, FanucSeries30i, FanucSeries15i, HeidenhainTNC640, HeidenhainITNC530), with ten instances. Six Analytics groups, 488 processors:

The apply is sent in three parts, DeviceHub, then Digital Twin, then Analytics, so the devices land and poll even if a later part does not complete. The solution then reports a partial apply rather than a failure.

The solution is deployed with a compose file. It publishes eleven ports, the operator view and one per controller.

Download cnc-machine-shop-demo-0.6.1-amd64.tar.gz from the solution's page on portal.litmus.io. The archive is the container image, not a source bundle, and needs no registry access.

docker load prints the image it added, which is the one the files below name:

Save this as docker-compose.yml:

Or, without Docker Compose, run the same image with the same .env:

Flags given with -e take precedence over .env, so change APPLY_ON_START or EDGE_VERIFY_TLS on the command line rather than in the file.

Open http://localhost:4025.

This solution can also publish its 10 Digital Twins into Litmus Unify, one message per asset under litmus-precision/dayton/.... It stays off until two things are true: the UNIFY_ values above are set, and the Litmus Edge has a Litmus UNS connector, which the Solutions provisioner can pair in one click. The next apply then publishes the twins, the page header shows how many are arriving, and removing the solution from the Edge removes its branch from Unify as well. Leave the values empty to keep Unify out of it.

Across the top: machines cutting now and the shop's cutting share of power-on time, machines down and why, the feed-override cost and the unattended standing cost an hour, the value of tool life thrown away, and tags read by the Edge out of 300.

Two views of the same shop, switched in the header and remembered per browser:

Clicking a machine in either view opens the same panel: every register the Edge polls on it, the controller variable it mirrors, the controller's value and the value the Edge read back side by side, with its topic, and that machine's cutting data and tool wear as computed on the Edge. Equations in the header sets out every formula behind the cutting data with its constants.

Every tile and figure is the Edge's reading, not the simulator's. A machine the Edge has not read yet is marked as such. State changes the Edge sees go into the event log.

Faults are the five scenarios above, each with a card naming the Analytics group that catches it and the DataHub topics to watch.

The header carries both controls. Apply to Edge pushes the devices, twins and analytics; it greys out once the solution is on the Edge. Remove from Edge previews first, listing exactly what would be removed and from which Edge, and only then offers to remove it.

The solution removes only what it created. It also records which Edge its apply landed on and removes from that one. Connections in the header points the solution at a different Edge without a restart.

The operator view stays on its waiting panel until Litmus Edge is verified to carry all ten machines and to be polling them.

Export report produces the shift report as one self-contained HTML file, built only from what the Edge read and computed: time in state per machine, the Analytics verdicts, the tool-change policy priced, and the faults that were injected. No scripts and no external requests, so it opens offline and prints.

Use Remove from Edge on the operator view, or Clean up in the Solutions provisioner, to remove what it created on the Edge.

[email protected]