Machine Tending: One Robot Serving Several Machines

Table of Contents

Direct answer: In machine tending with one shared robot, arm speed is rarely the constraint. The arm is fixed, so machine spacing, orientation and load-port height decide whether every station is reachable at all. After that the machines set the pace, because a faster arm still waits for a cut to finish, and the guard fence decides how people continue to reach the parts.

Video overview of the application context. The footage supports process observation, not model-specific performance, safety, or acceptance claims.

Who this is for: This guide is written for production engineers and plant managers considering one robot to serve two or more machines, where the business case rests on sharing a single arm across several existing machines.

Scope: It covers how machine layout, waiting behaviour and fenced access decide whether a shared arm is viable, and what each judgement still owes in evidence. It does not cover gripper design detail, machine retrofit electrics, or the cutting process inside the machines.

Six-axis industrial robot inside a guard fence transferring a metal part between two production machines
Six-axis industrial robot inside a guard fence transferring a metal part between two production machines

Why robot speed is rarely the constraint

Sharing one robot across several machines is an attractive case, and the arithmetic is easy to like: one arm amortised over two or three machines instead of one. That is usually where the enquiry starts, and it is usually the wrong place to test the idea.

In the reference footage the arm moves between two machine positions inside a guard fence, taking and placing a part at each. What the sequence shows most clearly is not motion but pause: for much of the cycle the arm is waiting, because the machines are working and there is nothing for it to do.

That is the normal condition in machine tending, and it reframes the question. The useful questions are whether the arm can reach every station, who waits for whom when requests collide, and how people still get to the machines once a fence surrounds them.

According to ISO 10218-2:2025, the assessment applies to the robot application rather than to the robot alone, which matches how these cells fail commercially. They rarely fail because the arm was slow. They fail because a machine could not be reached, because two machines finished together, or because a routine task became a fenced-entry procedure.

Reach comes before cycle time

A fixed arm has a fixed working volume, and every machine it serves has to place its load port inside that volume in a pose the gripper can actually use. Spacing, orientation, door swing and port height all enter the same check, and so does whatever else stands in the way: chip conveyors, coolant tanks, control cabinets, pallet positions.

This is why machine layout for machine tending cannot be settled first and handed over afterwards. In an existing shop the machines are usually already placed, and the honest outcome of the reach check is sometimes that one of them has to move, or that the shared-arm idea only works across two of the three machines under discussion.

In practice a reach check done on a layout drawing with the real gripper envelope resolves most of this in an afternoon, and it is the one step that cannot be recovered later. If a station cannot be reached, no arm on the shortlist changes that, and no amount of programming does either.

Decision path from machine layout and robot reach through waiting behaviour and fence access to buffer and fault handling
Reach is settled first, waiting second; access is what decides whether the cell is liveable.

The machines set the pace

Once reach is settled, the waiting behaviour decides the value of the cell. Where machine processing is long relative to load and unload, the arm is idle for most of the cycle and a faster arm buys nothing. Where processing is short, the arm becomes the bottleneck and the case for sharing it weakens.

The awkward middle case in machine tending is machines with similar processing times, because their requests arrive together. Then the cell needs a queueing rule and somewhere to put a part that has nowhere to go yet. That is a buffer and sequencing question rather than a robot question, and it is answered with a table of processing, load and unload times rather than with a specification sheet.

According to ISO 13849-1:2023, safety-related parts of a control system are designed to a performance level derived from the assessed risk, which is why the interlock scheme between the arm and each machine belongs in this discussion rather than in commissioning. Writing that table is the fastest way to test a shared-arm proposal. It usually shows either that the machines are complementary enough to share an arm comfortably, or that they collide often enough that the cell needs buffers, which changes the cost and the floor space the proposal assumed.

Decision table: what a shared-arm layout justifies

The table maps what a layout and a set of processing times can justify on their own against the evidence a supplier still has to produce.

