The machine was running fine last month. What did we change?

GI4 saves every recipe and creates a new version each time it changes, on its own. It compares versions, recipes and the real machine, and makes even the most cryptic parameters readable.

Let's talk about your plant

The questions on this page

“Nobody remembers to save versions.”Automatic versions, without thinking about it
“How far has the machine drifted from how it should be set up?”The three-column comparison
“The panel shows a different value from the recipe: mistake or trial?”Differences are recorded, not corrected
“1,107,296,262: what does that number mean?”Packed parameters, readable at last
“And what if the machine is running?”Writes to the machine happen only when it is stopped

The problem

“Nobody remembers to save versions.”

Automatic versions, without thinking about it

GI4 automatically saves every new recipe, with its name and all parameter values. On every later save, if something has changed, a new version is created with its number: v.1, v.2, v.3. Nobody has to remember to do it.

Hence the change table: versions in columns with their dates, parameters in rows, and at a glance what changed and when. Every recipe also shows who last updated it.

GI4 app: list of a machine’s recipes with version, dates and parameter detail — A machine’s recipes, each with its version.

The problem

“How far has the machine drifted from how it should be set up?”

The three-column comparison

You can compare two different recipes for the same machine, or two versions of the same recipe. But you are not comparing two documents: alongside them is the current value on the machine, so you see two recipes against the controller’s real state.

Filters isolate what you need: rows where the two recipes differ, rows where the machine departs from one or the other, active steps only, important parameters only. The result exports to Excel.

GI4 app: comparison between two recipes with the current value on the machine and the values of both recipes — Value on the machine, recipe 1, recipe 2: differences in colour.

The problem

“The panel shows a different value from the recipe: mistake or trial?”

Differences are recorded, not corrected

An operator starts a recipe and then tweaks a value on the panel. It happens, and it is often a trial meant to be reversed. GI4 doesn’t wipe it out: it shows the machine value next to the recipe value, counts the differences and flags them.

From there, two paths, and it is a plant decision: align, by saving the recipe from GI4, or follow the controller. A system that forced alignment would destroy exactly the most interesting data: what operators have been trying.

GI4 app: recipe rows with current machine value and recipe value, the difference highlighted in orange — In orange, the machine value that doesn’t match the recipe.

The problem

“1,107,296,262: what does that number mean?”

Packed parameters, readable at last

PLC recipes have a row limit, typically 500, and machines grow. So several settings end up packed into the bits of a single number: one wash step can hold a dozen.

The number alone is unreadable. GI4 shows the decoded meaning next to it, and one click opens a form grouped by machine function — drum: speed and direction; water: fill and drain level; dosing — editable field by field.

The problem

“And what if the machine is running?”

Writes to the machine happen only when it is stopped

What you prepare in GI4 stays in GI4 until it is sent. Creating, duplicating, renaming or disabling a recipe doesn’t touch the controller. Sending is a separate act, with a dedicated command or at batch change, and happens only with the machine stopped and only if the logic agreed for that plant allows it.

When a new parameter is added after a recipe already exists, GI4 proposes the real value on the machine and asks for confirmation. Until confirmed, it isn’t sent: better to send nothing than a zero which, on a packed value, means “everything off”.