Public Support

Florian Roth wrote:

Hallo Joan,

vorweg stellt sich mir die Frage, warum ihr über die DS API geht und nicht den speziellen uEye Filter verwendet ?
Der wäre was das Device betrifft dahingehend optimiert und spricht des API, natürlich wenn Hardware und Treiber(Version) zur verwendeten API passen (siehe Doku).

Wir hatten weiterhin Probleme mit den uEye Filter leider, dann haben wir mitgekriegt dass es mit den DS auch gehen sollte (ein Kollege hatte schon seit einige Monate damit gearbeitet). Aus Zeitdruck haben wir uns entschieden mit den DS Filter weiter zu arbeiten.

Unabhängig davon löst aber auch das nicht euer Problem.
Eine ADTF Config kann nicht mit Bordmitteln von außen beeinflusst werden, es besteht aber die Anfordung, eine API/Tooling bereitzustellen um z.B. Componenten hinzuzufügen, zu verbinden oder deaktivieren, das soll in ADTF 3 umgesetzt werden.

OK. ADTF 3 wäre schon schön zu haben, aber dafür brauchen wir viel mehr Zeit, was wir jetzt im Projekt nicht haben.

Aber eine Config ist immer spezialisiert für ein Setup, heißt wenn eine Komponente nicht vorhanden ist, startet sie auch nicht.
Im Init muss geprüft werden, ob die Device-API verfügbar, ansonsten bricht es ab und das ist ja auch richtig so.

Was mir als Lösung einfallen würde:
1) Ihr prüft z.B. per Skript (Python, batch/shell, ...) ob das Device verfügbar ist und startet dann erst ADTF mit der dafür geeigneten Config
1a) Ihr erstellt jeweils eine mit oder ohne Device
1b) Ihr manipuliert das System-xml File (Config) und deaktiviert die Komponente auf File Ebene vor dem Start
2) Ihr schreibt den DS Filter um (der Source wird in der Device TB geliefert), so dass das beim Init ignoriert wird und der Filter einfach bei fehlender Hardware "nichts macht"

Hilft euch das weiter ?

Ja, das hilft uns auf jeden Fall. Bevor wir was codieren, wollte ich mich vergewissern dass es nicht einen einfacheren Weg gibt.

vielen Dank
Joan