+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: Debugging externer DLL (/Thread-Debugging-externer-DLL)
Debugging externer DLL - Tom_UniMainz - 10.05.2008 11:19
Hallo zusammen !
Ich bin in der LabVIEW-Welt relativ neu und habe einige Schwierigkeiten. Wir steuern mit LabVIEW eine selbstentwickelte Hardware und die Schnittstelle stellt eine ebenfalls selbstentwickelte DLL dar. Im Zusammenhang mit dieser DLL haben sich zwei Probleme ergeben:
1) Ich müsste während der Laufzeit die DLL schrittweise debuggen nachdem sie von LabVIEW geladen und aufgerufen wurde. Ist das möglich und falls ja wie ?
2) Nach dem Beenden des VI scheint die externe und geladene DLL irgendwie noch "aktiv" zu sein. Ein Neuladen der DLL funktioniert nur, nachdem man LabVIEW komplett geschlossen und wieder neu geöffnet hat. Wo liegt das Problem ?
Vielen Dank !
Thomas...
Debugging externer DLL - rolfk - 13.05.2008 10:30
' schrieb:Hallo zusammen !
Ich bin in der LabVIEW-Welt relativ neu und habe einige Schwierigkeiten. Wir steuern mit LabVIEW eine selbstentwickelte Hardware und die Schnittstelle stellt eine ebenfalls selbstentwickelte DLL dar. Im Zusammenhang mit dieser DLL haben sich zwei Probleme ergeben:
1) Ich müsste während der Laufzeit die DLL schrittweise debuggen nachdem sie von LabVIEW geladen und aufgerufen wurde. Ist das möglich und falls ja wie ?
2) Nach dem Beenden des VI scheint die externe und geladene DLL irgendwie noch "aktiv" zu sein. Ein Neuladen der DLL funktioniert nur, nachdem man LabVIEW komplett geschlossen und wieder neu geöffnet hat. Wo liegt das Problem ?
1) Wenn Du eine aktuelle LabVIEW Version hast kannst Du extFuncCatching=False in Dein LabVIEW.ini File setzen und das sollte den LabVIEW Exception Dialog vermeiden und anstelle davon die Möglichkeit bieten um den registrierten SystemDebugger aufzurufen bei einer Exception. Ausser Fehlerexceptions kannst Du dann auch zum Beispiel einen {__asm int 3} User breakpoint in Deinem Code haben.
Alternativ in der Visual C IDE LabVIEW.exe als externes Executable zum Debuggen Deiner DLL angeben. Breakpoint in IDE setzen wo Du willst und dann Execute auswählen.
2) Solange das VI im Speicher ist hat es auch eine Referenz zur DLL offen. In LabVIEW 8.2 und neuer kannst Du aber den Path zur DLL als Parameter der Call Library Node angeben. Bei Übergabe eines leeren Paths wird die zuletzt geladenen DLL aus dem Speicher entfernt. Damit hast Du direkte Kontrolle über wann die DLL geladen und ausgeladen wird.
Rolf Kalbermatter
Debugging externer DLL - abrissbirne - 08.07.2008 14:59
' schrieb:Alternativ in der Visual C IDE LabVIEW.exe als externes Executable zum Debuggen Deiner DLL angeben. Breakpoint in IDE setzen wo Du willst und dann Execute auswählen.Das ganze sieht dann so aus:
Rolf Kalbermatter
Edit:
Du solltest unter Configuration: -> All configurations und unter Platform: Win32 wählen. Da war ich mal wieder zu schnell.
Debugging externer DLL - martinv - 20.07.2009 16:58
' schrieb:2) Solange das VI im Speicer ist hat es auch eine Referenz zur DLL offen. In LabVIEW 8.2 und neuer kannst Du aber den Path zur DLL als Parameter der Call Library Node angeben. Bei übergabe eines leeren Paths wird die zuletzt geladenen DLL aus dem Speicher entfernt. Damit hast Du direkte Kontrolle über wann die DLL geladen und ausgeladen wird.
Ich habe nicht ganz verstanden, wie das funktioniert. Ich habe eine Call Library Node eingebaut, die aufgefufen wird, wenn die .dll nicht mehr richtig funktioniert (dies geschieht bei meinem Programm ab und zu) Die Funktion enthaelt nur einen Rueckgabewert. Als Pfad habe ich eine Pfadkonstante angegeben, die keine Buchstaben enthaelt. Dennoch verschwindet das Problem dadurch nicht, weshalb ich glaube, dass ich da noch immer etwas falsch mache. Was habe ich das falsch verstanden?
Debugging externer DLL - rolfk - 22.07.2009 07:31
Tritt das Problem auch auf wenn Du alle VIs sauber abgeschlossen und aus dem Speicher entfernt hast? Dann macht Deine DLL selber wohl etwas Unorthodoxes das sie auf diese Weise im Speicher behält. Ein LoadLibrary Call auf sich selber wäre beispielsweise schon genug.
Rolf Kalbermatter