A vertical lift module and my own simulator
The machine was a few weeks away and the vendor's simulator wouldn't be ready in time, so I wrote my own to reach delivery day with the integration tested.
Details
How it works
-
1 Order the WMS decides which bottles are needed
-
2 Slot tray, row and position
-
3 Call the tray comes down to the bay
-
4 LED bar “5B 2BOT” and an arrow above the slot
-
5 Operator picks the bottles without touching a screen
-
6 Return the tray goes back on its own
Context
The company bought a 25-tray vertical lift module to replace the tubes where supplier bottles are stored. Delivery was set for 26 October 2026 and the idea was clear from the start: the ERP decides, the machine executes, and the operator never touches the machine’s screen.
What I did
Every slot on every tray is just another bottle-rack location, so its stock counts in every report from day one. That’s 49 slots per tray, 1,225 in total, with room for 3,675 bottles. The LED bar text (slot, row, quantity, an arrow at the centre of the slot and a depth symbol) comes from a pure function with tests, and its format lives in configuration so it can be changed in minutes.
The connector talks to the machine’s API to call, return and swap trays, logs every command and takes turns on the double bay. There’s a screen for stocking, another one for picking and an admin console. Since the vendor’s simulator wouldn’t be ready, I wrote my own version of the documented API, with trays that take time to arrive and realistic errors, and tested against it all week.
Outcome
The integration is tested against the simulator before the machine arrives, so on delivery day it only needs to be validated for real.
What I learned
When hardware is late, simulate the contract, and whatever the documentation leaves unclear becomes a parameter. Anything operations wants to be able to change, like symbols, texts or timings, goes in configuration.