Skip to content

Search these docs, or ask Revo a question — answers link the pages they came from.

PF400 with Rail

The PF400 — Brooks Automation’s PreciseFlex 400 — is a four-axis laboratory robot built around a tall vertical column, which is what makes it useful on a crowded bench: the work envelope is a column rather than a dome, so stacked instruments, hotels and shelves are reachable from a small footprint. Revolution drives it standalone and mounted on Brooks’ linear rail, where the added axis lets one arm serve instruments spread along a bench.

The line originated with Precise Automation, which Brooks Automation announced it was acquiring on 26 April 2021. It is published today as a Brooks Automation product, on brooks.com — not under Azenta, which is the separate life-sciences business that took the Azenta name after the Brooks group split. If you are looking for the current datasheet, look for “PreciseFlex 400”, not “Precise Automation PF400”.

AxesFour
Vertical (Z) travel400, 750 or 1,160 mm
Payload0.5 kg with Servo Gripper
Repeatability±0.090 mm
Typical speed at TCP500 mm/sec
Linear rail1.0, 1.5 or 2.0 m travel, up to 700 mm/sec, ±0.05 mm repeatability
Revolution controlPlate transfers, scheduled through Revolution’s transfer system

Brooks publishes the following for the PreciseFlex 400.

Payload, repeatability and typical TCP speed are given in At a glance above. Brooks additionally publishes:

Maximum acceleration2000 mm/sec²
Servo gripper23 N

The 0.5 kg payload is the specification to check a workflow against before anything else. It is a small number, and a filled deep-well plate with a lid is a great deal heavier than the empty microplate a cell is usually demonstrated with. Payload is not a figure to establish empirically on a live deck.

JointRange
Joint 1 (Z)400, 750 or 1,160 mm, depending on the column ordered
Joint 2±93°
Joint 3±168°
Joint 4±960° with Servo Gripper

The Z column length is chosen at order time and cannot be changed later, so it constrains the cell layout permanently — the tallest thing the arm has to reach into has to be inside the column travel.

Brooks publishes two different pairs of horizontal-reach figures for the same robot, and they do not agree. The product page gives 433 mm (standard) and 588 mm (extended); the PreciseFlex 400 datasheet gives 579 mm (standard) and 734 mm (extended), in both cases “with included Servo Gripper”. We have not reconciled the two — confirm the reach of the exact configuration you are quoting with Brooks before you commit a deck layout to it.

Travel options1.0, 1.5 and 2.0 m
SpeedUp to 700 mm/sec
Repeatability±0.05 mm

Brooks states the optional linear rail extends the robot’s horizontal reach up to 2 metres. On a long bench this is the difference between one arm and two.

Communications100 Mb Ethernet, TCP/IP and EtherNet/IP
Operator interfaceWeb-based
Digital I/O12 inputs, 8 outputs at the base of the robot
Power90–264 VAC auto-selecting, 50–60 Hz; 100–250 W typical operation
ProgrammingGuidance Programming Language (GPL) and the TCP Command Server (TCS)

Brooks also publishes a design life of 40,000+ hours for the PreciseFlex range.

Brooks describes the PreciseFlex robots as collaborative, states they are “the fastest collaborative robots available, while meeting the collaborative robot safety standards”, and states they offer high throughput with low collision forces. Brooks does not, in the material we could verify, publish the specific standard numbers, the measured force limits, or a statement that guarding can be omitted.

So treat the collaborative claim as what it is: a property of the arm, not a clearance for your cell. A risk assessment of your own installation is still required — the neighbouring instruments, the labware, the operator’s working posture and the rail travel are yours, not Brooks’. A rail-mounted arm in particular sweeps a much larger volume than the same arm on a fixed base, and the pinch hazards along the rail are part of the cell, not part of the robot.

The PF400 is a mover, and movers are not driven by device operations. Revolution schedules plate transfers and the mover executes them through the transfer system, in the same way as the Thermo Orbitor and Stäubli arms. There is no “move plate” operation to call from a method — you describe where labware needs to be, and the scheduler works out the moves. The PF400 driver exposes no device operations at all.

Revolution recognises six PF400 devices, across two driver generations:

DeviceRailNotes
PF400 Robot GenericNoThe arm on its own base
PF400 1160 XR (0°) – 2m Track2 mRobot mounted on the carriage at 0°
PF400 1160 XR (-90°) – 2m Track2 mRobot mounted on the carriage at −90°
PF400 Robot 1160 XR NGNoNewer-generation driver, RevoWeb teaching
PF400 1160 XR 0deg 2m Rail NG2 mNewer-generation driver, 0° mount
PF400 1160 XR -90deg 2m Rail NG2 mNewer-generation driver, −90° mount

The mount orientation matters when you pick the device, not just when you bolt the arm down: the 0° and −90° variants describe the rotation of the robot base on the rail carriage, and the kinematics differ accordingly. Choosing the wrong one gives you a robot whose taught positions do not correspond to the cell. The NG devices are the newer driver generation, which integrates its teaching application with RevoWeb.

Alongside the arm, the same driver provides Revolution’s passive plate stacks designed to be served by a PF400 — the TTPv1 and UKRv2 stacks — which do expose operations for setting and counting their plate contents.

Revolution connects to the robot over TCP/IP, at a configured host and port.

  • The robot must be commissioned with Brooks’ own tooling, and taught its positions, before Revolution schedules transfers through it. Position teaching is instrument-side work; a mover that has not been taught a position cannot be scheduled to it.
  • Every instrument the arm serves must be inside the Z travel of the column that was ordered, and inside the horizontal reach of the configuration fitted — plus the rail travel, where a rail is fitted.
  • Labware weight must be within the 0.5 kg payload.
  • The robot must be reachable on the network from the Revolution host.
PropertyPurpose
Robot Host/IPAddressAddress of the robot controller
Robot TCP PortPort the controller’s command interface listens on
Default Speed (%)Speed the driver commands when a move does not specify one
GripperOpenClearanceHow far the gripper opens clear of the labware
TeachBlockGripForceGrip force used when handling the teach block
Safe Home Bounding BoxVolume the arm must be inside to be considered safely homed
PlaceOffsetZNewer-generation driver only. Vertical offset applied on setdown

The Safe Home Bounding Box is worth setting deliberately rather than accepting: it is how the driver decides that the arm is parked somewhere harmless, which is exactly the question that matters when a schedule is recovering from an error and the arm’s position is not yet known.

If you need more of this instrument driven from a schedule, get in touch — the driver is extended on demand.