Konstante nicht konstant?!

Moin!

Ich habe ein umfangreicheres VI erstellt, das im Prinzip einwandfrei läuft. In einem Punkt allerdings treibt mich LabVIEW (Version 7.1) in den Wahnsinn: In einer Schleife wird ein Messgerät über VISA (GPIB) abgefragt. Der dazu an das Gerät gesendete Befehl ":read?" steht in einer String-Konstante. Die Antwort des Geräts wird dann über "In String suchen" zerlegt:

   

Ab und zu (leider recht häufig) kommt die Antwort des Messgeräts aber nicht an, das VI bricht die Ausführung mit einer Fehlermeldung ab. Wechsele ich nun in das Blockdiagramm, ist die String-Konstante nicht mehr mit dem Wert ":read?" belegt, sondern ein Leerstring. Der Fehler kommt also vermutlich daher, dass der ans Messgerät gesendete String leer ist, was keinen Rückgabewert ergibt, worauf "In String suchen" den Fehler bringt.

Wie bringe ich LabVIEW dazu, diese Konstante in Ruhe zu lassen!? Es kann ja nicht angehen, dass eine "Programmiersprache" an einer Konstanten zur Laufzeit nach Belieben rumpfuscht!

Etwas verzweifelte Grüße, TwisT

Anzeige

' schrieb:Wie bringe ich LabVIEW dazu, diese Konstante in Ruhe zu lassen!? Es kann ja nicht angehen, dass eine "Programmiersprache" an einer Konstanten zur Laufzeit nach Belieben rumpfuscht!

Bei allem was recht ist, aber das was Du denkst das gibt es nun wirklich nicht. Es muß dafür andere, vielleicht ganz triviale Gründe geben.
Hast Du denn das VI abgespeichert? Wenn ja, bist Du sicher, daß es auf Deinem PC nur dieses eine VI gibt, und das Du es nicht am Ort X abspeicherst und am Ort Y aufrufst? Oder ist das VI vielleicht schreibgeschützt? (das passiert leider von selbst, wenn das VI mal auf einer CD gespeichert war, und darauf tippe ich am ehesten) ).
Du kannst es ja auch mal versuchsweise mit neuem Namen abspeichern.

Manchmal verschwindet auch nur der Text, wenn das Fenster zu klein ist. Also mach mal das rosa Fenster um die Konstante größer. Schalte auch mal auf Code-Anzeige um, um zu sehen, ob Dein Text wirklich nur die gewünschten Zeichen enthält.

Ja. wem fällt noch etwas sein, was es sein könnte?

Moin!

Vielen Dank für Deine schnelle Antwort!

' schrieb:Bei allem was recht ist, aber das was Du denkst das gibt es nun wirklich nicht. Es muß dafür andere, vielleicht ganz triviale Gründe geben.

Das hoffe ich auch;)Leider ist das kein Einzelfall, auch einige Kollegen kämpfen mit dem selben Problem... Und es ist mehr oder weniger reproduzierbar, es tritt meistens nach einigen tausend Datenpunkten auf, manchmal nach 30k, manchmal nach 80k, einmal auch erst nach 140k. Auch bei dem Testlauf, den ich über Nacht laufen hatte, ist es wieder passiert. Gestern Abend ging alles, heute Morgen war die Konstante leer?!

Zitat:Hast Du denn das VI abgespeichert?

Jepp, mehrmals auch unter verschiedenen Namen. Genau genommen speichere ich jeden Tag die aktuelle Version unter einem neuen Namen, der auch das Datum enthält.

Zitat:Wenn ja, bist Du sicher, daß es auf Deinem PC nur dieses eine VI gibt, und das Du es nicht am Ort X abspeicherst und am Ort Y aufrufst?

Dieses VI gibt es nur einmal und ich rufe es direkt per Doppelclick auf. Das ist ein Mess-PC, auf dem außer LabVIEW auch praktisch keine andere Software installiert ist.

