Scanora 0.10.0: Warum sich der Scanner jetzt ausschaltet, statt einzuschlafen

Kurz gesagt: Scanora 0.10.0 ist im Mac App Store. Die wichtigste Änderung betrifft weniger die App als den Scanner: Scanora stellt ihn so ein, dass er sich nach einer einstellbaren Zeit ohne Scan ganz ausschaltet, statt in den Ruhezustand zu gehen. Aus dem Ruhezustand geweckt, nimmt er nämlich keine Tastendrücke mehr an, bis er einmal aus- und wieder eingeschaltet wurde. Dieser Beitrag beschreibt, wie wir das eingegrenzt haben, warum dabei ein alter Verdacht gegen unseren eigenen Code ausgeräumt wurde – und was das Update sonst noch mitbringt.

Das Fehlerbild: ein Bedienfeld, das nicht mehr antwortet

Scanora ist unsere macOS-App für den KODAK E1030, einen Einzugsscanner, für den der Hersteller keinen macOS-Treiber anbietet. Die App spricht das USB-Protokoll des Geräts direkt. Am Scanner selbst sitzen ein kleines Display und ein paar Tasten: Pfeile zur Wahl des Profils, Start und Abbrechen. Wer Scanora im Hintergrund laufen lässt, scannt fast nur über diese Tasten – Papier einlegen, Start drücken, die fertige Datei liegt im Ordner des Profils.

Nach einer Weile ohne Benutzung geht der Scanner in den Ruhezustand, die Ein-Taste blinkt. Weckt man ihn mit einem kurzen Druck, wirkt er gesund, doch das Display bleibt auf dem Profil stehen, das es zuletzt zeigte, und die Tasten tun nichts. Über USB ist dagegen alles in Ordnung: Das Gerät beantwortet Statusabfragen, meldet keinen Fehler und scannt, wenn der Mac den Auftrag gibt. Nur das Bedienfeld ist tot – und damit der bequemste Weg, einen Stapel zu starten.

Drei Vorfälle im August, zwei falsche Spuren

Das Fehlerbild war nicht neu. Im August stand das Bedienfeld an drei Tagen still, und am Ende half jedes Mal nur Aus- und Einschalten. Beim ersten Mal war das Display auf einem Profil stehen geblieben, direkt nachdem die Anzahl der Profile an den Scanner geschickt worden war. Der Verdacht lag nahe, und die App schickte die Anzahl danach nur noch, wenn ein Profil angelegt oder entfernt wurde – nicht mehr beim Einschalten.

Die zweite Spur war eine Sperre des Bedienfelds, die das Protokoll per Befehl setzen und aufheben kann. Beim zweiten Vorfall schien der Befehl zum Aufheben zu helfen. Erst später fiel auf, dass der Scanner kurz davor aus- und eingeschaltet worden war: Zwei mögliche Ursachen hatten sich gleichzeitig geändert, und geprüft war nur, dass beide zusammen wirken. Beim dritten Vorfall wurde der Befehl nachweislich gesendet – und das Bedienfeld blieb tot.

Beide Spuren standen seitdem als ungeklärt in unserer Protokolldokumentation. Das war keine Formalie, wie sich zeigen sollte.

Die Messung, die den eigenen Code entlastet

Bei einem Gerät, dessen Protokoll man selbst nachgebaut hat, liegt der erste Verdacht beim eigenen Treiber. Die Gegenprobe ist einfach, wenn man sie konsequent macht: Scanner aus- und einschalten, dann keinerlei Datenverkehr vom Mac – keine App, keine Abfrage –, warten, bis er in den Ruhezustand geht, und ihn aufwecken. Das Bedienfeld war trotzdem tot. Damit war klar: Der Scanner tut das von sich aus.

Danach haben wir durchprobiert, was das Bedienfeld zurückholt: den Befehl zum Aufheben der Sperre, einen Scan, einen Reset des USB-Busses, das erneute Schreiben der Profilanzahl. Nichts davon half. Ein langer Druck auf die Ein-Taste – aus, dann wieder ein – half jedes Mal. Was im Gerät beim Aufwachen nicht wieder anläuft, lässt sich von außen nicht reparieren; einen Befehl, der das Bedienfeld wiederbelebt, gibt es nicht.

Die Ursache lag seit August offen

Rückblickend war der Hinweis von Anfang an da. Unter Windows, mit der Software des Herstellers, kannte unser Gerät keinen Ruhezustand: Es war an oder aus, geblinkt hat es nie. Eine Sicherung des Gerätespeichers aus dem August zeigt, warum – die Abschaltzeit stand auf null. Ein Zurücksetzen während der Protokollanalyse hat am selben Tag die Werkseinstellungen fürs Energiesparen zurückgebracht, und mit ihnen den Ruhezustand.

Alle drei Vorfälle liegen nach diesem Zurücksetzen. Ob jedem ein Ruhezustand vorausging, wurde damals nicht aufgezeichnet; das Bild passt aber genau. Den Schreibvorgang für die Profilanzahl haben wir deshalb gezielt nachgemessen: bei ausgeschaltetem Scanner ein sechstes Profil angelegt, Scanner eingeschaltet, Anzahl sofort geschickt – das Bedienfeld bot die Profile 1 bis 6 an und reagierte weiter. Wieder entfernt bei eingeschaltetem Gerät: 1 bis 5. Der Verdacht aus dem August ist damit ausgeräumt, und 0.10.0 überträgt die Profilanzahl wieder, sobald der Scanner auftaucht.

Die Lösung: den Zustand vermeiden, statt ihn zu reparieren

