Unzulässiger Zugriff auf Speicherbereich

Hallo LabVIEW-Gemeinde,

ich habe diesmal folgendes Problem:
Im Zuge meiner Masterarbeit arbeite ich mit einer programmierbaren Lichtquelle. Die Treiber der Lichtquelle sind etwas veraltet; wenn ich sie im Instrumentenverzeichnis kopiere (dll und llb) und die Funktionen das erste Mal ins Blockdiagramm setze, muss ich wenn ich das Programm anschließend schließe, die genutzen Funktionen neu abspeichern (unter 2011), andernfalls werden sie aus dem Speicher entfernt (siehe Bild 1). Mir bleibt also keine andere Option...
Wenn ich nun das Programm neu lade, oder auch LabVIEW beende und neu starte und anschließend das Programm lade, passiert erstmal nichst Schlimmes... Alle Funktionen noch da und auch keine Fehlermeldung. Nun führe ich das Programm aus. Alles klappt, ich kann die Lichtquelle problemlos ansteuern. Bis hier hin ist alles toll...
Nun kommt einmal der Zeitpunkt wo man fertig ist und das Programm beende. Wenn ich es aber das nächste Mal neu lade, kommt folgende Fehlermeldung (siehe Bild 2). Das Programm kann nicht mehr ausgeführt werden weil der Bezug zur dll fehlt... (siehe Bild 3)
Was geht da intern ab und wie kann ich das verhindern?

Ich verwende LabVIEW 2011.

Viele Grüße,
stud12

Anzeige

So ins Blaue rein: Du machst irgendetwas falsch beim Laden/Entladen der DLL über deine VIs. Was genau,

Gruß, Jens

Hallo,

ich hab mal noch ein wenig rumgestöbert und musste feststellen, dass ich nicht der einzige mit diesem Problem bin.

Nochmal das Problem in Kurzform:
Fehlermeldung "Ungültiger Zugriff auf einen Speicherbereich" nachdem VI geöffnet wurde und erfolgreich lief, anschließend geschlossen wurde und später erneut geladen werden soll.

In folgenden zwei Links wird das selbe Problem beschrieben und auch gleich eine Erklärung inklusive Lösung besprochen. Allerdings verstehe ich nur Bahnhof... Liegt weniger an meinen Englischkenntnissen, sondern wohl mehr an meinem oberflächlichen LabVIEW-Wissen.

Hab zu jedem Link auch gleich die Lösung des Problems herauskopiert, damit ihr nicht erst die ganze Diskussion lesen müsst...


Link 1

Erklärung/Lösung:
It relates to our dll structure. We create a message pump in the dll associated with a hidden window. When the dll is initialized, the window is registered with the operating system. When the dll is unloaded, the window is closed but we weren't de-registering it. This caused the problem the second time the dll was loaded. By de-registering when the dll is unloaded, the problem has been solved.


Link 2

Erklärung/Lösung 1:
The problem was threading. LabVIEW does not currently have the capability to handle multithreaded DLLs properly. The calling application would create a thread, run the DLL, then destroy the thread. When it was run again, the thread creation process was not able to proceed as it should have.

Erklärung/Lösung 2:
DLLs created by LV need a number of resources to carry out execution. The problem here is that the first time LV is called, the thread it is called with will be adopted as its UI thread. The LV execution system will create windows in that thread, and if the thread is later destroyed, it will cripple the LV execution system since it cannot have anything execute in the UI thread. This is why some VIs will work fine while others will not.
If the rest of your app relies on this create/call/destroy architecture, just make sure that the first call or th
e LoadLib is in a different thread that satisfies these requirements. You can then make the DLL calls in any thread that you like and destroy them any way that you like.


Was ist hier mit "Thread" gemeint, und was stimmt mit dem nich?
So ungefähr versteh ich das Problem jetzt ein bisschen, aber ich hab nicht den Hauch einer Ahnung wie ich mit dem Wissen das Problem jetzt umgehen kann...

Danke schonmal im Voraus und Sorry für den vielen Text...