Zitat:Oder ist das VI vielleicht schreibgeschützt? (das passiert leider von selbst, wenn das VI mal auf einer CD gespeichert war, und darauf tippe ich am ehesten) ).

Nein, ist es nicht. Habe ich eben nochmals überprüft.

Zitat:Manchmal verschwindet auch nur der Text, wenn das Fenster zu klein ist. Also mach mal das rosa Fenster um die Konstante größer. Schalte auch mal auf Code-Anzeige um, um zu sehen, ob Dein Text wirklich nur die gewünschten Zeichen enthält.

Habe ich gemacht, da ist nichts. Auch keine ''-Codes. Ich habe jetzt testweise mal ein String-Anzeige-Element auf das Panel gepackt, das ich außerhalb der Schleife mit dem Wert ':read?' vorbelege, und den Inhalt dieses Elementes jetzt an das VISA-Write VI als Sende-String übergeben. Mal sehen, ob das hilft. Trotzdem kann es das ja nicht wirklich sein! Eine Konstante ist eine Konstante und sollte das auch bleiben.

Sehe ich das also richtig: Nachdem das Programm sich aufgrund eines Fehlers beendet hat, steht in dem rosa Kasten, in dem zu Anfang ":read?" steht, plötzlich nicht mehr ":read?" drinnen?

Was passiert in folgendem Falle: Das Programm bedendet sich. Du siehst in der Konstanten also nicht mehr ":read?" stehen. Daraufhin beendet du LV - ohne irgedendwas zu speichern! Jetzt öffnest du LV und das VI wieder. Steht jetzt wieder ":read?" drinnen - ich hoffe doch: ja.

Benutzt du Globale Variablen mit unsynchronisiertem Schreib/Lese-Zugriff?

' schrieb:Ich habe jetzt testweise mal ein String-Anzeige-Element auf das Panel gepackt, das ich außerhalb der Schleife mit dem Wert ':read?' vorbelege, und den Inhalt dieses Elementes jetzt an das VISA-Write VI als Sende-String übergeben. Mal sehen, ob das hilft.

Das könnte helfen - für diese eine Stringkonstante. Nur: Damit ist das Problem nicht gelöst. Möglicherweise wandert dann der "Fehler" z.B. auf die 70 gleich rechts daneben oder auf andere Stringskonstanten.

Ich sehe da eine Möglichkeit, wie so was passiert: Da schreibt einer auf Speicher, der ihm gar nicht gehört.

' schrieb:Sehe ich das also richtig: Nachdem das Programm sich aufgrund eines Fehlers beendet hat, steht in dem rosa Kasten, in dem zu Anfang ":read?" steht, plötzlich nicht mehr ":read?" drinnen?

Ganz genau: In "In String Suchen" fällt der Fehler an (ist klar, wenn der übergebene String leer ist) und das Programm bricht mit dem Fenster für Fehler ab (Auswahl "ok" oder "stopp"). Klicke ich auf "stopp" und schaue ins Blockdiagramm ist die Konstante leer, bei "ok" tritt der Fehler beim nächsten Schleifendurchlauf wieder auf.

Zitat:Was passiert in folgendem Falle: Das Programm bedendet sich. Du siehst in der Konstanten also nicht mehr ":read?" stehen. Daraufhin beendet du LV - ohne irgedendwas zu speichern! Jetzt öffnest du LV und das VI wieder. Steht jetzt wieder ":read?" drinnen - ich hoffe doch: ja.

Werde ich mal genauer ansehen. Bisher habe ich die Konstante wieder neu gesetzt und das Programm neu gestartet. Wie das beim Neustart ohne vorheriges Speichern ist, muss ich mal ausprobieren. Ich kann mich nicht recht erinnern, ob ich dann neu gespeichert hatte oder nicht. Beim nächsten Mal, wenn der Fehler auftritt, werde ich das genauer prüfen. Bzw. nach dem Testlauf mit der geänderten Version nochmal die alte ausprobieren.

