Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
dies ist mein erster Post in diesem Forum, bitte weist mich auf fehlende Informationen hin, danke!
Ich habe ein Problem mit der Initalisierung eines Arrays in Labview. Ich verwende eine DLL, dieser übergebe ich den Zeiger auf einen Unsigned 32bit Integer (in Form einer numerischen Konstante in Labview) und über die Parametereinstellung "Zeiger auf Wert" in der VI zum Aufruf externer Bibliotheken. Als Rückgabe erhalte ich von der DLL einen Unsigned 8bit Integer, welcher als Dimensionsgröße meines zu initialisierenden Arrays dienen soll. Leider stürzt das Programm (vermutlich an dieser Stelle) ab. Und zwar scheinbar abhängig davon, ob ich die Numerische Konstante (welche ich als Pointer an das VI übergebe) mit "0" festlege (kompletter Programmabsturz) oder einer anderen Zahl (z.B. "5"), dann gibt es eine Meldung, dass der Speicher voll sei. Wenn ich eine andere Zahl als 0 wähle, kann ich mir das initialisierte Array ausgeben, allerdings ist die Länge scheinbar nicht, oder nur teilweise, durch die DLL beeinflusst (bei 5 ist das Array auch nur 5 lang, bei größeren Werten ändert sich die Länge allerdings seltsamerweise).
Kann mir jemand sagen, wo das Problem liegen könnte?
dies ist mein erster Post in diesem Forum, bitte weist mich auf fehlende Informationen hin, danke!
Dann lass Deinen Code doch mal sehen! Prosa ist schön und gut aber hilft in solchen Dingen nur sehr eingeschränkt, um sich ein Bild machen zu können, was Du denn genau getan hast und wo das Problem eventuel liegen könnte.
(28.08.2012 09:34 )Forti schrieb: allerdings ist die Länge scheinbar nicht, oder nur teilweise, durch die DLL beeinflusst (bei 5 ist das Array auch nur 5 lang, bei größeren Werten ändert sich die Länge allerdings seltsamerweise).
Hast du die DLL selbst geschrieben oder verwendest du sie nur?
Einfach mal den Code posten, dann kann dir der 'Lord of DLLs' (aka rolfk) weiterhelfen
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Leider verwende ich sie nur. Es handelt sich um eine PVCAM software zur Kamerasteuerung. Ich kann euch da also leider keinen Code Zeigen. Oder meint ihr etwas anderes?
Ist der Wert den ich in meine numerische Konstante schreibe überhaupt relevant, oder sollte er das sein?
Ich habe mal meine VI als Attachment hinzugefügt.
Dies ist aus der Header Datei der DLL, und ich glaube an dieser Stelle in der VI tritt der Fehler auf:
(29.08.2012 08:04 )Forti schrieb: Leider verwende ich sie nur. Es handelt sich um eine PVCAM software zur Kamerasteuerung. Ich kann euch da also leider keinen Code Zeigen. Oder meint ihr etwas anderes?
Ist der Wert den ich in meine numerische Konstante schreibe überhaupt relevant, oder sollte er das sein?
Ich habe mal meine VI als Attachment hinzugefügt.
Dies ist aus der Header Datei der DLL, und ich glaube an dieser Stelle in der VI tritt der Fehler auf:
Ich dachte sowohl an die LabVIEW VIs als auch an die Header Files! Was steht dort drin als Deklaration für rgn_const_ptr? Die anderen Parameter sind auch alles custom types aber ich vermute (hoffe) mal dass die gewählten Namen sinngemäss sind, aber das ist immer so eine Sache mit Annahmen. Viele Programmierer haben da so ihre eigenen Ideen die manchmal ziemlich unlogisch erscheinen können.
Zudem muss der Fehler nicht unbedingt in der Funktion liegen wo es crasht, sondern kann auch davor irgendwo geschehen sein, nur stolpert vielleicht erst diese Funktion über allenfalls inkonsistente Daten.
Zum Beispiel ist der Aufruf von pl_cam_get_name() mit einem leeren String als zweiten Parameter ein garantierter Fall von direktem oder indirektem Crashprovozierer. Wenn Du eine C Funktion aufrufst kann die nicht nach Bedarf Speicher reallozieren so wie das in LabVIEW überall passiert, sondern Du musst ihr für alle Parameter genug Speicher verfügbar stellen, in den sie dann schrieben kann. Das kann am einfachsten in der CLN Konfiguration mit dem Minimum Size value für diesen Parameter, aber ich ziehe eine explizite Initialisierung im Diagramm vor mittels Initialize Array und Byte Array to String Funktion, da die Konfiguration dieses sehr wichtige Detail ziemlich gemein versteckt.
Wie gross dieser Buffer sein muss musst Du der Dokumentation entnehmen. Die Library wird intern irgend einen Maximum size verwenden für die Namen und das ist dort dokumentiert. Niemand anders kann Dir das sagen.
Selbiges Problem natürlich auch für pl_error_message()!
ok, ich habe es "zum laufen" gebracht (das Problem war eine falsche Angabe des Modes in der VI), ich danke euch für eure Mühe
Ich werde mir auch die von dir genannten Punkte noch einmal anschauen (da das Programm hin und wieder abstürzt und ich noch suche woran es liegen könnte)
(29.08.2012 10:12 )Forti schrieb: Ich werde mir auch die von dir genannten Punkte noch einmal anschauen (da das Programm hin und wieder abstürzt und ich noch suche woran es liegen könnte)
Buffer overrun Fehler (denn das ist es eigentlich wenn Du einer Funktion zu kleine Buffer übergibst und diese Funktion dann über das Ende des allozierten Buffers schreibt) sind eine typische Ursache von sporadischen Crashes. Je nachdem was die Funktion gerade überschreibt kann es im Glücksfall gleich crashen, oder irgendwann mal später, etwa beim Abschliessen des Programmes wenn LabVIEW versucht alle Resourcen ordnungsgemäss freuizugeben und dann über die zerstörten Pointer im Speicher stolpert, oder im schlimmsten Fall crasht es gar nicht. Und ich sage hier bewusst "im schlimmsten Fall" denn das sind die Fehler die entweder Variablen überschreiben so dass Dein mehr oder weniger komplizierter Algorithmus völlig idiotische (oder auch nur ganz leicht falsche) Resultate liefert oder urplötzlich doch crasht, wenn Du scheinbar kleine Anpassungen an der Applikation gemacht hast die die Reihenfolge und Anordnung von Elementen im Speicher verändert hat, so dass nun plötzlich doch ein Fehler oder Crash auftritt. Und da dann auf die Idee zu kommen alle DLL Aufrufe nochmals gründlich zu checken, statt den Fehler in den letzten Änderungen zu suchen ist oft nicht ganz vor der Hand liegend, aber die einzige richtige Lösung.
Deshalb tendiere ich immer mehr zu der Meinung: Wer mit der Call Library Node rumspielt ohne wirklich SEHR genau zu wissen was er tut, und das Resultat dann in eine Produktionssoftware übernimmt, handelt eigentlich grobfahrlässig. Wenn die Applikation nur ein Messdatenfile produziert, kann das im schlimmsten Fall bedeuten, dass die damit erfassten Daten alle wertlos sind, also eine mehr oder weniger grosse finanzielle Katastrophe. Aber wenn dieselbe Applikation auch Motion und was noch mehr enthält und bei einer Fehlfunktion potentiel Menschenleben gefährden kann, dann ist es schlichtweg unverantwortlich.
/
Array initalisieren über DLL Funktion
