INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Debug von irregulären LV-Zuständen



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!

14.06.2008, 11:15
Beitrag #11

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
Debug von irregulären LV-Zuständen
' schrieb:Pardon, wo soll der Vorteil liegen? Solch ein VI zu bauen macht einen Haufen Arbeit. Ich sehe auch unter extremen Voraussetzungen wie gleichzeitiger lese- und Schreibzugriff nur die Möglichkeit das Unsinn gelesen wird.... aber irreguläres Verhalten, blue-Screen....

Gottfried
Den Vorteil hat Freedive erklärt: Du kannst noch einen Errorcluster integrieren, dann hierüber wieder den Datenfluss innerhalb von LabVIEW deterministisch vorgeben und somit die Gefahr von Race Conditions stark verringern.

Globale Variablen sollte man aus IMHO nur unter folgenden Einschränkungen verwenden:
1. Einfache Datentyp (also z.B. keine großen Arrays)
2. Es wird diese Globale Variable nur an einer (oder sehr wenigen) Stelle im Programm gesetzt und dann nur noch lesend verwendet.

MfG, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
14.06.2008, 18:55
Beitrag #12

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.692
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Debug von irregulären LV-Zuständen
' schrieb:aber irreguläres Verhalten, blue-Screen....
Ich hätte es nicht geschrieben, wenn ich es nicht erlebt hätte.

Ursache war ein 2D-Array als globale Variable, die in zwei While-Schleifen jeweils lesend und schreibend manipuliert wurde. Warum? War halt sehr einfach und ohne einen Haufen Arbeit zu realisieren. Selbst bei dauernder Abarbeitung beider Schleifen (24 Stunden, 7 Tage ...) ist das Problem nur alle drei Wochen mal aufgetreten. Und warum war da ein BlueScreen? Genau in der halben µs, in der in der einen Schleife auf das Feld zugegriffen wurde, hat LV einen Threadwechsel gemacht und im anderen Thread mal kurzerhand der Speicher neu alloziert. Dann hab ich mir das mal durch den Kopf gehen lassen, alles mit Flags "threadsicher" gemacht - und plötzlich war der Fehler weg?

Und da jetzt alles in SubVIs liegt und das selbe SubVI nicht gleichzeitig ausgeführt wird (jaja, außer invarianter Ablauf), sind alle Probleme behoben. Der Haufen Arbeit lohnt sich immer. Weil der nämlich nie größer ist, als die Arbeit hinterher.

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.06.2008, 02:23
Beitrag #13

thomas.sandrisser Offline
LVF-SeniorMod


Beiträge: 1.298
Registriert seit: Sep 2005

xxxx
2005
EN

78759
United States
Debug von irregulären LV-Zuständen
dieses phen kenne ich nur bei hyperthreading enabled und lv version < 8.5
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
15.06.2008, 08:15
Beitrag #14

gottfried Offline
LVF-Guru
*****


Beiträge: 1.735
Registriert seit: Mar 2007

2019
2004
EN

20**
Oesterreich
Debug von irregulären LV-Zuständen
' schrieb:Ich hätte es nicht geschrieben, wenn ich es nicht erlebt hätte.

Ursache war ein 2D-Array als globale Variable, die in zwei While-Schleifen jeweils lesend und schreibend manipuliert wurde. Warum? War halt sehr einfach und ohne einen Haufen Arbeit zu realisieren. Selbst bei dauernder Abarbeitung beider Schleifen (24 Stunden, 7 Tage ...) ist das Problem nur alle drei Wochen mal aufgetreten. Und warum war da ein BlueScreen? Genau in der halben µs, in der in der einen Schleife auf das Feld zugegriffen wurde, hat LV einen Threadwechsel gemacht und im anderen Thread mal kurzerhand der Speicher neu alloziert. Dann hab ich mir das mal durch den Kopf gehen lassen, alles mit Flags "threadsicher" gemacht - und plötzlich war der Fehler weg?

Und da jetzt alles in SubVIs liegt und das selbe SubVI nicht gleichzeitig ausgeführt wird (jaja, außer invarianter Ablauf), sind alle Probleme behoben. Der Haufen Arbeit lohnt sich immer. Weil der nämlich nie größer ist, als die Arbeit hinterher.