Zitat:Benutzt du Globale Variablen mit unsynchronisiertem Schreib/Lese-Zugriff?

Nein, keine globalen Variablen, nur lokale. Allerdings hatte ich anfänglich mal ein paar globale Variablen, die ich wieder entfernt habe. Könnten davon noch irgendwo Reste sein? LabVIEW ist für mich in vielen Fällen immer noch eine Blackbox, bei der mir die Kontrollmöglichkeiten einer "normalen" Programmiersprache fehlen. Codezeilen sind irgendwie ... strukturierter

Zitat:Das könnte helfen - für diese eine Stringkonstante. Nur: Damit ist das Problem nicht gelöst. Möglicherweise wandert dann der "Fehler" z.B. auf die 70 gleich rechts daneben oder auf andere Stringskonstanten.

Wenn das tatsächlich auf andere Konstanten übergeht, wird's wirklich ärgerlich :/ Mal sehen, was mein Test ergibt, der nun seit etwa einer Stunde läuft (12k Datenpunkte). Da der Fehler üblicherweise erst nach sehr viel mehr Datenpunkten auftritt, muss ich da noch etwas warten. Ich melde mich dann aber nochmal!

Zitat:Ich sehe da eine Möglichkeit, wie so was passiert: Da schreibt einer auf Speicher, der ihm gar nicht gehört.

Ja, das würde erklären, was passiert. Nur warum kann da einer unkontrolliert im Speicher rumpfuschen? Windows XP sollte das eigentlich verhindern und andere Programme laufen nicht. Jedenfalls nichts Ungewöhnliches. Da der Rechner nur 256MB Speicher hat, sollte sich ein Defekt im RAM durch Abstürze sofort bemerkbar machen.

So langsam fange ich an, an der Ernst der Lage zu glauben. Es müßte sich dann womöglich um einen bug von LV7.1 handeln, der vielleicht unter "bugs fixed" in irgendeiner DOC aufgelistet ist?
Wenn es sich wirklich nur um diese eine Stringkonstante handelt, dann würde ich es ganz pragmatisch mit einem work-arround versuchen, z.B so: Stringkonstante in byte array konvertieren --> Anzeigen. Aus Anzeige Konstante erstellen. Stringkonstante, Funktion string to Byte array, Anzeige: Löschen. Die neue Konstante zusammen mit der Funktion Byte Array to String anstelle der Stringkonstanten verwenden.
Oder: verborgenes Bedienelement mit Standardwert ":Read?" anstelle der Konstanten verwenden.

Anzeige

' schrieb:So langsam fange ich an, an der Ernst der Lage zu glauben.

=)

Zitat:Oder: verborgenes Bedienelement mit Standardwert ":Read?" anstelle der Konstanten verwenden.

So in der Art habe ich es gemacht. Bis jetzt scheint es zu funktionieren. Aber mal abwarten. *klopfaufholz*

Vielen Dank für Eure Mühe/Hilfe! Viele Grüße, TwisT

' schrieb:Könnten davon noch irgendwo Reste sein?

Nein. Respektive: das kannst nur du wissen.

Zitat:bei der mir die Kontrollmöglichkeiten einer "normalen" Programmiersprache fehlen.

Auch LabVIEW hat Kontrollmöglichkeiten - zugegeben nicht so schön wie bei Delphi aber immerhin.

Zitat:Codezeilen sind irgendwie ... strukturierter

Eine "Struktur" bekommst du bei LV durch die Drähte rein - und durch das Verfahren des Datenflusses. Das ist eine Art der Strukturierung - man muss sich nur daran gewöhnen.

Zitat:Nur warum kann da einer unkontrolliert im Speicher rumpfuschen?

Aufgrund von Programmierfehlern. Pointer, Listen etc sind da sehr anfällig.

Zitat:Windows XP sollte das eigentlich verhindern und andere Programme laufen nicht.

