Getting a recipe approved in the ERP or MES to the PLC so that the right line runs with the right parameters is one of the most sensitive steps in integration projects. A read error spoils a report; a write error spoils the product or the machine. That is why recipe transfer is a controlled operation, not “write the values and finish”.
The recipe is held in a single source and versioned; writing to the PLC is done with a handshake: write → ready flag → PLC validates → read back and compare → report the result. Every step is logged.
The handshake: four steps
- The recipe is written. All parameters are written to a staging data block in the PLC; the running recipe is not touched.
- Ready flag. A flag is set only after all values are written. Putting the flag last prevents the PLC from using a half-written recipe.
- The PLC validates. Range and consistency checks (ranges, interdependent parameters, line state) are done on the PLC side; the result is reported as an accept or reject code.
- Read back and report. The integration layer reads back the values it wrote, compares them with what was sent and writes the result to the MES. Until an acknowledgement arrives the recipe is not considered accepted.
Design decisions
A single source of truth and versioning
The master record of the recipe should be in one system (ERP or MES). Add an id, a version number and, where possible, a checksum to every recipe. The PLC should know which version is running and write it to the production record, so “which recipe was this batch made with?” can be answered.
Separate download from activation
Downloading a recipe to the PLC and activating it are different actions. Download can happen at any time; activation should happen only when the line is in a suitable state (idle, between batches) and with operator or MES approval. Do not change parameters in the middle of a running batch.
Validate in the PLC
Checks in the integration layer are not enough; the last line of defence is the PLC. Out-of-range or mutually inconsistent values should be rejected by the PLC, and the reason for rejection reported back.
Timeout and retry
What if the PLC gives no acknowledgement? After a defined time the transfer should be counted as failed, reported to the MES and the operator alerted. A retry must not activate the same recipe twice (duplicate check by id and version).
Audit trail
Who wrote which recipe version to which line and when, and how did the PLC respond? This record is needed for traceability and post-incident analysis. Write permission should be granted only to the relevant flow.
Risks and countermeasures
| Risk | Consequence | Countermeasure |
|---|---|---|
| A half-written recipe is used | Faulty product or machine stress | Ready flag last; staging versus running block separation |
| Change during a running batch | Mixed batch, quality problem | Activate only in a suitable state |
| Out-of-range value | Equipment or safety risk | Limit and consistency validation in the PLC |
| Communication interruption | Uncertain state | Timeout, read-back, persistent error notification |
| Duplicate transfer | Double activation | Id and version check |
| Untraceable change | Loss of responsibility and traceability | Full audit trail |
Implementation tools and testing
An integration tool such as OPC Router sets up the two-way flow between the ERP/MES and the PLC; the trigger can be “recipe approved” (designing data flows with OPC Router). Before going live, test: a normal transfer, an out-of-range value, a timeout when the PLC does not acknowledge, connection loss and a duplicate transfer (integration acceptance test).
Frequently asked questions
Can I write the recipe directly into the running data block?
It is not recommended. Write to a staging block first and let the PLC activate after validation, so a half-written or faulty recipe does not enter production.
Why is a checksum needed?
It proves with an extra check that the written values arrived complete and uncorrupted; useful especially for large recipes.
Should recipe management be in the PLC or the MES?
The master record should be in the MES/ERP, and application and validation in the PLC. With a clear separation of roles each layer provides its own assurance.
