Bildverluste vermeiden


Industrie-PCs

Eine andere Lösung ist ein Industrie-PC für die Bildverarbeitung. An diesem darf niemand etwas bewegen (z.B. die Maus) und es gibt Systeme, bei denen verschiedene Windows-Services deaktiviert wurden, um möglichst keine Störung des BV-Systems zu haben, was aber u.U. zu einem instabilen Windows führt. Selbst mit einem Stand-Alone-PC nur für die Bildverarbeitung lassen sich die Probleme nur bedingt lösen. So kann es z.B. aus nicht nachvollziehbaren Gründen einige Male am Tag zu einem Produktionsstopp kommen. Zudem bedeutet ein weiterer PC zusätzliche Kosten sowie erhöhter Platzbedarf. Mangels kostengünstiger Alternativen ist diese Strategie aber ein weit verbreitetes Szenario.

Windows-Echtzeitverarbeitung

Um alle Windows-Latenzzeiten in den Griff zu bekommen, ist es nötig, dass die Bildaufnahme und -verarbeitung unabhängig von Windows läuft. Die Bildakquisition müsste, abhängig vom verwendeten Kamerainterface, dann als eigenständiger Prozess auf einem eigenen Kern laufen, auf den Windows keinen Zugriff hat und der somit unabhängig von Windows ist. Das von der Kamera übertragene Bild bzw. die zugehörigen Bilddaten wären dann nicht im Windows-Speicher, sondern in einem von Windows unabhängigen, getrennten Speicher zu legen. Wenn aber die Bildalgorithmen unabhängig von Windows auf die Bilddaten angewendet werden, dann gibt es die Möglichkeit, mit modernen Mehrkernprozessoren eine komplette Maschine inkl. der SPS und Feldbus-Anbindung auf einem einzigen IPC zu implementieren. Eine Lösung für diese Echtzeit-Bildverarbeitung wird seit Kurzem angeboten. Sie besteht aus einem PC, einem CL-Framegrabber von Matrox Imaging mit zugehörigem RTX64-Treiber sowie der Portierung der gesamten MIL-Algorithmen auf dem RTX64-Subsystem. Dieses kann nachträglich zu Windows installiert werden und ist nach kurzer Konfigurierung einsatzbereit. Es fungiert als SMP-Erweiterung (Symmetric Multi Processing) und transformiert Windows in ein RTOS (Real-Time Operating System). Gleichzeitig stellt es die unabhängige Nutzung vorhandener Kerne für Echtzeitanwendungen sicher, wobei ein Kern immer für Windows reserviert bleibt. Sämtliche Mechanismen (z.B. Mutex, Semaphore….), die ein Software-Entwickler von einem RTOS erwartet, sind vorhanden. Zudem erlaubt die Entwicklungsumgebung (Microsoft VisualStudio) die Implementierung eigener Algorithmen unter Standard C/C++. Je nach benötigtem Interface (bei GigE kann die vorhandene Ethernet-Schnittstelle genutzt werden) kommen nur Software-Komponenten zum Einsatz, was die Kosten zusätzlich senkt. Somit fallen nur die Lizenzkosten für das linear skalierende Subsystem RTX64 an. Allerdings wird ein PC mit Windows bzw. die MIL-Bibliothek benötigt.

Erfolgreicher Praxistest

Für die abgebildeten Screenshots wurde eine Demoapplikation, bestehend aus einer Kamera mit 2x1k Pixel mit 8Bit Tiefe, benutzt, die über ein doppeltes CL-Kabel und einem Radient-CL Framegrabber mit 335fps die Bilder an den PC sendet. Das gleiche Testprogramm zeigte speziell bei Bewegung der Maus oder beim Öffnen des Windows-Taskmanagers, erhebliche Verzögerungen bei den Berechnungen, bis hin zu verlorenen Bildern. Beim Einsatz des RTX64-Subsystemes wird dagegen kein Bild verloren und auch die geforderte Abweichung von kleiner 1ms wird erfüllt. Gleichzeitig besteht die Möglichkeit einen echtzeitfähigen-Master-Stack und eine selbstprogrammierte Ablaufsteuerung auf dem PC zu integrieren, sodass sich ein leicht zu wartendes Software-Gesamtsystem ergibt.

Seiten: 1 2Auf einer Seite lesen

Themen:

| Fachartikel

Ausgabe:

inVISION 1 2015

Das könnte Sie auch Interessieren