Can your machine concept achieve the required throughput?

A new machine often gets a number attached to it early: 60 products per minute, 120 parts per hour, or a required takt time. That number may come from the customer's business case, an existing line, a sales promise, or a first engineering estimate. The number is clear. The confidence behind it often is not.

Write the source of the number next to the number. A rate copied from an existing machine is a different claim from a rate that sales used to win the order. A first estimate from cycle-time sketches is weaker still. If the source is missing, treat the figure as a target, not as evidence.

A concept review should also split measured timings from assumed ones. A process time taken from a trial or from a similar machine can sit in the calculation with a named source. Transfer, settle, return strokes, and waiting between stations often enter as guesses. Those guesses are where a promising concept usually breaks.

The job at this stage is to decide whether the current concept deserves the next investment in engineering. Predicting the finished machine to the last millisecond is the wrong test.

Throughput is rarely decided by the headline process time alone. Products have to move, settle, queue, and leave. Mechanisms accelerate and return. Some movements can overlap. Others cannot. One slower station can force an otherwise fast machine to wait.

Take an illustrative pick-and-place cell quoted at 60 products per minute. The process station is 0.8 s. A spreadsheet that uses only that number predicts 75 per minute. Transfer, settle, and the return stroke sit outside the 0.8 s and cannot fully overlap. A longer product variant needs extra settle time. The 60/min commitment now depends on those extra timings, not on the process step that looked fast in CAD.

That example is a sketch, not a customer result. It is the kind of gap that shows up in clarification: the number on the slide was never the complete cycle. The useful output of the review is a short list of the assumptions that carry the most risk. Do not start by modelling the entire machine.

Validate those assumptions first. If transfer time, settle, or overlap cannot be bounded, more CAD detail will not make the throughput claim stronger.

Stay with the same 60/min cell. Concept A keeps one fast station. It holds 60 per minute only if transfer stays at 0.4 s. Concept B uses two slower stations in parallel. Peak rate is lower, but a longer settle time does not immediately drop the cell below the requirement. Both can be drawn to hit 60. The project risk is not the same.

Margin is the room that remains when a timing moves. Real products, mechanical tolerances, and later tuning all eat that room. A concept with almost no room can still be technically possible. It needs a different conversation with the customer and with internal stakeholders: the design has to be right first time, or the promised rate will slip.

There is no universal percentage that defines enough margin. It depends on the process, the contract, product variation, and how mature the input data is. What you need in the review is a visible gap between calculated capability and the target, not an optimistic average that hides the gap.

If two concepts both appear to meet the number, rank them by how much the result moves when the weakest assumption changes. That ranking is often more useful than a single peak-rate figure.

Early modelling is most useful when there is more than one plausible way to solve the same production problem. One concept might use a single fast station, another two slower stations in parallel, and a third a continuous process. Throughput is only one column in that comparison.

Include expected capacity, margin to the requirement, floor space, mechanical complexity, flexibility for product variants, and sensitivity to the critical timings. A model should not choose the machine. It should make those tradeoffs visible while changing direction is still cheap.

A visual behaviour model also gives people outside the design team a shared object. A CTO, customer, or steering group can watch the same flow instead of arguing from different spreadsheets and sketches. That is often the actual decision the clarification phase needs: whether to proceed with this concept, or with another one, before detailed engineering starts.

Match the evidence to the cost of being wrong. If the question is whether a mechanism is understandable and physically plausible, a calculation, a layout review, or a clear animation can be enough. If a throughput commitment depends on overlapping movements, buffers, or several stations that affect each other, a dynamic behaviour model gives stronger evidence.

Stop when the current decision is supported. An early model does not have to become a full digital twin or a virtual commissioning project unless the next question needs that extra fidelity. Building too much, too early, turns a cheap clarification into a simulation programme that still cannot answer the original go/no-go.

Keep the four levels separate in the project file: target, calculated capability, validated concept, built-machine performance. Mixing them is how a spreadsheet average gets presented as if the machine had already run.

A spreadsheet is enough when the process is mostly sequential, the timings are known, and there are few interactions. Building a 3D model to add three fixed operation times costs time without changing the decision.

A dynamic model earns its place when important assumptions interact: motions overlap, products accumulate, a buffer changes the flow, alternative concepts need comparison, or the physical layout affects timing. Seeing the complete behaviour can show a starvation or blockage that isolated calculations miss.

For long production horizons, shift patterns, random stops, and statistical variation across a whole hall, a discrete-event tool such as Siemens Plant Simulation is usually the better instrument. Unity-based models, and tools such as Visual Components or realvirtual, are stronger when the question is spatial and mechanical: can this layout, this transfer, and this product size keep the rate. Choose the smallest method that reduces the uncertainty behind the decision you are making now.

If the concept has credible margin and the main assumptions are named, the project can move into detailed engineering with clearer risks. The model may have done its job. Stopping is a valid outcome.

If the project still needs more certainty, refine the same concept with better geometry, measured timings, and more realistic behaviour. Later, when the question becomes whether the actual automation software controls the chosen machine correctly, the work moves into virtual commissioning. That is a different decision, with different evidence.

Holding those stages apart keeps a small feasibility question from becoming a large simulation project too early. It also makes it clear what each stage has actually proven, and what still waits for the physical machine.