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!
' schrieb:Ich wage - wieder mal - zu sagen, dass es geht.
Als ob ich es nicht damals schon gewust hätte: Es hat nicht funktioniert, das mit dem "Immer kopieren".
Die damalige Konfigurationsdatei enthielt ca. 13 Kanäle pro Sample. Mit dem "Immer kopieren" hat diese Konfiguration immer funktioniert. Da konnte ich machen, was ich wollte: kein Absturz mehr.
Jetzt hat der Kunde aber eine Konfigurationsdatei gemacht mit nur noch 7 Kanäle pro Sample - und siehe da: Das mit dem "Immer kopieren" geht nicht mehr. Jetzt kommt verstärkt die Absturzvariante ohne jedwede Anzeige, dass gerade abgestürzt wird. Ja, was jetzt tut?
[*programmier*]
Natürlich hab ich schon wieder eine neue Lösung. Nur: Beim Programmieren gilt: Wenn was funktionirt, heißt das noch lange nicht, dass es richtig geht. Nur wenn etwas nicht richtig geht, weis man: es funktioniert nicht.
Wenn ich mir die neue Lösunbg mal durch den Kopf hab gehen lassen, sag ich wieder Bescheid.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Wenn ich mir die neue Lösunbg mal durch den Kopf hab gehen lassen, sag ich wieder Bescheid.
[*Bescheid*]
Ich hab die Lösung mal angehängt. Das konstante, leere Array am Eingang des DLL-Knotens für den Array-Handle musste ich nachrüsten. Seitdem geht es - mal wieder. Natürlich ohne "immer kopieren".
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
29.01.2008, 12:40 (Dieser Beitrag wurde zuletzt bearbeitet: 29.01.2008 12:40 von rolfk.)
' schrieb:[*Bescheid*]
Ich hab die Lösung mal angehängt. Das konstante, leere Array am Eingang des DLL-Knotens für den Array-Handle musste ich nachrüsten. Seitdem geht es - mal wieder. Natürlich ohne "immer kopieren".
Ouch, ich glaub ich habe eine Idee! Wenn es das Hinzufügen der Arraykonstante ist, dann tut der DLL Knoten was falsch. Da das Array einfach als Array Handle definiert ist, darf LabVIEW nicht einfach eine NULL an die DLL geben. LabVIEW dürfte und würde das tun wenn es ein Array Handle Pointer ist, da es davon ausgeht dass die aufgerufene Funktion smart genug ist um in dem Falle selber ein Handle zu generieren. Bevor LabVIEW 8.2 oder 8.5 (bin gerade nicht mehr sicher) war es nicht zulässig um einen Eingangsparameter and einem Bibliotheksknotenpunkt unwired zu lassen, ausser eventuel für Array Handle Pointers. Seither geht das und sollte LabVIEW dann halt in diesem Fall selber ein leeres 2D Array erzeugen und an die Funktion übergeben. Hier geht wohl etwas falsch.
Ich muss dazu sagen, dass mir dieser Fehler nie passieren würde, da ich auch in 8.5 niemals einen Bibliotheksknotenparameter an der linken Seite unwired lasse. Da dies aber ein NI VI ist bin ich schon etwas beunruhigt was denn hier genau falsch geht.
Es ist ganz sicher ein Bug, in erster Instanz im Bibliotheksknoten aber in Anwesenheit dieses Fehlers auch in der CAN Library.
Na, da bin ich ja beruhigt, dass wenigstens ein Experte (den Kaufleuten und Vertretern glauch ich sowieso nix mehr) meine Beobachtungen nachvollziehbar erklären kann.
Für mich heißt das jetzt aber auch, dass ich alle verwendeten CAN-Vi's mal prüfen sollte. Offensichtlich abstürzen tut eigentlich nichts mehr. Nur manchmal geht Can-Stopp nicht, dann wieder Can-Start oder Can-SetProperty.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
