' schrieb:Guckst du Bild: Der DLL-Knoten im SubVI NCDT2401-GetError ist falsch konfiguriert. Die Funktion in der DLL erwartet einen Pointer auf einen Speicherbereich. Der Bereich muss aber auch vorhanden sein! Das wird dadurch gewährleistet, dass im DLL-Knoten für die "Mindestlänge" des "C-String-Zeigers" der Werte "maxlen" ausgewählt werden muss.
Probiers mal aus und sag Bescheid.
Das ist wirklich ein sicherer Weg um komisches Verhalten und Abstürze zu verursachen. Leider ist die maxlen Konfiguration erst von LabVIEW 8.2 (oder war das 8.5?) an verfügbar. In 6.1 wird dem OP nichts anderes übrig bleiben dann ein Array von Bytes mit genügend Anzahl Bytes zu initialisieren (Initialize Array) und diese mit Byte Array To String in einen Stringbuffer zu verwandeln.
Wenn sowas in dieser Funktion drin ist wird der selbe Fehler wohl auch anderswo vorkommen und das ist beinahe 100% der Grund für dieses komische Verhalten.
Und sag nicht dass kann in Delphi nicht passieren! :DKann nämlich schon! Nur muss man da für alle Buffer selber sicherstellen dass sie alloziert und gross genug sind, während das in LabVIEW normalerweise nicht nötig ist. Aber im Falle der Call Library Node kann LabVIEW leider nicht per Telepathie den Programmierer der DLL kontaktieren, um ihn zu fragen welche Buffergrösse denn wohl gross genug sei und deshalb wurde entschieden hier gar nichts selbst zu tun, statt etwas dass manchmal zufällig gerade gross genug ist oder immer viiiiiiiiiieeeeel zu gross.
PS: Habe gesehen dass es in LabVIEW 8.2 jetzt zu laufen scheint.
Muss aber hier gleich warnen: Wenn der Fehler irgendwo durch einen zu kleinen Ausgangsbuffer zur DLL verursacht wird, so wie bei obigem ErrorQuery VI, dann braucht die Tatsache dass es nun geht noch gar nichts zu beweisen. In einem solchen Fall überschreibt die DLL einfach irgendwo Speicher den sie nicht überschrieben darf.
Das kann je nach dem unmittelbar zum Absturz führen, bei irgendeiner späteren Funktion im Programm, nur wenn man ein LabVIEW Menu auswählt, erst wenn man die Applikation oder gar LabVIEW abschliesst, in Version X schon und Version Y zufällig nicht, komische Resultate in irgend einer LabVIEW Funktion verursachen, lange gut gehen und bei einer kleinsten Veränderung am Programm plötzlich konsistent crashen, oder im Highlight Mode schon aber normal nicht und umgekehrt. Es wäre also schon Sache um dem auf den Grund zu gehen.
Die Tatsache dass die Error Query Funktion so einen Bug besass lässt mich schwer vermuten, dass derjenige der diese Library geschrieben hat von diesen Problemen nicht so viel Ahnung hatte und nach dem Motto: Es läuft endlich ohne zu crashen, den Treiber ganz schnell als released erklärt hat.
' schrieb:Das muss mit den Enums auch gehen. Mag sein, dass da 6.1 einen Bug hat. Kannst du nicht auf was neueres Updaten: 8.5, 8.2 oder wenigstens 7.1.1 ?
Kein Bug soweit ich weiss aber es könnte schon sein dass wenn Du die Defaultgrösse einer Enum verwendest (U16) und die DLL hier eine 32 Bit Integerzahl erwartet LabVIEW in manchen Versionen nur die niegrigswertigsten 16 Bit richtig initialisiert und den Rest so stehen lässt wie er halt im Moment im entsprechenden Register ist. Das ist aber kein Bug, zumindest in LabVIEW
. Ob man ein Register erst ganz löscht bevor man es initialisiert und dann auf den Stack schiebt ist eine Ansichtssache. Manche finden die 1 ns Zeitverzögerung um das Register erst zu löschen eine Riesenzeitverschwendung, andere gehen nach dem Motte so konservativ möglich um alle möglichen Benützerfehler so gut möglich zu vermeiden. Beide Lager haben hier ihre Berechtigung auch in LabVIEW. Da DLL Interfacing ohnehin nicht etwas Triviales ist, ist es nicht unbedingt abwegig vom entsprechenden Programmierer zu erwarten dass er solche Unterschiede berücksichtigt.
Rolf Kalbermatter
/
DLL liefert versch. Errorcodes (Highlight-Modus AUS/Highlight-Modus AN)