PS: Ein Bildchen vom Blockdiagramm würde euch bestimmt gefallen... Hole ich nach, sobald ich im Labor bin

Wie versprochen, anbei ein Screenshot des Blockdiagramms, vielleicht hab ich ja einfach nur wieder was falsch programmiert...
Die orangen Funktionen gehören zu nem Powermeter und haben mit der Sache nix zu tun.

Viele Grüße

Mit deinem zweiten Link bist du definitiv auf dem Holzweg. Du rufst aus LabVIEW eine "fremde" DLL auf.

Ist die DLL korrekt installiert? Vielleicht braucht es mehr als Copy-Paste (-> Hersteller nachfragen!)
Passt deine DLL zur Firmware deiner Lichtquelle ( http://www.onelightcorp.com/support/software/ ) ?

Laut Onelightcorp Seite gibt es eine Steuersoftware von Hersteller selber. Läuft die?

Gruß, Jens

DLL ist meiner Meinung nach korrekt installiert. Genau so gemacht wie beschrieben. dll und llb hab ich in einem Ordner, desweiteren gibts noch ne .ini und ne .sys im entsprechenden system32-Unterverzeichnis, damit dass ganze übern USB-Port fehlerfrei läuft.
Das Gerät war eines der ersten. Firmware immer noch die von damals, Updates wären nur noch nach Kontakt mit Hersteller möglich (siehe die von dir angegebene Website). Treiber sind ebenfalls die damals zugehörigen.

Es gibt eine Anwendung (.exe) die läuft egal wie oft ich sie ausführe und wie oft ich die Anwendung schließe und neu starte; ich kann immer die Lichtquelle ansteuern.
Genau die gleiche Anwendung is im Treiberpaket nochmals als .vi enthalten (halt nur nich in .exe umgewandelt), und hier genau das selbe Problem: einmal läufts, dann will LabVIEW beim Beenden, dass ich alle darin enthaltenen Funktionen neu abspeichere (auf die 2011er Version). Beim nächsten Start funktionierts nich mehr.
Auch andersrum würde es nich klappen, sprich Programm öffnen, gleich wieder schließen und vorher die Funktionen konvertieren. Dann Programm neu öffnen, einmal starten und wieder schließen. Beim nächsten Mal tritt dann der Fehler auf. Es scheitert also immer die zweite Ausführung des Programmes. Das Konvertieren scheint keinen Einfluss zu haben, weil ichs nach Variante 2 ja auch zumindest einmal ausführen kann.

Vielleicht helfen euch diese Infos weiter:
Info1:
Wenn ich das nun funktions-unfähige VI lösche und durch das gleiche ersetzte, welches ich noch in nem Backup-Ordner drin hab, dann bietet sich mir zunächst nochmal die Möglichkeit, die zugehörige dll über ein Dialogfeld auszuwählen, bekomme dann aber wenn er die dll für das neue programm laden will die Fehlermeldung: "Eine DLL-Initialisierungsroutine ist fehlgeschlagen"

Info2:
die .exe-Datei läuft weiter problemlos, obwohl ich im Dialogfeld bein Programmstart jedesmal die selbe DLL auswähle, die auch versucht wird aufzurufen, wenn das VI geladen wird (dann aber halt mit Fehlermeldung "Unzulässiger Zufriff auf einen Speicherbereich").... und das wundert mich am meisten...

Anzeige

(12.10.2012 10:13 )stud12 schrieb:  DLL ist meiner Meinung nach korrekt installiert. Genau so gemacht wie beschrieben. dll und llb hab ich in einem Ordner, desweiteren gibts noch ne .ini und ne .sys im entsprechenden system32-Unterverzeichnis, damit dass ganze übern USB-Port fehlerfrei läuft.
Das Gerät war eines der ersten. Firmware immer noch die von damals, Updates wären nur noch nach Kontakt mit Hersteller möglich (siehe die von dir angegebene Website). Treiber sind ebenfalls die damals zugehörigen.

Es gibt eine Anwendung (.exe) die läuft egal wie oft ich sie ausführe und wie oft ich die Anwendung schließe und neu starte; ich kann immer die Lichtquelle ansteuern.
Genau die gleiche Anwendung is im Treiberpaket nochmals als .vi enthalten (halt nur nich in .exe umgewandelt), und hier genau das selbe Problem: einmal läufts, dann will LabVIEW beim Beenden, dass ich alle darin enthaltenen Funktionen neu abspeichere (auf die 2011er Version). Beim nächsten Start funktionierts nich mehr.
Auch andersrum würde es nich klappen, sprich Programm öffnen, gleich wieder schließen und vorher die Funktionen konvertieren. Dann Programm neu öffnen, einmal starten und wieder schließen. Beim nächsten Mal tritt dann der Fehler auf. Es scheitert also immer die zweite Ausführung des Programmes. Das Konvertieren scheint keinen Einfluss zu haben, weil ichs nach Variante 2 ja auch zumindest einmal ausführen kann.

Vielleicht helfen euch diese Infos weiter:
Info1:
Wenn ich das nun funktions-unfähige VI lösche und durch das gleiche ersetzte, welches ich noch in nem Backup-Ordner drin hab, dann bietet sich mir zunächst nochmal die Möglichkeit, die zugehörige dll über ein Dialogfeld auszuwählen, bekomme dann aber wenn er die dll für das neue programm laden will die Fehlermeldung: "Eine DLL-Initialisierungsroutine ist fehlgeschlagen"

Info2:
die .exe-Datei läuft weiter problemlos, obwohl ich im Dialogfeld bein Programmstart jedesmal die selbe DLL auswähle, die auch versucht wird aufzurufen, wenn das VI geladen wird (dann aber halt mit Fehlermeldung "Unzulässiger Zufriff auf einen Speicherbereich").... und das wundert mich am meisten...

Das sieht nach einer ActiveX DLL aus, oder zumindest macht sie intern Gebrauch von ActiveX und die Programmierer dieser DLL haben die Feinheiten von der Verwendung von ActiveX innerhalb eines miltithreaded Programmes noch nicht ganz begriffen. LabVIEW ist grundsätzlich multithreaded und die einzige Möglichkeit um das beim Aufruf einer DLL zu verhindern ist um alle Call Library Nodes so zu konfigurieren dass diese im UI Thread ausgeführt werden. Das kann aber je nach Situation wieder andere Probleme mit sich mitbringen. Da ich die entsprechende DLL nicht kenne kann ich das nicht beurteilen, aber grundsätzlich lässt sich sagen, dass die verwendete ActiveX Componente wahrscheinlich als sogenannte Apartement Threading DLL registriert ist. Das besagt im wesentlichen dass die Aufrufe in die ActiveX Server DLL immer vom gleichen Thread aus erfolgen müssen. Die einzie Art und Weise um das in LabVIEW zu garantieren ist um entweder in der Wrapper DLL selber diese Threadsynchronisation zu tun (aber das ist noch schwieriger dann eine ActiveX Componente zu schreiben die echt Free-Threading ist), oder aber in LabVIEW all Call Library Nodes so zu konfigurieren dass sie im UI Thread ausgeführt werden (dann macht LabVIEW das Ganze mit der Einschränkung dass es im speziellen UI Thread passiert und wenn die DLL oder ActiveX Komponente sich selber dabei blockiert auch LabVIEW komplet unbedienbar wird.

Grundsätzlich ist einfach zu sagen dass der Treiberhersteller die Feinheiten von Multithreadingprogrammierung zumindest noch nicht ganz begriffen hat. In Visual Basic läufts ja, also ist LabVIEW das Problem!!! Aber er vergisst dabei dass die meisten Visual Basic Programmierer nicht mal in die Nähe von Multhreading Programmen kommen und seine schöne Komponente halt einfach grundsätzlich Singelthreaded angesprochen wird, somit dass Problem nicht darin liegt dass LabVIEW grundsätzlich Multithreaded ist, sondern darin dass seine Componente mit multithreading Probleme hat.