What the layout justifies, and what still has to be proven
Evidence from the application Selection it justifies Evidence you still owe
Long machine processing, short load and unload, stable part mix One shared arm serving the group, sized on reach rather than on speed Reach check at every load port with the real gripper, and a collision review with doors open
Similar processing times across machines, frequent simultaneous requests A shared arm plus buffer positions and an explicit queueing rule A timing table covering processing, load, unload and allowed waiting per machine
One machine outside the working volume of any acceptable arm position Either relocating that machine or excluding it from the shared group Layout study with the relocation cost stated, and the reduced case recosted
Frequent manual intervention at the machines each shift Access design before arm selection, since fenced entry changes routine work An entry procedure with the stop and restart conditions, and a count of entries per shift

Once the fence goes up, access changes

In the footage a guard fence encloses the arm and the machines it serves. That boundary is required, and it also changes daily work in a way that rarely appears in the business case. Loading bar stock, changing an insert, clearing chips and checking a dimension were casual actions before the fence; afterwards each one passes through a door and a stop.

According to ISO 12100:2010, risk reduction begins at the design stage rather than at the guarding stage, and access is exactly the kind of question that framing is meant to catch. Deciding which tasks stay outside the fence, which need entry, and how long a machine is down for each entry belongs in the layout discussion, not after installation.

It is worth being concrete about this during selection, because the answers differ so much between shops. A cell entered twice a week and a cell entered several times a shift look identical on a layout drawing and behave nothing alike, and the difference usually decides whether operators end up working with the cell or around it.

What the footage proves and what it does not

The reference footage proves a visible process. One six-axis arm works inside a guard fence between two machine positions, transferring parts with a gripper, with a parts rack and control cabinet in the enclosure. Those are observable facts about the operation.

It proves nothing about cycle time, utilisation, throughput or the payback the shared arm produces. Those depend on processing times and part mix at your own machines, and no video supplies them. EVST states that boundary explicitly so that a quotation is compared on the same evidence rather than on impressions.

That separation also makes the remaining work visible. What is left after the footage is a reach check, a timing table and an access plan, and those three deliverables are what a serious proposal for a shared arm should contain before any acceptance criteria are agreed.

What to put in the enquiry

State the machines: type, load-port position and height, door behaviour, and whether each can supply the signals a shared arm needs. Add processing, load and unload times per machine, and the part mix that runs across them. This is also the point at which the wider automation route matters, because a shared arm sits next to other options such as robot machine tending overview cases, dedicated loaders, or automatic welding system solutions on the fabrication side.

Then state what the supplier still has to prove: a reach check at every load port with the real gripper, a timing study covering simultaneous requests, and an access plan with entry frequency and stop conditions. Add the floor plan with the obstructions drawn in, since a shared arm competes for space with chip conveyors, coolant tanks and pallet positions, and note whether a collaborative robot range is being considered as an alternative to a fenced cell, because that changes the access answer completely.

Frequently asked questions

How many machines can one robot serve?

There is no general number. It depends on whether every load port sits inside one working volume, and on how often the machines request the arm at the same time. Two machines with long, complementary processing can share an arm comfortably; three with similar short cycles often cannot.

Does a faster robot improve the cycle?

Usually not. Where machine processing is long relative to load and unload, the arm already waits, and a faster arm simply waits longer. Speed only matters once the arm is the bottleneck, which is the case that weakens the argument for sharing it.

What changes once we fence the cell?

Routine tasks become fenced-entry tasks. Loading stock, changing tooling, clearing chips and checking dimensions all pass through a door, and each entry stops the arm and often the machines. Counting those entries per shift during selection avoids a cell that people work around.

Does the footage show what utilisation we would get?

No. It shows an arm transferring parts between two machine positions inside a fence. Utilisation and payback depend on your own processing times and part mix, and both have to be calculated from those rather than read from a video.

Project inputs for an application review

Send the following and the shared-arm case can be checked rather than estimated:

  • the machine list with load-port position, height and door behaviour
  • processing, load and unload times per machine, and the part mix across them
  • the floor plan with obstructions, cabinets and pallet positions drawn in
  • the interface signals each machine can supply, and which need retrofitting
  • how often people need to reach the machines during a shift, and what for

If you are considering one robot across several machines, send the machine list with load-port geometry, the processing and handling times, the floor plan with obstructions, the available interface signals, and how often operators need to reach the machines. The proposal can then be tested on reach, waiting and access rather than on arm speed. Related reading: automatic welding system solutions, collaborative robot range.

Awesome! Share to:

EVST logo
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.