Wieder was gelernt

Danke

Gottfried

mein wöchentlicher (eigenwilliger) Beitrag zur Innovation
http://innovation1.wordpress.com/
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
16.06.2008, 09:16 (Dieser Beitrag wurde zuletzt bearbeitet: 16.06.2008 09:21 von rolfk.)
Beitrag #15

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
Debug von irregulären LV-Zuständen
' schrieb:Pardon, wo soll der Vorteil liegen? Solch ein VI zu bauen macht einen Haufen Arbeit. Ich sehe auch unter extremen Voraussetzungen wie gleichzeitiger lese- und Schreibzugriff nur die Möglichkeit das Unsinn gelesen wird.... aber irreguläres Verhalten, blue-Screen....

Gottfried

Es ist Arbeit und solange Du nur eine FGV schreibst die einfach eine get und put methode hat auch noch nicht mal so viel besser als eine Global (obwohl da schon ein paar kleine Vorteile sind). Wirklich interessant wirds erst wenn Du aus dieser FGV eine IGV (intelligente globale Variable) machst. Um es mal an einem einfachen Beispiel sehen zu lassen:

Nimm an Du hast irgendwo einen Zähler den Du manchmal inkrementieren und manchmal dekrementieren musst und dann möchte man ihn natürlich noch lesen können. Das kannst Du tun indem Du irgendwo eine dumme Global hinsetzt und jedesmal wenn Du die verändern musst liest Du sie machst die Änderung und schreibst sie zurück. Und dann staunst Du dass das ja überhaupt nie stimmt. Denn an Stelle A liest Du den Wert, Stelle B liest in auch. Bei A wird er inkrementiert und zurückgeschriben und B dekrementiert ihn und schreibt ihn dann zurück. Grundsätzlich kann das Resultat dieses Programmes nun dreifach sein. Die Globale kann wieder dasselbe Resultat haben als zuvor (das ist ziemlich sicher was Du eigentlich willst). Oder sie kann eins grösser oder kleiner sein dann zuvor (ziemlich sicher nicht was Du willst). Das ist eine Race Condition.

Das Ganze in einer IGV mit init, get, increment, und decrement Methode GARANTIERT Dir dass der Wert am Ende wieder gleich ist als zuvor da die IGV als SubVI nicht nur halb von Stelle A ausgeführt werden kann bevor B sie startedt, und ist effizienter da zum inkrementieren und dekrementieren nicht jeweils der Inhalt einer Global herauskopiert und wieder zurückgekopiert werden muss. Ok für einen Counterwert macht dieser Effizienzgewinn nicht wirklich was aus aber mach daraus ein Array von 10000 Messwerten und der Unterschied zwischen Global und IGV ist schon deutlich messbar und wenn es gar um 1000000 Messwerte geht ist es der Unterschied der im einen Fall eine untoleriebar langsame Applikation von einer flott daher laufenden Applikation unterscheidet.

Im Prinzip ist eine IGV schon eine Art Objekt die die Operationen auf bestimmte Daten kapselt und Dir ein Interface zur Manipulation dieser Daten gibt. Ja es ist etwas Arbeit so etwas zu schreiben aber wenn Du mal damit begonnen bist wirst Du die Vorteile davon schnell einsehen und es nicht mehr mit Globals tun wollen.

Rolf Kalbermatter

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Debug-Auswertung mijarena 20 13.840 24.03.2016 09:40
Letzter Beitrag: Lucki
  Anregungen für eine Debug Console für Kunden-Software dali4u 6 5.164 09.09.2013 10:30
Letzter Beitrag: dali4u
  Debug Tools gesucht Mrindfleisch 6 4.548 15.02.2013 07:34
Letzter Beitrag: Mrindfleisch
  Array mit Werten nach Zuständen aus zweitem Array in neue Arrays jedes Zustandes sortieren Mika 6 6.614 08.01.2011 19:17
Letzter Beitrag: Lucki
  Rückgabewert im Debug-Modus ok, sonst nicht Matze 4 4.285 22.10.2010 12:57
Letzter Beitrag: TSC
  Festhalten von Ablauf-Zuständen wohl 3 4.745 17.06.2009 21:22
Letzter Beitrag: schrotti

Gehe zu: