Different boxes, one promise to test
A production manager needs to ship different boxes on one pallet. A video shows a very fast robot, but the useful question is different: will it finish our work within the shift, including every grip, wait and changeover? This article shows how to test that promise before comparing quotations. The result is an understandable threshold: how long can an average cycle take without missing the required output?
The analysis uses an entirely imaginary factory, three box types and arithmetic executed in Python. We tested no robot, gripper or vision system. Times, availability and costs are teaching assumptions, not measurements or prices. A project can look economical on a cost sheet yet lack capacity after just one extra second per cycle. That is a consequence of the stated model, not an observed industrial performance.
What a cycle must represent
Palletizing means arranging packages on a platform for handling. The gripper holds the package; a recipe defines a work configuration. To compare proposals, first fix the same boundary: a cycle starts when the machine is ready to pick and ends when it is ready for the next package. Comparing outward travel alone with a complete cycle artificially favors the former proposal.
Our cycle includes gripping, transfer, placement and return. Recurring waits belong either here or in deductions from available time, never both. Format changes are separate. We are not designing trajectories; we are building a time budget to populate with real measurements. A consistent budget does not make an incorrect assumption realistic; it makes clear which assumption needs measurement.
Before counting seconds, a logical condition comes first: every planned box must be movable in the proposed configuration. Mass, dimensions, surface and position affect gripping. Universal Robots’ consulted Maximum Payload section distinguishes tool and workpiece mass, center of gravity and inertia: kilograms alone do not describe an application. We take no limits from that page to apply to an imaginary robot.
Why the average must follow the boxes
Suppose five of every ten boxes are A, three B and two C. Assumed complete cycles take 6, 10 and 14 seconds respectively. The arithmetic mean of these three numbers is 10 seconds, but that answers a different order: equal quantities of each type. For our order, first count all ten boxes: 30 plus 30 plus 28 equals 88 seconds. Dividing by ten gives 8.8 seconds per box.
The next formula answers exactly: how long does an average box in this order require? Let pᵢ be the fraction of type i, dimensionless, and tᵢ its complete time in seconds per box. Fractions must sum to one. They are not probabilities estimated experimentally: here the author fixes the mix to make the calculation verifiable.
In words, each time is weighted by how often it is actually needed. For 2,400 boxes, the exact mix is 1,200 A, 720 B and 480 C, requiring 21,120 seconds. Order does not affect this calculation only because we assume sequence-independent times. If A→C requires a tool change or recipe adjustment, that transition cost belongs in the model: the average alone is insufficient.
An eight-hour shift is not eight productive hours
Set shift H to 28,800 seconds, or eight hours. Assume fraction a=0.85 is available before format changes, then separately subtract S=1,200 seconds for those changes. Productive time T becomes 23,280 seconds, or six hours and twenty-eight minutes. The 85% availability was not observed: replace this input with plant data. Defining it before changeovers avoids deducting the same stop twice.
Dividing available time by average time gives an equivalent continuous capacity of about 2,645.45 boxes. Fractional shipped boxes do not exist: this is not a simulated count of completed cycles. The integer count depends on the final sequence and pallet constraints. To test our 2,400-box order, no rounding is needed: compare its required 21,120 seconds directly with the available 23,280, leaving 2,160 seconds of model margin.
This budget is necessary, not sufficient. If every box arrives in the final twenty minutes, the same daily quantity cannot be processed in the same way. A shift can have enough total capacity yet miss a shipping window. Here we assume regular box availability and no intermediate deadlines. A real order needs arrival times and deadlines, not just a daily total: use a time-based simulation or a verified plan, not another rounding operation.
The second that changes the decision
Now suppose grip confirmation and release together need one additional second per box beyond the times already included. We do not claim this happens with any particular gripper. This is sensitivity analysis: change one assumption, keep the others fixed, and see how fragile the conclusion is. Average cycle time rises from 8.8 to 9.8 seconds; required work becomes 23,520 seconds, leaving a 240-second shortfall within the shift.
Instead of arguing whether one second seems large or small, derive the threshold from demand. N is the required box count, here 2,400. If N times the average cycle must not exceed T, dividing by positive N gives the maximum compatible cycle. Here it is 9.7 seconds per box. The initial cycle has only 0.9 seconds of headroom. Discuss this quantity with the system supplier, together with the conditions under which it should hold.
| Extra seconds/cycle | Mean cycle (s) | Continuous capacity (boxes) | Compatible (1/0) |
|---|---|---|---|
| 0 | 8.8 | 2645.45 | 1 |
| 1 | 9.8 | 2375.51 | 0 |
| 2 | 10.8 | 2155.56 | 0 |
In the figure, demand stays at 2,400 boxes; bars show equivalent continuous capacities, not machine observations. The first bar exceeds the line, the other two do not. The decisive step is comparison with demand, not the appearance of the tallest bar. In the table, 1 means compatible with the time budget alone and 0 means incompatible. Neither value certifies physical handling or safety.
An average changes when the order changes
The 50/30/20 mix is not a robot property; it belongs to the required workload. If every box were C, the assumed cycle would be 14 seconds and continuous capacity would fall to about 1,662.86 boxes in the same productive time. No invented breakdown is needed to lose the advantage: a different order is enough. Testing only the easy format therefore does not validate a mixed-box promise. Coverage of the required combinations matters.
A fuller model writes total time as the sum of individual box cycles plus transitions between consecutive types. If transitions are directional, A→B differs from B→A. Grouping formats may reduce changes but violate shipping order or pallet layout. The problem becomes constrained scheduling. We have not solved that scheduling problem and do not attribute an optimizer to our small program when it contains none.
When economics says yes and the shift says no
Only after capacity do we introduce an educational cost comparison. Assume monthly fixed cost F of €4,500 for the robotic solution, variable cost v of €0.03 per box, and avoidable manual cost m of €0.18 per box. Every number is invented; F is not an arm price, and m is not automatically a wage saving. The boundary must include what genuinely changes between comparable alternatives.
The formula asks: with these costs alone, at what monthly volume do the accounts match? For n boxes, robotic cost is F+vn and manual cost mn. Equating them and collecting n gives F/(m−v), provided m exceeds v. Here break-even is 30,000 boxes per month. If m were no greater than v and F positive, increasing volume would not recover the fixed cost in this model. The mathematical condition prevents a false promise of scale.
Across twenty-two identical assumed shifts, demand is 52,800 boxes and costs are €6,084 versus €9,504 monthly. The arithmetic difference is €3,420, not a demonstrated saving. With the extra second, monthly demand still exceeds break-even, but each shift lacks capacity. Applying the unit cost to every box anyway buys capacity that the model does not provide. A different organization, more time or another design would be needed, with costs recalculated.
A real quotation should separate purchase and financing, integration, tooling, maintenance, energy, support and remaining labor. Do not add the full purchase to depreciation for the same period. Staff may be reassigned rather than removed: the value of work changes, not necessarily cash spending. We lack data to quantify that. Damaged products or rebuilding a pallet consume time and money; excluding them from both columns is an explicit boundary, not proof they are negligible.
Compare alternatives that solve the same problem
A non-AI alternative might use fixed box presentation, code-based identification and deterministic recipes. Another might improve packaging or the manual station layout. AI vision becomes an interesting hypothesis when variability remains that those solutions handle inadequately; assess final outcomes, not image recognition alone. Our budget does not prove AI necessary: it helps establish how much time any solution may consume.
A larger robot is not an automatic answer either. A different tool can change clearance and timing; a different layout may shorten travel while complicating supply. The consulted Robotiq guidance includes jaw-opening space and actual gripping and release times in cycle assessment. We do not adopt its settings as universal instructions: comparison must remain specific to the offered configuration and the integrator’s verification.
What a real trial must establish
To move from arithmetic to a decision, we propose—but have not executed—a protocol: record each box type, start and end times, pallet position, outcome and intervention reason. Keep stops, changeovers and waits separate with nonoverlapping definitions. Collect a whole representative order, including agreed unfavorable conditions. Measuring only ten successful cycles and discarding everything else would not estimate the required work.
The mean serves total workload; long cycles and event order serve deadlines. Reporting both reveals whether a proposal has little margin or depends on a favorable distribution. Our example produces no confidence intervals because it contains no randomly sampled measurements. Multiple real shifts would require analysis of mix variation and event dependence. Inventing a statistical interval around author-chosen numbers would add apparent precision, not evidence.
Final answer and reproducible code
For our imaginary order, the opening question has a precise, limited answer: the time budget admits 2,400 boxes only if average cycle time does not exceed 9.7 seconds under the stated conditions. The 8.8 assumption passes; 9.8 fails despite favorable-looking break-even economics. This supports asking for targeted verification before investment, not approving a system. Gripping, pallet stability, dynamics, collisions, safeguards and compliance remain outside the model and need their own verification.
EL-AI considers robotics a direction to explore: this article documents no company product, trial or installation. The following code reproduces educational arithmetic only. Decimal preserves the stated decimal inputs; assertions check the mean, useful time, threshold and change in outcome. Complexity is linear in the number of types for the mean and in scenarios for sensitivity; no trajectory search is included. Exported results explicitly distinguish assumptions from absent measurements.
Universal Robots — Maximum Payload, SW10.8, full section; accessed 30 October 2026.
"""Invented workload arithmetic, not robot dynamics or hardware measurements."""
import json,sys
from decimal import Decimal as D
from pathlib import Path
# Each cycle includes assumed grip, travel, release and return, in seconds.
cycles={"A":D("6"),"B":D("10"),"C":D("14")}
weights={"A":D("0.5"),"B":D("0.3"),"C":D("0.2")}
assert sum(weights.values())==1
mean=sum(weights[k]*cycles[k] for k in cycles)
horizon=D("28800") # 8 hours
availability=D("0.85") # assumed fraction of planned time available for work
changeovers=D("1200") # excluded from available work time, once
productive=horizon*availability-changeovers
assert productive>0
capacity=productive/mean
required=D("2400")
max_cycle=productive/required
# Consequence of an extra second of grip/release on EVERY box.
sensitivity=[dict(extraSeconds=str(e),meanCycleSeconds=str(mean+e),capacityBoxes=str(productive/(mean+e)),meetsDailyDemand=productive/(mean+e)>=required) for e in [D(0),D(1),D(2)]]
assert mean==D("8.8") and productive==D("23280") and max_cycle==D("9.7")
assert sensitivity[0]['meetsDailyDemand'] and not sensitivity[1]['meetsDailyDemand']
# Monthly comparison on the SAME demand. Prices invented, not a vendor quote.
fixed=D("4500"); manual=D("0.18");variable=D("0.03")
threshold=fixed/(manual-variable)
monthlyDemand=required*D(22)
assert threshold==30000 and monthlyDemand==52800
assert required*mean==21120 and productive-required*mean==2160
assert required*(mean+1)-productive==240
assert (manual*monthlyDemand)-(fixed+variable*monthlyDemand)==3420
allC=productive/D('14')
result=dict(allCContinuousCapacity=str(allC),python=sys.version.split()[0],scope="Synthetic deterministic arithmetic only; no robot, gripper, simulation of trajectories, safety validation, human timing, measured uptime, vendor quote or measured saving",cycleSeconds={k:str(v) for k,v in cycles.items()},mix={k:str(v) for k,v in weights.items()},meanCycleSeconds=str(mean),shiftSeconds=str(horizon),availabilityAssumed=str(availability),changeoverSeconds=str(changeovers),productiveSeconds=str(productive),requiredDailyBoxes=str(required),maxMeanCycleSeconds=str(max_cycle),sensitivity=sensitivity,economics=dict(fixedEuroPerMonth=str(fixed),manualEuroPerBox=str(manual),robotVariableEuroPerBox=str(variable),continuousBreakEvenBoxesPerMonth=str(threshold),demandBoxesPerMonth=str(monthlyDemand),robotEuroPerMonth=str(fixed+variable*monthlyDemand),manualEuroPerMonth=str(manual*monthlyDemand),warning="Economic threshold is not sufficient: extra one-second cycle violates daily capacity. Manual unit cost must mean actually avoidable cost, not wage automatically saved. Static screening is separate and does not establish any feasible robot."))
Path(__file__).with_name("results.json").write_text(json.dumps(result,indent=2),encoding="utf8")
print(json.dumps(result))
Code, data, and instructions · JSON. Educational calculations executed with Python 3.14.0; figures with Matplotlib 3.11.2. AI-assisted analysis, without claiming peer review or human review. Original illustrative ImageGen cover: it does not document EL-AI people, premises, or installations. Sources accessed 30 October 2026.