Design Mode: Industrial Screwdriver Control Software

April 26, 2026

This case study is different from the others in this series. No cloud, no AI, no SaaS. A Windows desktop application for a factory floor operator, communicating with a physical screwdriver over Modbus TCP/IP, generating PDF reports for SAP.

It is included because it demonstrates that Ileen’s Design Mode is not limited to web and AI projects. The architecture principles — proportionality, explicit rationale, risk identification — apply equally to industrial software.

At a glance


Project	Windows desktop control software for a Modbus TCP/IP screwdriver
Mode	Design Mode
Stack	C#, WPF, NModbus, SQLite
Domain	Industrial / factory floor (no cloud, no SaaS)
Integration	PDF reports for SAP
Output	Architecture, Modbus protocol mapping, data model, deployment plan

The brief

A manufacturing company needed software to manage screwdriving operations on a production line. The operator’s workflow was manual and error-prone:

Receive a workpiece with a barcode identifying the required screw program sequence.
Look up the correct programs in a paper/spreadsheet reference.
Manually load programs onto the screwdriver controller.
Execute the sequence, monitoring torque and angle values.
Record the results and generate a report for SAP.

The goal was to automate steps 2–5 entirely. The operator scans the barcode; the software handles everything else.

Constraints

Windows only — the production line workstations run Windows. No web, no mobile.
Modbus TCP/IP — the screwdriver controller communicates via Modbus TCP/IP. This is a fixed constraint; the hardware cannot be changed.
SAP integration via PDF — the company’s SAP instance reads PDF reports from a network share. No direct API integration required or wanted.
Local operation — the software must work without an internet connection. The network share for PDF output is internal.
Operator UX — the operator is not a software user. The interface must be simple enough to use with work gloves on, under time pressure.

The architectural decision

A single-process Windows desktop application with four layers.

GUI Layer (WPF)
├── Barcode input field (scanner or keyboard)
├── Program sequence display (current step, status, parameters)
├── Real-time data visualisation (torque, angle, cycle count)
├── Confirmation dialogs (before executing each program)
└── Report preview

Business Logic Layer
├── Barcode → sequence lookup (SQLite)
├── Program sequencer (load → execute → collect → next)
├── Data collector (torque, angle, timestamps per program)
└── Report assembler (collected data → PDF)

Modbus TCP/IP Client (NModbus library)
├── Connection lifecycle (connect, heartbeat, reconnect on drop)
├── Program write (register map per program parameters)
└── Data read (torque register, angle register, completion flag)

Data Persistence (SQLite)
├── barcode_sequences table (barcode → ordered list of program IDs)
├── programs table (program ID → Modbus register values)
├── execution_log table (timestamp, barcode, program, torque, angle, result)
└── (PDF files written to network share, not stored in DB)

The plan explicitly rejected a database server:

SQLite is the right choice. A database server (PostgreSQL, SQL Server) would require installation, configuration and maintenance on a factory floor workstation. SQLite is a single file. The dataset — a few thousand barcode mappings and execution logs — does not justify anything heavier.

Technology stack

Layer	Choice	Rationale
GUI framework	WPF (Windows Presentation Foundation)	Native Windows, strong data binding, rich UI controls for real-time data
Language	C#	WPF’s natural language; async/await for non-blocking Modbus I/O
Modbus library	NModbus	Open-source, well-maintained, handles Modbus TCP/IP protocol details
Database	SQLite	Zero-install, single file, sufficient for the dataset and access patterns
PDF generation	iText or PdfSharp	Lightweight, no external service dependency, works offline
Report delivery	Network share (UNC path write)	Matches SAP’s existing ingestion method; no API integration needed

Operator UX design decisions

The plan dedicated a section to operator experience — unusually for a technical architecture document.

Key decisions:

Large touch targets — all interactive elements sized for gloved hands.
Single primary action per screen state — the operator should never need to choose between multiple buttons during a sequence.
Explicit confirmation before each program — the operator sees program parameters and must confirm before execution begins. This prevents loading the wrong program due to a misread barcode.
Clear error states — Modbus communication errors, barcode not found and validation failures each have distinct, plain-language error messages. No technical codes shown to the operator.
Completion sound — audible feedback when a full sequence completes, so the operator does not need to watch the screen.

Modbus communication design

The plan specified the Modbus interaction pattern in detail, because this is where the highest failure risk exists:

Write cycle (loading a program):

Write program parameters to the controller’s holding registers.
Write a “load” command register to trigger program activation.
Poll the “load complete” flag register until set or timeout.
If timeout: retry once, then surface error to operator.

Read cycle (collecting execution data):

Poll “execution complete” flag register.
On completion: read torque, angle and cycle count registers.
Write “acknowledge” command to clear the controller’s ready-for-next flag.

Connection lifecycle:

On startup: attempt connection with configurable retry count.
During execution: heartbeat check every 5 seconds.
On connection drop: pause sequence, show reconnection dialog, resume automatically when connection restores.

PDF report structure

The report was defined in the plan to match SAP’s existing reconciliation format:

Header: workpiece barcode, operator ID, workstation ID, date/time.
Per-program section: program ID, parameters, torque result, angle result, pass/fail status, timestamp.
Summary: sequence pass/fail, total duration, signature field.

The file is written to a UNC network share path configured in the application settings. SAP reads it on its normal polling cycle.

Milestones

M1 — Modbus TCP/IP connection + read/write validation on the real controller.
M2 — SQLite schema + barcode lookup + program parameter loading.
M3 — Sequence execution engine + real-time data collection.
M4 — WPF UI with operator UX (barcode input, sequence display, confirmation dialogs).
M5 — PDF generation + network share write.
M6 — Error handling (Modbus errors, barcode not found, execution failures).
M7 — Operator acceptance testing on the production line.

Risks identified

Risk	Mitigation
Modbus register map not fully documented	Allocate M1 entirely to controller validation on the real hardware
Network share unavailable during report write	Queue failed writes locally; retry on next successful write
SQLite corruption on power loss	Enable WAL mode; application-level backup on startup
Operator error (wrong barcode scan)	Confirmation step shows program parameters before execution; operator can abort
Modbus timeout on heavy network load	Configurable timeout and retry count in application settings

Honest limitations

The software is designed for a single screwdriver controller per workstation. A multi-controller setup would require significant architectural changes.
SQLite is sufficient for a single workstation’s execution log, but not suitable if a central reporting database across multiple workstations is needed later. That would require migrating to a server database and a reporting layer.
PDF report format is fixed to match the current SAP ingestion. Any SAP upgrade that changes the expected format requires updating the PDF template.
The application has no remote update mechanism. Updates require manual installation on each workstation.

Browse the full case study library →