' schrieb:Ja, aber zur api32.dll und die habe ich auch schon mal ausgetauscht und sichergestellt dass der Pfad korrekt ist.
Aber ich wüsste auch nicht was da dann so einen Fehler verursacht, oder fällt dir da was ein?
Ich hab davor schon ein Programm mit EDIABAS VIs geschrieben, da hatte ich garkeine Probleme.
Allerdings war mein Programm nicht annährend so komplex und auch ohne Events.
Ich versteh halt nicht warum das alte Prog. das Problem nicht hat, muss was mit der Darstellung als Tabelle oder den Doppelklick-Events zu tun haben.
Wüsste aber nicht was.
Trozdem danke.
Zum Beispiel eine falsch konfigurierte Call Library Node die nicht mit der aufgerufenen Funktion übereinstimmt. Oder was ein ganz beliebter Fehler ist bei Call Library Node Benützern ist um zu "vergessen", dass C Pointer durch den Aufrufer auf die nötige Länge alloziert werden müssen. Das heisst wenn da irgendwo ein Buffer ist in dem die DLL Informationen zurückgeben soll, muss der in Deinem LabVIEW Diagramm genügend gross angelegt werden. Dies geht zum Beispiel sehr gut mit der Initialize Array Funktion.
Wenn der Buffer zu klein ist kann die DLL über das Ende des Buffers schreiben und damit andere wichtige Informationen im Speicher zerstören. Das braucht nicht unmittelbar zu crashen, da der Bereich direkt hinter einem Buffer nicht automatisch benützt sein muss aber früher oder später muss das einmal krachen.
LabVIEW ist entgegen der Meinung einiger Leute hier wirklich sehr stabil. Wenn Du dann ein Projekt hast wo Du eine DLL mittels Call Library Node anrufst würde ich bei Crashes, Access Violations, und dergleichen grundsätzlich immer erst diese DLL Aufrufe verdächtigen bevor ich auch nur in Erwägung ziehe, dass LabVIEW das irgendwie selber macht. Und meine jahrelange Erfahrung auch mit Interfacing nach DLLs in LabVIEW bestätigt diese goldene Regel 100%.
Hier auch gleich eine Warnung an alle die Call Library Node VIs schreiben. Nur weil es nicht kracht heisst das noch lange nicht dass es alles perfekt ist. Zu klein allozierte Ausgabebuffer für Funktionen ist ein wirklich beliebter Fehler. So kann es lange gut gehen, weil zum Beispiel bei den Tests immer nur ein kurzer String von der Funktion zurück kommt, aber wenn dann in der Produktion plötzlich ein realer String zurückkommt geht es schief.
Oder die DLL schreibt zwar frisch fröhlich über das Ende des Buffers aber da der Speicher unmittelbar danach in diesem Moment nicht benützt ist geht es gut. Kleinste Änderungen am LabVIEW Diagramm erzwingen aber eine Rekompilation und plötzlich ist das Memorylayout anders angeordnet und BUMMS.
Eine andere Möglichkeit ist dass die DLL zwar gültige Daten überschreibt die aber im Moment nicht benötigt werden. Zum Beispiel die internen Verwaltungsstrukturen des Tabellenkontrolls. Wenn LabVIEW dann ein Displayupdate für das Kontroll machen will krachts halt wieder.
Oder die zerstörten Daten werden während der Runtime gar nicht benötigt sondern erst später wenn Du eine Editoperation an einem VI machst, oder gar erst wenn Du LabVIEW abschliesst und es beim ordentlichen Aufräumen aller allozierten Speicherlemente über durch die DLL ungültig gemachte Pointer stolpert.
Jeder dieser genannten Fehlerfolgen kann selbst durch kleine Änderungen an dem LabVIEW Programm plötzlich in einen der anderen Folgen veränderen. Auch eine Möglichkeit die ich öfters sah ist,dass es im Entwicklungssystem normal scheinbar gut ging aber in einer Build Applikation plötzlich crashte.
Deshalb an jeden der mit der Call Library Node arbeiten will und diese VIs in ein Produktionssystem einbauen will: Sorgfältig arbeiten, die nötigen C Kenntnisse erlernen, und Testen, Testen, Testen, Testen!!!
Rolf Kalbermatter