Das Betriebssystem verhindert lediglich, dass eine Applikation auf Speicher außerhalb ihres zugesprochenen Speichers zugreift (lesend oder schreibend). Was die Applikation mit ihrem eigenen Speicher macht, dafür ist Win32 nicht zuständig. Sehr wohl kann ein Fehler innerhalb der Applikation - ob in LV als System oder in dem mit LV erstellen Programm - vorhanden sein. Wenn dann z.B. auf die Variable X geschrieben werden soll, das Ergebnis aber - eben wegen eines Fehlers irgendwo - in der Variablen B landet, dann treten genau solche Fälle auf wie bei dir. Das sehr sehr unschöne daran ist auch, dass solche Fehler sich nur manchmal bemerkbar machen - so wei eben auch bei dir.

Zitat:Da der Rechner nur 256MB Speicher hat,

WinXP, LV und 256MB? :blink:256MB halte ich für zu wenig. Mach 512 und der Fehler ist weg.

' schrieb:So langsam fange ich an, an der Ernst der Lage zu glauben. Es müßte sich dann womöglich um einen bug von LV7.1 handeln, der vielleicht unter "bugs fixed" in irgendeiner DOC aufgelistet ist?
Wenn es sich wirklich nur um diese eine Stringkonstante handelt, dann würde ich es ganz pragmatisch mit einem work-arround versuchen, z.B so: Stringkonstante in byte array konvertieren --> Anzeigen. Aus Anzeige Konstante erstellen. Stringkonstante, Funktion string to Byte array, Anzeige: Löschen. Die neue Konstante zusammen mit der Funktion Byte Array to String anstelle der Stringkonstanten verwenden.
Oder: verborgenes Bedienelement mit Standardwert ":Read?" anstelle der Konstanten verwenden.

ja, ich auch. Ich denke, es handelt sich um den berühmt berüchtigten "Constant Folding Bug". Ich hab mir das Thema aber damals nicht allzugenau reingezogen und kann hier nicht wirklich hilfreich beitragen, aber ich würde mal empfehlen sich in den NI-Foren nach diesem Bug umzusehen und da weiter zu recherchieren ...

' schrieb:Auch LabVIEW hat Kontrollmöglichkeiten - zugegeben nicht so schön wie bei Delphi aber immerhin.
Eine "Struktur" bekommst du bei LV durch die Drähte rein - und durch das Verfahren des Datenflusses. Das ist eine Art der Strukturierung - man muss sich nur daran gewöhnen.

Ja, es ist für jemanden, der 20 Jahre lang Code-orientiert programmiert hat, eine ziemliche Umstellung. Aber es wird immer besser, je länger ich mich mit LabVIEW beschäftige.

Zitat:WinXP, LV und 256MB? :blink:256MB halte ich für zu wenig. Mach 512 und der Fehler ist weg.

*g* Könnte ich natürlich machen. Aber da auf dem Rechner nur die Datenerfassung meines Experiments läuft, die nicht so schnell sein muss (ca. 2-4 Datenpunkte/sek), sollten auch die 256MB reichen. Ich habe so ziemlich allen Schnickschnack von WinXP abgestellt. Da läuft es recht flüssig. Sobald das Programm fertig ist, soll es auch nicht mehr in der LabVIEW-Entwicklungsumgebung laufen.

Danke für den Tipp mit dem "Constant Folding Bug". Das hört sich interessant an, soweit ich das im NI-Forum auf die Schnelle sehen konnte. Mein work-around scheint übrigens ganz gut zu funktionieren. Jedenfalls war es diesmal ein anderer Fehler, der mein Programm beendet hat. Auch in dem "In String suchen", nur diesmal weil der zu durchsuchende String fehlerhaft war. Da hat mein Messgerät wohl etwas Falsches übermittelt, der ":read?"-Befehl wurde jedenfalls korrekt gesendet. Da muss ich mir noch etwas zur Überprüfung einfallen lassen.

Viele Grüße, TwisT