Hamilton MFX2.0

This device is a door-state monitor for an enclosure. It sits on a serial port, keeps a heartbeat running against a small controller wired to the enclosure’s door sensing and locking, tracks whether the door is open or closed and locked or unlocked, and lets a schedule ask one question before it resumes: is the door confirmed closed? If the answer is anything other than a positive confirmation — open, unknown, or no answer at all — the schedule does not resume.

The name does not match a Hamilton product. The Revolution driver is registered as “Hamilton MFX2.0” and described internally as a “Safety micro PLC MFX2.0”, but Hamilton publish nothing under that name. What Hamilton do publish as MFX is their MultiFlex carrier system: passive deck hardware for the Microlab STAR, STAR V and VANTAGE platforms — baseplates that occupy a number of deck tracks and hold MFX modules in portrait or landscape orientation, and the modules themselves (MTP holders, tip modules, tilt and seesaw modules, gravity waste modules, and so on). Hamilton’s MultiFlex Carier Base, for example, is described as a baseplate holding up to three modules in a portrait configuration and occupying five tracks. None of that is a controller, none of it has a serial interface, and none of it performs a safety function. The MFX name and the driver’s description do not line up, and this page does not pretend otherwise.

Read the rest of this page as documentation of what the Revolution driver does, not of a Hamilton catalogue item. The serial protocol it speaks comes from an interface specification supplied with the instrument it was written against, not from anything Hamilton publish on their website. Before this device is relied on anywhere, the actual hardware behind a given installation needs to be identified from its own nameplate and documentation.

At a glance

What it is	Serial door-state monitor and resume gate for an enclosure
Manufacturer product	None published by Hamilton under this name — see above
Transport	Serial port, ASCII line protocol
Live state tracked	Door open/closed, lock locked/unlocked, controller state, link liveness
Revolution control	One operation — confirm doors closed before a resume
Safety classification	None. Not a certified safety interlock — see Safety scope

Specifications

No manufacturer specifications are published for this device. Hamilton publish no product page, datasheet, dimensions, electrical ratings, environmental limits or safety rating under the name MFX2.0, and none are stated here. Nothing in the table below is a manufacturer figure — these are the link parameters the Revolution driver uses, taken from the interface specification the driver was written against and from the driver source itself.

Link	Serial, 115200 baud, 8 data bits, no parity, 1 stop bit
Line ending	CRLF
Message form	Single short ASCII tokens, numerically framed on the wire
Heartbeat	Sent once per second by the driver
Link-loss timeout	3 seconds without a heartbeat reply
Door-state query timeout	2 seconds
Safety rating (PL / SIL / category)	Not published

The parameter that decides an integration is the 3-second heartbeat timeout, because it defines what “connected” means to Revolution. Opening a COM port only proves the port exists. The driver treats the link as live only while a heartbeat reply has been seen inside that window, and it uses that same test at initialise time — see Integration.

Safety scope

This matters more than anything else on the page, so it is stated explicitly.

The Revolution driver is a supervisory monitor and a schedule-level policy layer. It reads the controller’s reported door state, it withholds or sends acknowledgements according to whether a schedule is running, and it stops or refuses to resume a schedule when it cannot confirm a closed door. Those are software decisions taken by the schedule controller.

What the driver does not do, and must not be assumed to do:

• It is not a certified safety interlock and carries no published safety rating. Neither the driver nor any Hamilton publication claims a performance level, SIL, or safety category for it.
• It does not itself lock the door, remove power, or stop motion. Physical locking and any energy-isolating function belong to the controller and the enclosure hardware, not to this driver.
• It cannot guarantee the door is closed. It can only report what the controller tells it, and fail safe when the controller says otherwise or says nothing.
• Its unlock policy is enforced by withholding an acknowledgement, which depends on the controller honouring the protocol. That is a cooperative arrangement, not a hardware guarantee.

Any installation that depends on this device to protect people needs a hardware safety function that is independent of Revolution, and a human safety review of the enclosure as built.

Supported methods

The Revolution driver has a single operation.

• CheckDoorsClosedForResume — confirm with the controller that the enclosure door is closed
  • no parameters

A schedule calls it immediately before resuming. It does not read cached telemetry: it actively queries the controller for its current door state and waits for the reply. It succeeds only on a positive door-closed confirmation. Anything else raises a blocking error.

The two failure paths differ deliberately. If the controller reports a door state other than closed, the only recovery offered is retry — the operator has to physically close the enclosure, and each retry re-queries the controller, so the schedule can only proceed once a closed door is confirmed. There is no ignore-and-continue past an open enclosure. If the controller does not answer in time, the driver also fails, but offers retry or abort, because silence is as likely to be a comms or power fault as an open door and the operator needs a way out other than retrying forever. Either way, a non-responsive controller does not resume the schedule.

Two behaviours run on their own, without a schedule asking for them. A door-unlock notification arriving while a schedule is actually running raises a blocking error and stops the run, with retry gated on a fresh confirmation that the door is closed; and losing the heartbeat stops the run too, on the grounds that an interlock that cannot be monitored is not doing its job. A door-open request made during a run is simply not acknowledged, so the operator has to pause the schedule first.

Integration

Revolution talks to the controller directly over a serial port — no vendor software, no SDK and no network. The driver owns the protocol: it sends a heartbeat every second, reads incoming lines on its own thread, and acknowledges the controller’s state-transition notifications. Door-open requests and unlock notifications are the exception: those are acknowledged only when the schedule controller reports that no schedule is active or that a schedule is fully paused. While a schedule is running — or while the schedule state cannot be determined — the driver treats an unlock as unsafe.

The pause condition is stricter than it first appears. A pause that has been requested but has not yet taken effect still counts as running, because motion may be ongoing until the system actually reaches a paused state. Only a pause that has landed permits a door unlock.

At initialise, the driver requires a serial port to be configured, opens it, and then waits for the first heartbeat reply before declaring success. If the port opens but nothing answers, initialise fails and the port is closed again, rather than leaving a schedule to run against a phantom port with no controller behind it. On uninitialise the link is closed.

Prerequisites

• Identify the hardware. Hamilton publish nothing under this name, so the controller in a given installation has to be identified from its own nameplate and documentation, and its interface specification obtained, before the driver is trusted against it.
• A serial connection between the Revolution host and the controller, at 115200 8N1 with CRLF line endings.
• The controller powered and answering the heartbeat — initialise fails without a reply.
• An independent hardware safety function for the enclosure, plus a human safety review of the installation. This driver is not a substitute for either.
• Schedule state must be readable by the driver. Where it cannot be determined, door unlocks are refused by design, so an operator will see denials rather than an unexpected unlock.

Device configuration

Property	Purpose
Serial Port	COM port the controller is wired to. Required — initialise fails if it is not set.

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