Scanora 0.10.0: Why the Scanner Now Switches Itself Off Instead of Sleeping

In short: Scanora 0.10.0 is on the Mac App Store. Its most important change concerns the scanner more than the app: Scanora now sets it to switch itself off after an adjustable time without a scan, instead of going into standby. Woken from standby, the scanner stops accepting key presses until it has been switched off and on once. This post describes how we narrowed that down, why an old suspicion against our own code was cleared along the way – and what else the update brings.

The symptom: a panel that stops answering

Scanora is our macOS app for the KODAK E1030, a sheetfed scanner for which the manufacturer offers no macOS driver. The app speaks the device’s USB protocol directly. The scanner itself has a small display and a few keys: arrows to choose a profile, Start and Cancel. Anyone who keeps Scanora in the background scans almost entirely through those keys – load paper, press Start, and the finished file lands in the profile’s folder.

After a while without use the scanner goes into standby, and the power key blinks. Woken with a short press, it looks healthy, but the display stays on the profile it last showed and the keys do nothing. Over USB, on the other hand, all is well: the device answers status queries, reports no error, and scans when the Mac tells it to. Only the panel is dead – and with it the most convenient way to start a stack.

Three incidents in August, two wrong leads

The symptom was not new. In August the panel froze on three days, and in the end only switching the scanner off and on helped each time. The first time, the display had stuck on a profile right after the profile count had been sent to the scanner. The suspicion was obvious, and from then on the app sent the count only when a profile was added or removed – no longer when the scanner came on.

The second lead was a panel lock that the protocol can set and clear with a command. At the second incident, the command to clear it seemed to help. Only later did we notice that the scanner had been switched off and on shortly before: two possible causes had changed at once, and all that had been tested was that both together worked. At the third incident the command was verifiably sent – and the panel stayed dead.

Both leads have been in our protocol documentation as unexplained ever since. That turned out to be more than a formality.

The measurement that cleared our own code

With a device whose protocol you have reimplemented yourself, the first suspect is your own driver. The counter-test is simple if you are strict about it: switch the scanner off and on, then no traffic from the Mac at all – no app, no query – wait until it goes into standby, and wake it. The panel was dead anyway. So the scanner does this on its own.

Then we tried what brings the panel back: the command that clears the lock, a scan, a USB bus reset, writing the profile count again. None of it helped. A long press on the power key – off, then on again – helped every time. Whatever fails to restart inside the device on waking cannot be repaired from outside; there is no command that revives the panel.

The cause had been in plain sight since August

Looking back, the clue was there from the start. Under Windows, with the manufacturer’s software, our device had no standby: it was on or off and never blinked. A backup of the device’s memory from August shows why – the switch-off time was set to zero. A reset during the protocol analysis brought back the factory power-saving settings the same day, and with them, standby.

All three incidents fall after that reset. Whether each one followed a standby was not recorded at the time, but the picture fits exactly. So we measured the profile-count write specifically: a sixth profile added with the scanner off, scanner switched on, count sent straight away – the panel offered profiles 1 to 6 and kept responding. Removed again with the device on: 1 to 5. The August suspicion is cleared, and 0.10.0 once again sends the profile count as soon as the scanner turns up.

The fix: avoid the state instead of repairing it

The scanner stores its own power-saving times, among them the time until standby and the time until it switches off. What matters is a combination nobody would guess: with the switch-off time at zero, the scanner skips standby and switches itself off completely once the standby time runs out. So “zero” does not mean “never off” here; it means “no standby”.

Measured on the device: standby after five minutes, switch-off time zero. Five minutes later, to the second, the scanner left the USB bus – dark rather than blinking. One press on the power key, a normal start, and the panel works.

That is exactly what Scanora 0.10.0 sets whenever a scanner turns up and whenever you change the setting. You choose the time in Settings, from 5 to 120 minutes; the default is 30. Because the values end up in the scanner’s non-volatile memory, Scanora reads them first and writes only where they differ; on a device that is already set up, it comes down to a single query. And because the setting lives in the scanner, it applies even when Scanora is not running.

What else 0.10.0 brings

Standby is the most visible change, but not the only one. Most of the others also started with a measurement on the device:

• Cancel stops the feed. Until now the stack carried on after a cancel: with four sheets in the tray and a cancel just after the start, all four went through. Now one goes through and three stay in the tray. And Scanora no longer reports a cancel as an error.
• A stack that stalls no longer counts as finished. Held back after the first of three sheets, the scanner reported the end of the stack after about ten seconds, although paper was still in the tray – and Scanora reported success. Now the tray sensor decides: if paper is left, Scanora says the sheets so far are saved and the rest should be scanned again.
• Faults after the stack are reported. If the cover is opened while a sheet is feeding, the scanner reports the paper jam only after the job has ended. So Scanora asks once more at the end and asks you to check the saved pages.
• Text recognition in a process of its own. Apple’s Vision framework keeps caches from one call to the next – 134 to 556 MB over thirty pages, measured. For an app that stays in the background for days, that is too much. The app sandbox allows no child processes, so text recognition now runs in an XPC service that ends once the app lets go of it, taking its memory with it.
• The euro sign stays in the text. Text recognition always read euro signs, curly quotes and dashes correctly; they were lost only when the PDF was written. Now a search for ”€” finds the filed receipt too.
• Also: no dark fringe along the page edges any more, blank back sides straightened again, a running number in file names that counts on reliably, a notification when a scan fails in the background, and a fault in the driver that no longer ends the whole app.

The complete release notes are on the product page.

What this means for device projects

Scanora is a small product, but working on it is no different from client projects with third-party hardware: a device does something no documentation mentions, and you have to find out whether it is your code or the device. Four things proved their worth:

1. One change per measurement. The command that seemed to help in August arrived together with a restart. As long as two things change at once, afterwards you only know that both together work.
2. Rule out your own part before repairing it. A measurement with no host traffic at all cleared the driver in one step – and with it a false suspicion that had cost a useful feature.
3. Write down what is unexplained. Without the note from August, the link to standby would not have been noticed.
4. Avoiding is a fix too. If a device does not come back cleanly from a state, the most robust path is often never to enter it – provided the device offers a setting for it and you write it sparingly.

Incidentally, Scanora drives the scanner entirely from user space, without a kernel extension. The same question comes up on Linux; when user space is enough and when a kernel driver becomes necessary is covered in our article on writing Linux device drivers.

---

Scanora is an independent product of bitshift dynamics GmbH and is not affiliated with the owner of the KODAK trademark. The model name says only which device the app works with.