Faster code may not make a faster machine
A training cell produces one tray every twelve seconds. Its PLC task takes two milliseconds. You shorten an expression and save a few microseconds. The tray still leaves every twelve seconds because a clamp waits for a slow mechanical return.
Improvement begins by deciding what you are measuring. Controller execution time, actuator response, process dwell, queueing, and complete production cycle time are different quantities. Changing one may have no useful effect on another.
Our example is a two-station line: Station A fills a tray in six seconds, Station B inspects it in eight seconds, and transfer takes one second. The first task is to draw the timeline rather than optimize a loop.
Define the event boundaries
Choose a cycle definition that matches the question. For a single station, cycle time might run from accepted part to completed processing. For line throughput, measure the time between successive completed good units over a defined observation period. Startup and shutdown can distort a short sample.
Give events precise names: PartAccepted, FillComplete, TransferAccepted, InspectionComplete, and GoodPartReleased. Record identifiers so that events from different trays cannot be accidentally combined.
Tray 104:
Accepted at A 00.000 s
Filling complete 06.000 s
Transfer accepted 08.300 s
Received at B 09.300 s
Inspection complete 17.300 sThe tray spent 2.3 seconds waiting after filling. That waiting may be the correct consequence of Station B being busy. It is not automatically a wasted timer in Station A.
Find the limiting resource
If both stations operate concurrently with sufficient buffering, the slower repeated operation tends to constrain sustained throughput, with transfer and coordination details affecting the actual result. Do not simply add every duration if operations overlap. Do not assume perfect overlap if they share a clamp, robot, operator, or transport zone.
Draw each resource on its own timeline. Mark active work, waiting for material, waiting for capacity, planned dwell, and faulted time. The picture often reveals the bottleneck before any statistics do.
For our model, reducing filling from six seconds to five does little while inspection still occupies its resource for eight. Reducing inspection to seven may help, but only if process quality remains acceptable and the transfer arrangement can supply it. The programmer cannot unilaterally shorten a validated curing or inspection requirement because it looks like a delay.
Classify waiting by cause
“Idle” is too broad. An idle station may be starved of incoming work, blocked by downstream capacity, waiting for an operator, completing a required dwell, or recovering from a fault. These categories suggest different improvements.
Use mutually defined reason priorities when several conditions exist together. Otherwise one minute can be counted as both blocked and faulted, making reports impossible to reconcile. Keep the raw events so that the classification can be audited or revised.
| Observed delay | Useful question | Possible investigation |
|---|---|---|
| Starved | Why did work not arrive? | Upstream cycle and transport |
| Blocked | Why was capacity unavailable? | Downstream service and buffer |
| Actuator waiting | Was the movement slower than expected? | Feedback trace and mechanism |
| Required dwell | Is this duration a process requirement? | Process owner and evidence |
| Communication waiting | Which transaction was outstanding? | Identifier, age, acknowledgement |
Avoid inventing a “PLC delay” category for every period the engineer cannot yet explain.
Use distributions, not one impressive cycle
Record several representative runs, including different products, loads, and operating conditions. Report sample size, observation window, exclusions, and uncertainty. A minimum cycle demonstrates what happened once; it does not describe dependable production.
Compare medians and slower tails when variability matters. A station with mostly six-second cycles and occasional thirty-second recoveries may have a worse production impact than a consistent seven-second station. Keep fault and recovery periods visible instead of deleting them to make a chart attractive.
For model exercises, control one source of variation at a time. Add a variable inspection duration, then add transfer delays, then add failures. Learn which behavior changes the average, which enlarges queues, and which causes occasional long gaps.
Know what an OEE number cannot tell you
Overall equipment effectiveness is commonly expressed as availability multiplied by performance multiplied by quality. The arithmetic is simple; definitions determine whether the result is meaningful. Agree planned production time, downtime treatment, ideal cycle time, total count, and good count before calculating.
As a worked example, suppose the agreed planned production period is 480 minutes, operating time is 420 minutes, total production is 3,000 units, ideal cycle time is eight seconds per unit, and 2,850 units meet the agreed quality criterion. Availability is 420/480 = 0.875. Performance is 24,000/25,200 ≈ 0.9524. Quality is 2,850/3,000 = 0.95. Their product is approximately 0.792, or 79.2%.
That number does not identify a root cause. It also does not measure profit, energy efficiency, worker safety, or whether the chosen ideal cycle is valid. Comparing two machines with different definitions can be misleading. Preserve the underlying losses and event records; the headline percentage is a prompt for investigation, not the investigation itself.
Improve one constraint and predict the consequence
Suppose traces show the model inspection station finishes processing but waits 0.8 seconds for an unnecessary polling handshake before release. Propose an event-based transaction with an acknowledged result, and predict which timestamps should move closer together.
Test the revised interface under delay, duplicate messages, and interruption. Faster happy-path behavior is not an improvement if it loses product identity during a restart. Keep the correctness criteria from earlier chapters while adding a performance target.
After the change, measure the same workload under the same declared conditions. If the bottleneck moves to transfer, that is useful information. It means the system changed; it does not justify continuing to optimize the old bottleneck by habit.
Try it
A line reports 100 completed units in a twenty-minute sample. Station A takes four seconds per unit, Station B takes seven seconds, and transfers take one second. The supervisor asks you to make A twenty percent faster. What evidence would you gather before agreeing that this will improve output? Give one case where it helps and one where it does not.
Work through the answer
First determine whether stations overlap, which resources are shared, and where the missing time goes. One hundred units in 1,200 seconds gives an observed average of twelve seconds per completed unit, much slower than either station's nominal processing duration. Faults, starvation, blocking, changeovers, or non-overlapping operation may explain it.
Making A faster helps if A's actual service or repeated interruptions are starving B, or if the line is deliberately sequential and A lies on every critical path. It may not help if B is continuously busy while a queue already waits upstream. In that case A would merely spend more time blocked.
Build an event trace, classify the loss, and write a prediction before changing code. Then use the complete design exercises beginning with the transfer conveyor to practice balancing correctness, recovery, and useful performance.