A sample tray is easy to move. Its identity, test status, priority and recovery history are much harder to carry safely in someone’s head. In a busy quality laboratory, that invisible work follows every handoff: storage to trolley, trolley to instrument, instrument to result folder. One missed state can leave a technician staring at a specimen and asking whether it is waiting, finished or already failed.

The useful job for automation is to hand that context forward with the tray. For a laboratory choosing a system integrator Singapore manufacturers can work with, ask whether the finished system makes sample state obvious, keeps test records attached to the right work and gives people a clear way to recover when a handoff breaks. The robot’s appearance says very little about any of that.

Motionwell Automation’s P23078 laboratory project shows what that requirement looks like in hardware. It connects a MiR autonomous mobile robot, a Universal Robots cobot, a 70-position storage rack and multiple Instron testing stations. Transport, test commands, file naming and exception handling belong to one controlled workflow; none of the machines gets to treat the handoff as somebody else’s problem.

Manual handoffs create invisible memory work

Manual handling is often described as a time problem. That is only part of it. A technician also has to remember why the sample moved, which test recipe applies, whether the instrument has been reset, where the result should be filed and what to do if the machine refuses the run. The tray may travel one metre while the context travels through a handwritten note, a spreadsheet, a conversation and someone’s memory.

Count decisions instead of counting footsteps

Imagine a technician collecting three specimens for tensile, compression and flex testing. One has priority. Another was returned after a setup error. The third is clean but waiting for a station. Walking them across the room is simple. Keeping those histories separate while answering a colleague, checking an instrument and preparing the next batch is the demanding part.

A sensible automation brief therefore counts decisions and handoffs. Who assigns the station? What state appears when the sample is moving? Can the technician tell the difference between a delayed test and a failed one? Where does a retry begin? These questions expose workload that a stopwatch misses.

Make every sample state explicit to technicians

In Motionwell Automation’s lab architecture, the scheduling layer can track a sample through queued, in-transit, at-station, in-test, completed and failed states. That sequence matters because it gives the sample one visible status at a time. A person does not have to reconstruct the story from where the tray happens to be sitting.

The 70-position rack also has a practical role beyond storage density. Slot tracking links a physical location to the schedule. Priority management can decide which sample moves next, while the mobile robot handles transport between the rack and test stations. The technician can then focus on whether the method and result make sense instead of acting as the room’s memory system.

A closed loop needs more than transport

Moving a specimen to a machine does not complete a test. The receiving station has to be ready, the correct parameters must be applied, the test must start under a known state and the resulting file must return to the right record. A robot that stops at the instrument simply moves the manual handoff to a new location.

Connect the instrument commands and result file

The P23078 example includes bidirectional communication with Instron test equipment. The control system can handle actions such as zero reset, speed setting and the start trigger. When the run finishes, controlled naming can combine the sample identity, test type and timestamp before the file is uploaded to network storage.

That naming step deserves attention. A result called “test-final-2” creates another memory task and another chance to attach evidence to the wrong specimen. A controlled name is less glamorous than a moving cobot, but it helps a later reviewer understand what was tested and when. In a quality setting, the dull parts often protect the whole chain.

Give the robot a precise handoff

A mobile base, a cobot arm and a test fixture each bring their own positioning tolerance. Motionwell Automation describes a layered approach: the AMR navigates to the station, the cobot reaches toward the handoff point and wrist-mounted vision compensates for the remaining offset before gripping or placement.

This matters for the person supervising the cell. “The robot missed” is too vague to support recovery. A good system separates navigation, arm position and final visual correction, so the team can see which layer needs attention. Clear boundaries reduce guesswork and make repeated faults easier to discuss with engineering support.

Recovery design protects human attention during failures

A lab gains little from automation that only behaves well on a clean run. Failures need to be legible. A sample may sit incorrectly in a rack, an instrument may reject a command, a gripper may not confirm pickup or the network may interrupt a file transfer. Each event needs a bounded response.

Use prompts and safe holds deliberately

The laboratory system described by Motionwell Automation includes verified retry logic, operator prompt sequences and safe-hold states. Those controls do not remove the technician. They give the technician a defined point of entry when the automatic path cannot continue.

A useful prompt says what the system knows, what it could not confirm and which action is permitted next. A safe hold prevents motion or state changes from racing ahead while a person investigates. Together, they keep an exception from turning into several uncertain samples and several half-finished files.

Review the exception before restarting flow

Teams should test recovery during acceptance, not wait for the first awkward production shift. Place a specimen slightly out of position. Interrupt a mission. Refuse a test start. Temporarily block the result upload. The aim is not to prove that nothing fails; it is to see whether the system preserves identity, explains the stop and returns to a known state.

Run that drill with the technicians who will supervise the cell. They are more likely to trust automation when they can predict what it will do after an error. Mystery creates vigilance of the wrong kind: people hover over the equipment because they do not know whether it can stop safely or remember unfinished work.

Record what happens after the retry as carefully as the original stop. The sample should not silently return to a clean state, and the first failed attempt should not disappear from the trail. A later reviewer needs to see both the interruption and the authorised recovery that followed it.

Know which decisions automation cannot safely make

Automation can move samples, apply configured commands and preserve a state trail. It cannot decide whether a questionable result is scientifically credible, whether a method remains appropriate or whether a failed specimen should be retested. Those judgements still belong to qualified laboratory staff operating under their approved procedures.

Keep exceptions visible to the technician

Motionwell Automation is most relevant to laboratories that need custom equipment, instrument communication and sample logistics to behave as one system. A smaller lab with low volume and stable manual control may not need that scale of integration.

The better test is simple: after a stop, can the technician see what happened, where the sample belongs and what action is safe? If the answer depends on memory or a private spreadsheet, the automation is incomplete. When state and recovery remain visible, the machinery can take the repetitive movement while people keep the scientific judgement.

Amelia Hart, a psychology graduate from the University of Hertfordshire, has a keen interest in the fields of mental health, wellness, and lifestyle.