Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
vielleicht könnt ihr mir bei folgender Aufgabe helfen:
Ich möchte eine etwas ältere (ca. 2001) Kamera (MX-916) der Firma Starlight Xpress in LabVIEW einbinden.
Im original Programm funktioniert das mit der unten genannten Treiber Datei hervorragend, nur eben nicht in LabVIEW.
Ich habe die notwendigen Dateien mit Ausnahme der header Datei.
cam32.dll
cam32.def
cam32.res
cam32.dpr
cam32.dof
Und ich habe eine Beschreibung der Funktionen der dll. Ich kann die Kamera auch schon ansprechen u den Status abfragen, aber leider kann ich keine Bilder auslesen.
Über USB alleine funktioniert es nicht, da die Kamera wohl nicht direct show kompatibel ist.
' schrieb:Und ich habe eine Beschreibung der Funktionen der dll. Ich kann die Kamera auch schon ansprechen u den Status abfragen, aber leider kann ich keine Bilder auslesen.
Über USB alleine funktioniert es nicht, da die Kamera wohl nicht direct show kompatibel ist.
Viele Grüße, Silvio
Hallo Silvio,
das sieht doch gar nicht so schlecht aus. Daß der Header fehlt macht nichts, Du hast doch in der Word-Datei eine Beschreibung der Funktionsprototypen und was die Funktion macht.
Das es nicht allein über USB geht steht in der Beschreibung drin. Und Bilder runterzuladen sollte über die Funktion "CamGetData" bzw. CamGetImage gehen (so auf den ersten Blick). Dann mußt Du für Buffer im DLL-Knoten Array vorzeichenloser 16-Bit-Wert einstellen, aber dazu gibt's in diesem Forum und auch bei NI reichlich Beispiele. Du mußt natürlich, wie in der Worddatei beschrieben vorher mit der genannten Funktion genügend Speicher reservieren und auch das Feld, das Du dem DLL-Knoten übergibst in LabVIEW mit einer ausreichenden Größe initialisieren.
Habe mal den Funktionsrumpf zusammen gebastelt:
Habe nur beim Schließen eine Fehlermeldung bekommen, daß da noch eine andere DLL fehlt.
dank der Hilfe von Andreas kann ich jetzt auf die Daten zugreifen u sie in einer Datei speichern, aber leider stimmt da an der Formatierung der Daten noch etwas nicht. Ich habe alle möglichen Kombinationen für den Datentyp ausprobiert, aber keiner macht Sinn.
Bei den Einstellungen für die Kamera wie ich sie benutzt habe um das Bild im Anhang zu machen, sollte das ganze Bild völlig überbelichtet sein u somit ein einheitliches Signal von 65.536 liefern. Leider tut es das nicht.
Könnt ihr mir dabei Helfen od. mir sagen wo ich weitersuchen kann.
Vielen Dank.
leider kann ich so nicht viel dazu sagen. Besteht die Möglichkeit, daß Du zu dem Bild, das Du geschickt hast, noch eins stellst das so aussieht, wie Du es erwartest, das z.B. mit der Originalsoftware gemacht worden ist?
Lad doch auch mal das VI, das Du in der Word-Datei abgebildet hast, hoch.
Warum benutzt Du einen "Intensity Graph", um ein Bild anzuzeigen?
dank der Hilfe von Andreas kann ich jetzt auf die Daten zugreifen u sie in einer Datei speichern, aber leider stimmt da an der Formatierung der Daten noch etwas nicht. Ich habe alle möglichen Kombinationen für den Datentyp ausprobiert, aber keiner macht Sinn.
Bei den Einstellungen für die Kamera wie ich sie benutzt habe um das Bild im Anhang zu machen, sollte das ganze Bild völlig überbelichtet sein u somit ein einheitliches Signal von 65.536 liefern. Leider tut es das nicht.
Könnt ihr mir dabei Helfen od. mir sagen wo ich weitersuchen kann.
Vielen Dank.
Viele Grüße, Silvio
Also interessant wäre zu wissen ob die Size Funktion die Grösse des nötigen Speichers in Bytes oder in Pixels angibt. Könnte durchaus sein dass es Bytes wären und dann wäre das schwarze Bild das was sie zurückliefert und der Rest einfach nur random Data wie er gerade im Speicher war bei der Allozierung.
' schrieb:Also interessant wäre zu wissen ob die Size Funktion die Grösse des nötigen Speichers in Bytes oder in Pixels angibt. Könnte durchaus sein dass es Bytes wären und dann wäre das schwarze Bild das was sie zurückliefert und der Rest einfach nur random Data wie er gerade im Speicher war bei der Allozierung.
Rolf Kalbermatter
Hallo Rolf,
in diesee Richtung denke ich auch.
Meine Vermutung war, daß es vielleicht auch sein könnte, daß die Bytes im Speicher in der falschen Reihenfolge ausgewertet werden. Die Funktion, die die Daten ausliest liefert aber lt. Funktionsrumpf ein Word-Feld, so daß das unwahrscheinlich ist. Deswegen würde ich gern ein Vergleichsbild sehen und das Blockdiagramm. Vielleicht ist es auch nur ein Anzeige-Problem, da Silvio einen Intensitäts-Graphen verwendet, wobei die Kamera aber ein Bild liefert.
Das kann man eben nur untersuchen, wenn man den Algorithmus sieht.
Gruß Andreas
________________
LV 7.1; 8.5
29.04.2008, 14:06 (Dieser Beitrag wurde zuletzt bearbeitet: 29.04.2008 18:16 von jg.)
Im Anhang befindet sich jetzt ein original Testbild (nicht sehr sauber aber zum Ausrichten u Testen vollkommen ausreichend). Ich habe 1 Sekunde belichtet. Genau das Gleiche habe ich mit dem VI aus dem Anhang gemacht (Bild ist ebenfalls angehängt).
Das Bild aus der original Software (die auf die gleiche .dll zugreift) muss ich mit folgenden Parametern in ein Bildbearbeitunsprogramm importieren:
Bits: 16 Bit
Word: PC
Sign: unsigned
Header size (bytes to skip): 16
End of Line (byte to skip): 0
X Resolution: 290
Y Resolution: 376
Vielleicht hilft das ja weiter.
Die Size Funktion gibt die Größe des zu reservierenden Speichers als Zahl der Speichereinheiten (Byte bzw. Word) zurück, aber nicht die Speichergröße.
Was ist an der Darstellung über einen intensity Graph nicht ok? Gibt es für diesen Fall bessere Möglichkeiten?
Im Anhang befindet sich jetzt ein original Testbild (nicht sehr sauber aber zum Ausrichten u Testen vollkommen ausreichend). Ich habe 1 Sekunde belichtet. Genau das Gleiche habe ich mit dem VI aus dem Anhang gemacht (Bild ist ebenfalls angehängt).
Das Bild aus der original Software (die auf die gleiche .dll zugreift) muss ich mit folgenden Parametern in ein Bildbearbeitunsprogramm importieren:
Bits: 16 Bit
Word: PC
Sign: unsigned
Header size (bytes to skip): 16
End of Line (byte to skip): 0
X Resolution: 290
Y Resolution: 376
Vielleicht hilft das ja weiter.
Die Size Funktion gibt die Größe des zu reservierenden Speichers als Zahl der Speichereinheiten (Byte bzw. Word) zurück, aber nicht die Speichergröße.
Was ist an der Darstellung über einen intensity Graph nicht ok? Gibt es für diesen Fall bessere Möglichkeiten?
Vielen Dank.
Viele Grüße, Silvio
Hallo Silvio,
das erste, was mir aufgefallen ist: Du hast keinen Speicher für die Daten, die Du abholen willst, reserviert. Du übergibst der dll-Funktion den Zeiger auf die Adresse im Speicher, wo die dll die Daten ablegen soll und wovon Dein VI die Daten lädt. Wenn Du diesen Speicherbereich zuvor nicht für Deine Applikation reservieren läßt, schreibt die Funktion die Daten irgendwo im Speicher hin und das führt in der Regel zum Crash. Entweder kommt eine LV-Fehlermeldung und die Ausführung des VIs wird abgebrochen oder es erscheint ein Fenster "LabVIEW hat einen Fehler verursacht und muß beendet werden"
Den Speicher reservierst Du, indem Du ein Feld anlegst, das so viele Elemente hat, wie Du Bildpunkte erhältst und zwar in dem Datenformat, wie die Funktion Dir liefert.
Vom Intensitätsgraph habe ich nicht so viel Ahnung, finde es nur ungewöhnlich. Dafür gibt es Bild-Elemente. Da Du eine Evaluierungsversion von LV verwendest, kann es sein, daß Du diese Bild-Funktionen nicht nutzen kannst, denn die gibt es auch nicht im Basis-Paket. Streng genommen sollte es auch mit einem Intensitätsgraphen funktionieren, hab's aber noch nicht ausprobiert.
Ich habe ein Bild-Element genommen und die entsprechende Funktion zum zeichnen. Hierfür mußte ich allerdings aus den 16-Bit-Werten 8-Bit-Werte machen und in Graustufen im RGB-Format wandeln. Ich weiß nicht, ob da etwas brauchbares, weil ich nicht weiß, ob die Kamera volle 16 Bit ausnutzt. Sonst mußt Du die Werte der Bildpunkte um ein paar Stellen nach rechts shiften.
das erste, was mir aufgefallen ist: Du hast keinen Speicher für die Daten, die Du abholen willst, reserviert. Du übergibst der dll-Funktion den Zeiger auf die Adresse im Speicher, wo die dll die Daten ablegen soll und wovon Dein VI die Daten lädt. Wenn Du diesen Speicherbereich zuvor nicht für Deine Applikation reservieren läßt, schreibt die Funktion die Daten irgendwo im Speicher hin und das führt in der Regel zum Crash. Entweder kommt eine LV-Fehlermeldung und die Ausführung des VIs wird abgebrochen oder es erscheint ein Fenster "LabVIEW hat einen Fehler verursacht und muß beendet werden"
Den Speicher reservierst Du, indem Du ein Feld anlegst, das so viele Elemente hat, wie Du Bildpunkte erhältst und zwar in dem Datenformat, wie die Funktion Dir liefert.
Hallo Andreas
Das mit dem Speicher war schon in Ordnung. Seit LabVIEW 8.2 (oder vielleicht 8.0) kann man bei einem Arrayparameter einen anderen skalaren Parameter als Minimum Size angeben. Dann alloziert LabVIEW den entsprechenden Speicher vor dem DLL Aufruf wenn kein gültiges Array angeschlossen ist (oder bei einem zu kleinen Array resized es den). Und das macht Silvio auch ganz richtig so.
In älteren LabVIEW Versionen hättest Du aber vollumfänglich recht, dass man den entsprechenden Speicher erst explizit allozieren muss indem man z.B. ein Array mit der nötigen Grösse initialisiert.
/
.dll für ältere USB Camera einbinden .h fehlt
