Using the terminal

The reports are only as good as what the operator does at the terminal. This is that side: how a shift and a job are started, how a stop gets a reason, and how good and reject counts are captured, in a few taps that keep the data clean.

Signing in and starting a job

At the start of a shift the operator takes ownership of the line's data, so everything that follows is attributed to the right person and the right run.

• Sign in. Select your name or scan your badge / RFID tag. This binds the shift's stops and counts to your operator ID, an unsigned line is exactly where "Unknown operator" time comes from.
• Confirm the shift. Check the shift pattern is right and the line reads Operational.
• Start the job. Select the active job or enter its job reference and product code, along with the planned quantity for the run. From here the run is bounded by the job, and its counts and stops are tied to that reference for later costing.

During the run

While the line runs, the terminal is a live feedback loop, not just a logger.

• Pulse indicator. The on-screen indicator flashes with every counted unit, so the operator can see the line is being read.
• Target versus actual. Current rate shows against the planned quantity and the best-operator benchmark, so a slow run is visible as it happens.
• Good and reject counts. Good units are counted from the line; rejects, rework and waste are captured against the run so the Quality side of OEE is real, not assumed. Where counting isn't automated, the operator enters them.

Handling a stop

When the pulse drops, the terminal registers a stop automatically and starts the response clocks. The operator's job is to respond and to classify.

• Evaluate. The screen flags the stop; the operator assesses it and decides whether they can clear it or need help. Responding promptly is what keeps the evaluation phase short.
• Resolve or call for help. Minor stops are cleared on the line. If it can't be cleared, the operator raises a call through Assist, which starts the technician-response clock.
• Give it a reason. Before or just after restarting, the operator selects the reason code (material starve, changeover, speed loss, and so on). The system infers some, but operator confirmation is what makes the accounting definitive.

Closing a job or shift

At the end of a run or a shift, the operator closes out so the next person's data is clean.

• End the job. Complete the job to finalise the batch, entering any required quality or waste counts that weren't captured automatically.
• Clear the pending list. Any stop still without a reason shows in Pending Classification and must be assigned before logout, this is what keeps the Pending Inputs queue trending to zero.
• Log out. Signing out ensures the next operator's stops and counts are recorded against them, not you.

If the network drops

Keep producing. The terminal stores every pulse and every screen interaction on board and syncs automatically when the network returns, so a dropped connection never means lost measurement. If the touchscreen stops responding, wipe it clean and dry; if it's still unresponsive, reboot it from the switch inside the panel.