Renovotec · Application development & hardware integration
PackingBench
A parcel leaves the bench. Its packing record stays behind.
- Problem
- Connect physical packing events to a record people can retrieve.
- My part
- Application, scanner integration, image handling, printing and reporting.
- Outcome
- Working demonstration marketed publicly by Renovotec.
Two arrivals, one packing record · Explanatory diagram
- Barcode arrivesIdentify the item and record the scan time.
- Image followsWait for fresh image data; retry reads while the upload finishes.
- Record is assembledStore the item evidence and set consumed files aside.
What I built
I developed Renovotec’s proof-of-packing application: scan an order, check its items, capture packing evidence and print the labels. The history brings the record back when someone needs to investigate what was packed.
My work covered the application flow, scanner integration, image handling, live interface updates, printing and reporting.
The hardware was only half the problem
A barcode result and its image do not necessarily arrive together. A camera can be ready while the application is not. And a scanner does not stop scanning just because someone has left the login screen.
I worked on those boundaries: when scans are accepted, which bench owns the state, and how the app waits for images. Each bench needed its own device configuration and image storage.
Under the hood: state, timing and isolation
I refactored the scanner interface around initialisation, start/stop, triggering and capture. The packing workflow could ask for an operation without taking on the device-specific connection setup.
For image arrival, I added timestamp-based waiting, file-read retries and handling for consumed files. That addresses stale or missing uploads; it is not a guarantee of perfect image matching under every timing condition.
While moving bench configuration into the database, I investigated a registry that was populated at startup but empty in the worker. The implementation was creating a second dependency-injection container. Keeping one registry and resolving database access within a scope addressed the registration problem.
A scanner stand-in. Not a pretend app.
To test without the physical FS40, I built an emulator that talks to the real scanner service. It sends barcode results, responds to scanner commands and exercises image-upload paths.
That let me work through valid and invalid scans, switching modes and connection behaviour without needing the bench beside me. The first runs exposed image-upload errors too—which is exactly the sort of thing a fake success screen would miss.
The demo changed the design
Customer feedback made one thing clear: mandatory photography was not right for every packing workflow. I worked on configurable capture and label steps instead of making every operator follow the same sequence.
I also tightened scanner/session behaviour and worked through a printing failure that appeared in the published executable but not in development. The release package needed native PDF dependencies. “It works in Visual Studio” was not the finish line.
What you can verify
Renovotec publicly markets the packing-bench demo. The photo shows the physical setup; the public video shows the product in context. My development records cover the simulator, scanner lifecycle, multiple benches and release packaging.