Injection Molding Cell

A four-machine injection moulding cell on shared utilities, read by one Litmus Edge over two protocols at once: the moulding machines over OPC UA in the EUROMAP 77 shape, and the central dryer, mould temperature control units and chiller over Modbus TCP. Eight devices, 158 tags.

Two Engel victory 150s run eight-cavity polyamide connector tools, an Arburg 570 A runs a four-cavity PBT sensor body, and a Husky HyPET 650 runs a two-cavity polyethylene crate. One central desiccant dryer feeds the three machines on hygroscopic resin, two mould temperature control units hold the tools, and a chilled water plant cools both units.

It is the first solution in the set on EUROMAP 77, and it splits its protocols by asset, which is how a real moulding shop is wired: the machines carry a modern OPC UA interface, the auxiliaries carry a Modbus register map. The question the cell answers needs both, because a cause in a shared utility only shows when its reading is joined to the machines it feeds.

The simulated clock runs at 8x real time, so a cycle of 16 to 52 seconds is watchable and a dryer losing its dew point plays out over minutes rather than an hour.

Three scenarios ship with the solution. None of them trips an alarm: every shot stays inside its machine's own limits, and the cause shows only in readings Litmus Edge joins.

EUROMAP 77 (OPC 40077) is the OPC UA companion specification for injection moulding machines. It gives every machine the same folder structure, so a client finds the cushion, the cycle time or the job counters in the same place whatever the make. Each machine is published under Objects/Machines/<device>/ with:

The register name on the OPC UA driver is the string node id, for example ns=2;s=PI1_IMM01.InjectionUnits.InjectionUnit_1.ActVolCush. The four job counters use their EUROMAP 77 browse names (JobCycleCounter, JobPartsCounter, JobGoodPartsCounter, JobBadPartsCounter); every other variable keeps its EUROMAP 63 name, such as ActVolCush, ActPrsInjPeak, ActTimPlst and ActPrsCav6, which is the vocabulary moulders already use.

The utilities are four Modbus TCP stations behind one port, told apart by unit id: 21 for the dryer, 31 and 32 for the TCUs, 41 for the chiller. Representative registers: DryDewPointC, MoisturePpm, RegenTempC, SupplyTempC, DeltaTempC, CoolingLoadKw, CopRatio.

The four moulding machines are four instances of one model, InjectionMouldingMachine, and the two temperature units are two instances of MouldTemperatureUnit. The dryer is ResinDryer and the chiller ChilledWaterPlant.

Every script returns a verdict rather than throwing when an input has no value, so a device that stops answering reads as "no reading from the device" instead of stalling Analytics. 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 is deployed with a compose file. It publishes three ports, and both protocol ports matter: an Edge that cannot reach 5032 or 5132 configures cleanly and then reads nothing from that half of the cell.

Download plastics-molding-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:

Put the three values in a .env file beside it:

Start it:

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:4022. Within about a minute the Edge is configured and the page fills in.

The page stays on its waiting panel until the Edge carries all eight devices and is polling them. The simulation does not tick and no value is shown until then, so nothing on screen can be mistaken for data that never made the trip. With APPLY_ON_START at its default of 1 the solution configures the Edge itself on startup, which takes 30 to 60 seconds. If you set it to 0, or the apply failed, press Apply to Edge in the page header.

SIM_HOST requires attention. The one address is written into both halves of the template: the OPC UA server URL of the four machines and the Modbus TCP address of the four utilities. Leave it auto when the solution runs on the Edge itself or with host networking. Otherwise set it to the address of the host running the solution, as the Edge sees it.

An incorrect value fails quietly: the devices are created and no tag ever reads a value. The solution refuses to apply a template whose address is obviously unreachable, and does not open its page until the Edge reports the devices as polling, not just present.

This solution can also publish its 8 Digital Twins into Litmus Unify, one message per asset under meridian-polymer/halstead/.... 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.

The page opens with what you are looking at and the question it answers: is the cell still making good parts at the cycle it was quoted, and when it is not, is the cause one screw, one cavity, or a utility every machine shares?

Five figures follow, each naming the machine it comes from: cushion spread, cavity balance, the dryer's dew point with the resin moisture at the hopper, cycle over quote, and cost per shift.

Below that is an animated mimic of the cell. Each machine cycles at its own pace, clamp closing, screw injecting and recovering, cavities filling with each shot. Clicking any machine or utility opens its Digital Twin instance: the model, its static attributes and every dynamic attribute with its live value and topic.

The rest of the page follows the process: the screw, as the last 25 shots of cushion on each machine against its nominal and the floor where the screw bottoms out; the tool, as peak pressure in every cavity against each tool's mean; and the dryer, as the dew point trend and each resin's moisture against its own limit. A section then shows the last result of every Analytics processor, read back from the Edge, so the verdicts are the Edge's rather than the page's.

Each scenario has a card naming the Analytics group that catches it and the DataHub topics to watch, beside the event log.

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

The solution removes only what it created, and records which Edge its apply landed on, so repointing at a different Edge cannot leave a solution stranded on the first one. Clean up in the Solutions provisioner does the same.

Preview report and Export report produce the shift report as one self-contained HTML file, inline charts and no scripts, so it opens offline, emails and prints. It carries the five figures, what the run cost, a row per machine, cavity pressure, the dryer dew point, the faults injected, what Litmus Edge computed, and the Litmus Edge configuration that produced it.

[email protected]