Bildverluste vermeiden
Echtzeit-Bildverarbeitung unter Windows
Die meisten der derzeit angebotenen Bildverarbeitungssoftwares wie Halcon, Matrox Imaging Library (MIL), VisionPro usw. laufen bevorzugt unter Windows. Allerdings wurde dieses Betriebssystem für Desktop-Anwendungen entwickelt. Dadurch ergeben sich aufgrund des Windows-Schedulers (der die aktuelle Reihenfolge der Abarbeitung der Aufgaben bestimmt) Latenzzeiten, die bis zu 500ms betragen können. Jeder Anwender kennt das Verhalten, wenn er die Maus bewegt, diese aber für eine kurze Zeit nicht reagiert und quasi stillsteht, um sich dann plötzlich irgendwo hinzubewegen.
Dieses Verhalten kann dazu führen, dass bei der Bildaufnahme (Transport der Bilddaten in den Speicher z.B. über GigE-Vision) Verzögerungen auftreten. Wenn die Maschinensteuerung bzw. der Prozess darauf angewiesen ist, dass das Bild zu einer genauen Zeit vorhanden sein muss, kann dies zu einer inakzeptablen Zeitdifferenz führen, die einen Maschinenstillstand zur Folge haben kann. Die Algorithmen (z.B. zur Form- oder Farberkennung) werden normalerweise auf jedes sich im Windows-Speicher befindliche, eingelesene Bild angewendet und können sehr komplex sein, d.h. benötigen ggf. auch unterschiedlich lange Berechnungszeiten. Sollten diese zu lange dauern, können Abbruchmechanismen definiert werden. Jeder Algorithmus, der unter Windows-Kontrolle läuft, kann in der Abarbeitung durch den Windows-Scheduler aufgerufene Services unterbrochen bzw. verzögert werden. Dadurch steht das Ergebnis der Berechnung eventuell nicht zum benötigten Zeitpunkt zur Verfügung und könnte zu einer Störung der Maschine führen. Jeder gute Ingenieur sucht daher nach einer Lösung für die beschriebenen Probleme, weshalb wir uns verschiedene Strategien genauer ansehen.
FPGA-Framegrabber
Es gibt Framegrabber, auf denen nicht nur die Bildaufnahme, sondern auch die komplette Berechnung (nicht nur eine Bildvorverarbeitung) direkt vorgenommen werden kann. Die Algorithmen sind entsprechend vorab als VHDL-Programm zu erstellen, mit dem passenden VHDL-Compiler zu übersetzen und anschließend zu testen, was einen hohen Zusatzaufwand und zusätzliche Zeit in der Entwicklung bedeutet. Die Framegrabber kosten ohne Programmierung einige hundert Euros pro Stück, wobei dort noch nicht das Interface (GigE, CL oder CXP) bzw. die Kamera mit einbezogen ist. Falls das FPGA zu klein und damit die Maschine nicht so flexibel wie gewünscht ist, bedingt dies ein Re-Design der Karte mit einem größeren FPGA.
PCI-Karte auf DSP-/FPGA-Basis
Eine andere Strategie wäre die komplette Eigenentwicklung einer PCI-Einsteckkarte auf Basis eines DSPs bzw. FPGAs. Dies bedeutet, dass darauf die Bilderfassung (das Interface muss selbst programmiert werden) sowie die gesamte Echtzeitverarbeitung (die auch entwickelt und getestet werden muss) abläuft und somit getrennt von Windows läuft. Dafür benötigt man ein Betriebssystem für den DSP bzw. FPGA, das dann noch anzupassen ist. Auch die Algorithmen müssen an den verwendeten Chip angepasst werden. Ebenfalls kommt man um eine eigene Hardware-Entwicklung mit den zugehörigen Platinenentwicklungen und Fehler-Iterationen sowie den Testszenarios nicht herum. Nicht zu vergessen ist die nachgelagerte Lagerhaltung für Service und Ausfälle. Ganz zu schweigen von dem Problem möglicher Abkündigungen von Bauteilen. Zudem ist das Board nur für eine begrenzte Leistung entwickelt, sodass, wenn mehr Power benötigt wird, ein neues Board notwendig ist.
