Automation is usually the last item on a bottling line specification and the first one that constrains the plant two years later. Machinery is selected on output and bottle format, and the control system is described in a paragraph at the end: PLC controlled, touch screen HMI, recipe management. That paragraph decides whether a changeover takes fifteen minutes or an hour, whether a fault can be diagnosed without an engineer on site, and whether the plant can answer a customer question about which batch ran on which settings.
The cost of vague automation requirements is paid slowly. Recipes that live in an operator’s notebook rather than in the controller make every changeover a small experiment. Interlocks written in software and adjustable from the HMI create a safety risk that is invisible until an incident. Data that is not logged cannot be analysed, so process improvement becomes guesswork and customer complaints cannot be traced back to a condition. None of these appear in a payback calculation, and all of them accumulate.
Sailwin has built filling equipment for 15+ years, with 500+ machines delivered into 60+ countries, CE marking, ISO 9001:2015 manufacturing and a 2-year whole-machine warranty. Our filling lines use Siemens and Mitsubishi PLC platforms with Schneider electrical components and ABB drives, 3-in-1 rinse-fill-cap monoblocs with laminar flow filling valves and constant magnetic torque capping, and SUS304/316L construction, tested at full load for 24 hours before shipment with remote engineering support at 7×24. This article sets out how bottling line control should be structured, what belongs in the specification, and what to verify before accepting a line.
Key Takeaways
- Specify the architecture before the components. Which device owns which decision matters more than which brand of PLC is fitted, because it decides how the line behaves when something stops.
- Recipes belong in the controller. Parameters stored on a shelf or in a notebook turn a repeatable changeover into a variable one, and the cost appears as rejects rather than as downtime.
- Safety functions must not be accessible from the recipe screen. Anything that protects an operator belongs in the safety-related control path, not in a configurable parameter list.
Review Your Bottling Line Control Specification
Share the machine list, format range and reporting requirements — Sailwin engineers return a control architecture, I/O schedule and acceptance test plan.
1. Why Control Architecture Is Decided Too Late
On a bottling line there are four or five independently controlled machines and a conveyor system between them. Someone has to own line-level decisions: when to release accumulation, which machine stops first, how a restart is sequenced, and where the speed reference comes from. If that responsibility is never assigned, each machine does what its own logic dictates, and the plant discovers the behaviour only when the line is running.
The practical consequence is that diagnosis becomes political. When a line loses output, each machine’s own data says it performed normally, because each machine was indeed doing what it was programmed to do. The lost time sits in the gaps between machines, in the handshakes that were never specified. A line-level control layer with a single time-stamped event log turns that discussion into a sequence of events that can be read in order.
It also changes what the plant can automate later. Recipe management, batch reporting, energy monitoring and remote diagnostics all depend on the control layer being structured and documented. A line specified as a group of standalone machines can be made to report, but only by adding hardware afterwards and paying for the integration twice. Because Sailwin machines monitor 40+ parameters through the PLC in real time, the data needed for that reporting already exists inside the control system — the question is whether it is exposed in a usable form.
Precision Engineering & Core Components: turnkey bottling line step 04 shrink wrapping packing machine
2. The Layers of a Bottling Line Control System
A well-structured line has three layers, and each has a different update rate, a different audience and a different failure mode. Writing them into the specification separately prevents the most common outcome, which is a single controller doing everything badly.
| Layer | Owns | Specify explicitly |
|---|---|---|
| Machine control | Valve sequencing, filling accuracy, capping torque, its own safety chain | Processor platform, I/O count and spare capacity, cycle time of the control task |
| Line coordination | Speed references, accumulation release, start and stop sequencing, jam handling | Who owns the line stop, restart sequence, and which signals travel between machines |
| Supervisory and data | Recipes, batch records, alarms, historian, reporting, remote access | Data model, retention period, export format, and who may edit what |
Interfaces between the layers should be named in the specification rather than left to the integrator, because that is where cost and delay accumulate. Where the supervisory layer communicates with machine controllers, a defined standard such as OPC UA is a reasonable requirement, and where line equipment produces state data, structuring it to a recognised machine-state convention makes later integration with reporting systems far simpler. The point is not to demand a particular technology; it is to refuse to leave the interface undefined.
3. Recipe Management: Where Automation Actually Pays
Changeover is the clearest place to see whether a line’s automation was designed or assembled. A line with proper recipe management stores the complete parameter set for each bottle and product format in the controller: fill volumes and valve timings, capping torque targets, speeds for each zone, and the rail positions that go with them. Changing format means selecting a recipe and physically adjusting the mechanical items the recipe tells you to adjust, with the settings themselves recalled rather than re-derived.
Without recipes, every changeover reintroduces variation. Operators dial settings back to approximately what they remember, the first bottles of the run are used to fine-tune, and the process drifts with each change of shift. That is why changeover time targets are usually met on paper and missed in practice: the mechanical part of the changeover is quick, but the tuning that follows it is not measured. Sailwin filling lines are built for quick changeover, and the automation side of that promise is the recipe structure, not simply the mechanical adjustment.
Recipe management also has a governance dimension. If anyone can edit a recipe from the HMI, then the process is only as repeatable as the least careful operator on the site. Access levels, version control over recipes, and an audit trail of changes cost very little to specify and are extremely difficult to add later. For products subject to customer audits, the ability to show which recipe version produced a batch is often part of the requirement rather than an optional extra.
4. Interlocks, Safety and What Must Not Be Configurable
Automation blurs a line that should stay sharp: the difference between a process parameter and a safety function. Fill volume, capping torque and line speed are process parameters, and operators should be able to adjust them within defined limits. Guard interlocks, emergency stops and the conditions that permit a machine to move are safety functions, and they should be implemented in a safety-related control path rated to the performance level determined by the risk assessment for that machine, in the form required by the machinery safety rules of the market the line is installed in.
The failure mode this prevents is well known and entirely predictable. A safety condition written as a standard PLC logic rung and exposed on the HMI can be bypassed by anyone who has learned the password, and every bypass removes protection while leaving the machine fully operational — the most dangerous combination there is. The same applies to timed overrides: a guard bypass that expires in ten minutes still allows ten minutes of unprotected operation every time it is used.
Practical specification rules follow from this. Safety devices should be hardwired or connected through a dedicated safety network to a safety relay or safety controller, not routed through general-purpose I/O. Safety functions should not appear in the recipe screen, the parameter list or any maintenance menu. And the acceptance test should include attempting to defeat each safety function, with the results recorded — a test that proves the guard works is worth more than a document that says it exists.
If a protection can be turned off from a touch screen, it is not a protection. It is a setting, and settings get changed on the shift where output matters more than caution.
5. Data, Alarms and Remote Diagnostics
A line generates useful data constantly and discards most of it. The data worth keeping falls into three groups: process data that explains quality, event data that explains downtime, and batch data that explains what was made and when. If the specification does not ask for these to be stored, the plant will have plenty of alarms and no history, which is the least useful combination possible.
- Process data. Fill volumes or flowmeter totals, capping torque, temperatures and speeds, trended at a resolution that lets you see a drift rather than a single point. Because Sailwin machines monitor 40+ parameters in real time, the machine side of this already exists; the specification question is retention and export.
- Event data. Time-stamped stops and starts with the initiating device identified. This is what converts a line performance argument into a maintenance task.
- Batch and traceability data. Recipe version, start and end times, quantity produced and rejects by cavity or head where the machine can report it.
Remote diagnostics deserve separate treatment because they change the economics of support. Sailwin provides remote engineering support at 7×24, and its value depends on what the machine can expose. A line that can present its alarm history and current process values to a remote engineer shortens diagnosis from days to hours; a line that can only be described over the phone turns every significant fault into a site visit request. For plants in remote locations or with limited local technical depth, this is often the single most valuable automation feature on the specification.
Security belongs in the same discussion. Remote access should be permissioned, logged and switchable off, and the plant should be able to state who can reach the line’s control network from outside. This is not a reason to avoid remote support; it is a reason to specify how it works before it is enabled rather than after someone asks who has access.
6. Case Study: Two Machines and No Line Controller
A beverage plant with a filler, labeller and case packer found that line output fell short of the sum of the individual machine outputs, and that no machine’s report showed any problem.
- Machines individually meeting their rated output while line output consistently fell short
- No line-level event log, so downtime could not be attributed to any specific cause
- Recipes for different formats held in operator notes rather than in the controllers
- Line coordination layer defined: a single owner of speed references, accumulation release and restart sequencing
- Time-stamped stop and start events collected centrally with the initiating device identified
- Format recipes built into the controllers with access levels and a change record
- The lost time became visible as a sequence of events instead of a disagreement
- Changeover variation reduced because settings were recalled rather than re-derived
- Fault diagnosis moved from phone description to remote data review
Scenario based on a Sailwin customer project; site-specific figures available on request during engineering review.
7. Specifying and Accepting the Control System
The specification can be short, but it must be specific. Sailwin filling lines are built on Siemens and Mitsubishi PLC platforms with Schneider electrical components and ABB drives, and the acceptance test for the control system happens at the same time as the mechanical test — a full-load run of 24 hours before shipment, followed by installation and commissioning in 3–7 days on site.
- Name the layer that owns the line stop. Ambiguity here is the root cause of most unexplained output loss, and it costs nothing to resolve on paper.
- Require spare I/O capacity. A control panel with no spare inputs and outputs guarantees that the first additional sensor becomes a panel modification.
- Define the recipe structure and access levels. Who can create, edit and approve a recipe, and how changes are recorded.
- Specify data retention and export. Which values are logged, for how long, and in what format they can leave the system for analysis.
- Test safety functions by attempting to defeat them. Record the result. A verified interlock is worth more than a documented one.
- Simulate faults during the acceptance test. Disconnect a sensor, block a transfer and stop a machine downstream, then confirm the line behaves as specified rather than as convenient.
- Get the as-built documentation and a network diagram. Without them, the next integration project starts from an inspection rather than from a drawing.
The commercial argument for doing this properly is straightforward. Automation features that reduce changeover variation and shorten fault diagnosis pay back continuously, while features that only look impressive in a demonstration cost money once and then sit unused. Specify the architecture, verify the interlocks, and insist on the data — the rest of the control system is largely a question of which mainstream platform the supplier prefers.
Get a Control Architecture Review for Your Filling Line
Send the machine list, format range and reporting needs — Sailwin engineers return the layer structure, I/O schedule and an acceptance test plan with fault scenarios.
Industrial Machinery Assembly & Workshop: turnkey bottling line step 05 automatic bottle blowing machine
8. Frequently Asked Questions
Specify the Control Architecture Before the Components
Send your bottle drawing, container sample or target output. Our engineering team replies with a machine recommendation, mould assessment and factory-direct quotation within 24 hours.
Related Reading:
• Filling Machines: Monobloc, Isobaric, Hot Fill and 5-Gallon Lines
• Filling Line Layout Design
• Conveyor Design for Bottling Lines
• Capping Torque Control on Filling Lines
• Filling Machine Changeover Procedure
• 3-in-1 Monobloc Rinse-Fill-Cap Machines