Der Scanner speichert seine Zeiten fürs Energiesparen selbst, darunter die Zeit bis zum Ruhezustand und die bis zum Abschalten. Entscheidend ist eine Kombination, die man nicht erraten würde: Steht die Abschaltzeit auf null, überspringt der Scanner den Ruhezustand und schaltet sich stattdessen ganz aus, sobald die Zeit bis zum Ruhezustand abgelaufen ist. „Null“ heißt hier also nicht „nie ausschalten“, sondern „kein Ruhezustand“.

Am Gerät nachgemessen: Ruhezustand nach fünf Minuten, Abschaltzeit null. Fünf Minuten später, auf die Sekunde, verschwand der Scanner vom USB-Bus – dunkel statt blinkend. Ein Druck auf die Ein-Taste, ein normaler Start, und das Bedienfeld funktioniert.

Genau das stellt Scanora 0.10.0 ein, sobald ein Scanner auftaucht und wenn Sie die Einstellung ändern. Die Zeit wählen Sie in den Einstellungen zwischen 5 und 120 Minuten, vorgegeben sind 30. Weil die Werte im nichtflüchtigen Speicher des Scanners landen, liest Scanora sie zuerst und schreibt nur, wenn sie abweichen; bei einem bereits eingestellten Gerät bleibt es bei einer einzigen Abfrage. Und weil die Einstellung im Scanner liegt, gilt sie auch, wenn Scanora gerade nicht läuft.

Was 0.10.0 sonst mitbringt

Der Ruhezustand ist die sichtbarste Änderung, aber nicht die einzige. Auch bei den meisten anderen stand am Anfang eine Messung am Gerät:

• Abbrechen hält den Einzug an. Bisher lief der Stapel nach einem Abbruch weiter: Mit vier Blättern im Einzug und einem Abbruch kurz nach dem Start liefen alle vier durch. Jetzt läuft eines durch, drei bleiben liegen. Einen Abbruch meldet Scanora außerdem nicht mehr als Fehler.
• Ein Stapel, der stockt, gilt nicht mehr als fertig. Hielt der Einzug nach dem ersten von drei Blättern an, meldete der Scanner nach etwa zehn Sekunden das Ende des Stapels, obwohl noch Papier im Einzug lag – und Scanora meldete Erfolg. Jetzt entscheidet der Papiersensor: Liegt noch etwas im Einzug, sagt Scanora, dass die Blätter bis dahin gespeichert sind und der Rest erneut gescannt werden sollte.
• Störungen nach dem Stapel werden gemeldet. Wird die Klappe geöffnet, während ein Blatt läuft, meldet der Scanner den Papierstau erst nach dem Ende des Auftrags. Scanora fragt deshalb am Ende noch einmal nach und bittet Sie, die gespeicherten Seiten zu prüfen.
• Texterkennung in einem eigenen Prozess. Apples Vision-Framework behält zwischen zwei Aufrufen Zwischenspeicher – gemessen 134 bis 556 MB über dreißig Seiten. Für eine App, die tagelang im Hintergrund läuft, ist das zu viel. Der App-Sandkasten erlaubt keine Kindprozesse, deshalb läuft die Texterkennung jetzt in einem XPC-Dienst, der endet, sobald die App ihn loslässt, und seinen Speicher mitnimmt.
• Das Eurozeichen bleibt im Text. Die Texterkennung hat Eurozeichen, deutsche Anführungszeichen und Gedankenstriche immer richtig gelesen; verloren gingen sie erst beim Schreiben des PDFs. Jetzt findet eine Suche nach „€“ auch den abgelegten Kassenbon.
• Dazu: kein dunkler Rand mehr an den Seitenkanten, wieder gerade gerichtete leere Rückseiten, eine laufende Nummer im Dateinamen, die zuverlässig weiterzählt, eine Mitteilung, wenn ein Scan im Hintergrund fehlschlägt, und ein Fehler im Treiber, der nicht mehr die ganze App beendet.

Die vollständigen Versionshinweise stehen auf der Produktseite.

Was daraus für Geräteprojekte folgt

Scanora ist ein kleines Produkt, aber die Arbeit daran unterscheidet sich nicht von Kundenprojekten mit fremder Hardware: Ein Gerät tut etwas, das keine Dokumentation erwähnt, und man muss herausfinden, ob es am eigenen Code liegt oder am Gerät. Vier Dinge haben sich dabei bewährt:

1. Eine Änderung pro Messung. Der Befehl, der im August scheinbar half, kam zusammen mit einem Neustart. Solange sich zwei Dinge gleichzeitig ändern, weiß man hinterher nur, dass beide zusammen wirken.
2. Den eigenen Anteil ausschließen, bevor man ihn repariert. Eine Messung ganz ohne Datenverkehr vom Host hat den Treiber in einem Schritt entlastet – und einen Fehlverdacht gleich mit, der eine sinnvolle Funktion gekostet hatte.
3. Ungeklärtes aufschreiben. Ohne die Notiz aus dem August wäre die Verbindung zum Ruhezustand nicht aufgefallen.
4. Vermeiden ist auch eine Lösung. Kommt ein Gerät aus einem Zustand nicht sauber zurück, ist der robusteste Weg oft, ihn gar nicht erst zu betreten – vorausgesetzt, das Gerät bietet eine Einstellung dafür und man schreibt sie sparsam.

Scanora spricht den Scanner übrigens vollständig aus dem Userspace an, ohne Kernel-Erweiterung. Unter Linux stellt sich dieselbe Frage; wann der Userspace reicht und wann ein Kernel-Treiber nötig wird, beschreibt unser Beitrag Linux-Treiber entwickeln.

---

Scanora ist ein unabhängiges Produkt der bitshift dynamics GmbH und steht in keiner Verbindung zum Inhaber der Marke KODAK. Der Modellname benennt allein, mit welchem Gerät die App zusammenarbeitet.