' schrieb:Hallo Jens,

erstmal entschuldigung für die späte Nachricht, aber ich hatte dieses Problem vorerst bei Seite gelegt, weil es mich zu sehr frustriert hat..

Also:
Eine Framegrabber Karte ist vorhanden. Die Meteor-II von Matrox.

Was ich bisher gemacht habe:
Mittels des Tools "Matrox IntelliCam" habe ich mir ein sogenanntes DCF-File erstellt mit angepasster Auflösung und Kameraeinstellungen, weil das angezeigte Bild bzw. Video in diesem Tool sich etwas überlappt hatte. Na jedenfalls habe ich mich nach erfolgreicher Suche in dem Forum hier 2 sehr interessante Posts entdeckt.

(hier ging es um die Datenerfassung allgemein)
http://www.LabVIEWforum.de/index.php?showtopic=6792

(hier um ein Problem mit dem Skript von abrissbirne)
http://www.LabVIEWforum.de/index.php?showtopic=7015

abrissbirne verwendet CIN und scheint wohl zum Ziel gekommen zu sein. Allerdings will ich nicht bloß Bilder anzeigen lassen, sondern ein Video.
Es soll per Button aktiviert sein und mir das Videomaterial anzeigen, was die Kamera gerade aufnimmt. Abspeichern oder sonstiges brauch ich nicht.
Jetzt wurde mehrfach darauf hingewiesen, dass es besser wäre DLL einzusetzen, da CIN vermutlich bald oder eines Tages nicht mehr unter LabVIEW laufen wird.
Wie dem auch sei, ich kann java und bissl c++ coden, doch wie ich die DLL coden soll, weiß ich leider nicht, da ich keine Erfahrung damit habe. Code würde ich sicherlich lesen und intepretieren können, mehr aber auch nicht.

Ich möchte genau wie abrissbirne das DCF-File (nichts anderes als ein Parameterfile um die Kameradaten korrekt auszulesen) dann in die DLL einbinden, nur habe ich wie gesagt keinen Schimmer, wie und was ich da anstellen soll

' schrieb:Das mit den CINS versus DLL hast Du richtig verstanden. Es gibt heutzutage in LabVIEW keinen guten Grund CINs zu verwenden aber viele gute Gründe um DLLs zu machen.

Was das eigentliche Problem betrifft: Du machst Dich mit dem Interfacen von externer Hardware an LabVIEW an eine potentiel ziemlich komplizierte Aufgabe heran und dabei ist ein Framegrabber noch gleich sowas wie die Köngisdisziplin dabei. Ich habe sehr viel Erfahrung in dieser Angelegenheit aber für einen nicht NI-Framegrabber brauche ich schnell mal eine Woche oder mehr Vollzeitarbeit um den wenigstens ein klein wenig in LabVIEW zum Laufen zu bringen.

Ausser wenn Du entweder spezielle Hardware hast die mit NI Mitteln nicht zu erfüllen sind, oder absehbar mehr dann eine handvoll derselben Framegrabber einsetzen wirst, macht das Verwenden eines nicht NI Framegrabbers in LabVIEW ökonomisch einfach keinen Sinn.

Mit wieviel rechnest Du Deine Zeit an? Wenn das einigermassen real ist, kannst Du mit dem Betrag den Du los wirst um dieses Problem zu lösen gleich ein dutzend NI Framegrabbers anschaffen. Mit der Hälfte dieses Betrages machte ich Dir einen LabVIEW Treiber, der grundlegende Funktionalität unterstützt.

Zudem kannst Du auch noch auf dem Web suchen und dann kommst Du zum Beispiel bei http://www.alliancevision.com die eine VI Library für bestimmte Matrox Produkte anbieten.

' schrieb:Gerade eine Antwort von alliancevision bekommen: Das benötigte Toolkit würde mich 535€ (vor Zoll) kosten. Hinzu kommt, dass IMAQ Vision von NI benötigt wird. Wenn ich das richtig verstanden habe, dann ist das hier gemeint.

' schrieb:Und wenn ich das ganze richtig interpretiert habe, dann wäre dieser softwareteil immerhin kostenlos. Hmhm... das sollte allerdings bloß als Notlösung fungieren.
Ich würde es dennoch gerne irgendwie schaffen ohne extra tools anzuschaffen
Eine weitere "Notlösung" wäre das anschaffen einer Kamera die direkt an USB oder Firewire angeschlossen wird und bereits VIs für LabVIEW mitbringt. Allerdings habe ich so die Befürchtung, dass diese Option nochmals teurer wird, weshalb ich mit meinem Problem immernoch nicht weiter gekommen bin.