Vision-App-Entwicklung mit IDS peak (Bild: IDS Imaging Development Systems GmbH)
Hardwareunabhängig und standardkonform
IDS hat aus den Kundenerfahrungen mit GenICam und der eigenen IDS Software Suite die Vor- und Nachteile identifiziert und IDS peak entwickelt. Mit GenICam als standardisierte Softwarebasis behält der Anwender auch mit dem neuen SDK weiterhin die freie Wahl, welche Kameras er einsetzen möchte, ohne dabei auf die Vorteile einer modernen Entwicklungsschnittstelle verzichten zu müssen. Für ein optimales Anwendererlebnis bringt das plattformunabhängige SDK IDS peak von Sourcecode Samples bis Transport Layer alle erforderlichen Komponenten mit, sodass Kunden direkt mit der Entwicklung eigener Anwendungen starten können. Als Nebeneffekt können Nutzer auf vollständigen Support für alle Anwendungskomponenten auf IDS als einzigen Ansprechpartner zurückgreifen. Das neue SDK stellt dabei für Anwendungsentwickler alle nötigen Bibliotheken und Softwareschnittstellen bereit. Gleichzeitig ist die neu entwickelte, objektorientierte Programmierschnittstelle aber erheblich einfacher zu bedienen als GenICam, ohne dessen Funktionsumfang einzuschränken bzw. zu umgehen. Die Kommunikation zur Kamerahardware erfolgt ausschließlich über die standardisierte Schnittstelle und die Vision Transport Layer, wodurch IDS peak absolut hardwareunabhängig und standardkonform bleibt. Die Austauschbarkeit und Kompatibilität mit allen USB3 Vision und GigE Vision konformen Industriekameras bleibt erhalten. Es gibt keinerlei herstellerspezifische Einschränkungen und selbst der Mischbetrieb von Kameras verschiedener Hersteller bzw. mit unterschiedlichen Schnittstellen ist möglich.
Funktionsweise
Dazu orientiert sich IDS peak an der Modulhierarchie, die durch den GenTL Standard vorgegeben ist. Die Module sind über Deskriptoren ansprechbar, die so etwas wie Visitenkarten darstellen. So lassen sich bereits ausgewählte Informationen der Module abfragen, bevor sie verfügbar und geöffnet sind. Wohingegen die Funktionalitäten der Module in unteren Schichten durch sogenannte Eltern-Kind-Beziehungen erst dann sichtbar und nutzbar werden, wenn die entsprechenden Module geöffnet und verfügbar sind. Dieses Prinzip verringert Fehler im Umgang mit den Klassen und damit auch Entwicklungszeit. Ein Beispiel dafür ist der Zugriff auf die Funktionen einer Kamera. Nur über eine bereits geöffnete Kamera bekommt man Zugriff auf ihre Nodemap. Erst darüber sind dann detaillierte Abfragen und spezielle Einstellungen dieser Kamera möglich. Convenience-Klassen und -Funktionen, die im Standard nicht vorhanden sind, vereinfachen den Umgang mit wiederkehrenden Prozessen, wie z.B. das Device- und Speicher-Handling. Der Einsatz der Modulklassen reduziert den notwendigen Anwendungscode und verbessert damit Lesbarkeit und Stabilität der Kameraanwendung.
