LabVIEWForum.de

Hallo zusammen,

ich plag mich schon seit Ewigkeiten mit einem Problem: Ich hab einen Dauerlaufprüfstand in LabVIEW programmiert. Folgende Situation: Über einen Zustandautomat wird eimal ein Zähler bei 0 gestartet und in ein Schieberegister geschrieben. Bei einem Anhalten der Messung wird der Zähler resetet und vorher die aktuelle Laufzeit in ein zweites Schieberegister gesichtert. Die gesamtlaufzeit ergibt sich nun aus der Summe der beiden Werte.

Jetzt läuft das alles wunderbar bis plötzlich die Gesamtlaufzeit um ein paar Minuten / Stunden oder und Sekunden zurückspringt. völlig zufällig in der Art, zeit und länge. Somit wird das mitgeschriebene Messprotokoll verwüstet weil die Zeit plötzlich aus heiteren Himmel zurückspringt. Dadurch wird das Messprotokoll schlecht lesbar und unbrauchbar für eine Analyse.

Folgende Anmerkungen noch zum Zustandsautomat: Initialisiert werden alle Laufzeitregister mit 0 und und nach dem Unterbrechen wird der Zähler rückgesetzt.

Hat irgendjemand vielleicht schonmal ähnlich mysteriöse Sachen gehabt??

Das programm ist leider zu gross um es hier zu posten.

Schon mal vielen Dank im voraus.

Gruß Rainito

Hallo

Ja ich hatte auch mal ein Problem mit Zeitsprüngen aber das hatte nix mit LabVIEW zu tun sondern mit einem ausgelasteten System und einem Zeitserver der das System dann ab und zu wieder in die Realzeit Zurück geholt hat.

Kannst du sowas alles ausschließen?

Wie bemerkst du die Zeitsprünge? Hast du doppelte Zeitstempel in deinem Messprotokoll?
Ist die Gesamtlaufzeit die Anzahl der Sekunden die die Messung läuft? Wie zählst du das?

Wie misst du die Zeit?

Wenn du z.B. TickCount verwendest...dieser zeigt die Zeit in ms seit Einschalten des PC...und irgendwann gibts dann nen Überlauf! Siehe dazu auch den LV-Hilfe-Artikel!

Hallo,

das mit dem ausgelastetem System überprüf ich noch. Aber da ich meine Whileschleife für den Zustandsautomat getaktet hab (100ms) sollte das nicht das Problem sein. Gut es laufen 9 Prüfstande gleichzeitig die gleiche messungen unabhängig voneinander machen. Ich untersuch das aber nochmal.

Auswirkung: Es wird in Sekunden gezählt......für meine Anzeige rechne ich sie nur noch in h/min/sec um aber das stellt ja kein hindernis da. Diese Anzeigewerte nehm ich dann und speicher sie in mein Protokoll in h/min/sec. Das pass alles bis er z.b. von 248h 30min 50sec auf 245h 26min 40 sec springt. Die sprünge dabei sind willkürlich und treten auch nach keiner wiederkehrenden zeit auf. Alles dem Zufall überlassen.

Da dies alles so zufällig passiert und nicht nach einem Schema d.h. nicht reproduzierbar liegt die Rechnerauslastung doch nicht so fern oder?

Hilfe!!

Danke

' schrieb:Auswirkung: Es wird in Sekunden gezählt......

Ist der Zähler ein I32 oder ein DBL und zählt die Sekunden? 250h sind nicht wirklich viel, gerade mal knappe 1Mio Inkremente. Für DBL wie für I32 machbar.

Zitat:Das pass alles bis er z.b. von 248h 30min 50sec auf 245h 26min 40 sec springt. Die sprünge dabei sind willkürlich und treten auch nach keiner wiederkehrenden zeit auf. Alles dem Zufall überlassen.

Verdächtig.

Zitat:Da dies alles so zufällig passiert und nicht nach einem Schema d.h. nicht reproduzierbar liegt die Rechnerauslastung doch nicht so fern oder?

Ich sehe hier keine Verbindung (nicht mal ganz in der Ferne). Auch ein zu langsamer Rechner kann einen richtigen Algorithmus nicht dazu bringen, plötzlich falsche Werte zu produzieren.

Ich würde hier eher auf eine RaceCondition im weitersten Sinne tippen. Möglicherweise ein (im weitesten Sinne) Synchronisationsproblem.

Theorie:
Gesetzt der Fall, du hast in deinem Algorithmus die Bearbeitung eines ganz bestimmten Falles vergessen, dann wird es zu einem Problem kommen, wenn dieser Fall eintritt. Sei dieser Fall nun das Zusammentretten zweier Ereignisse, dann wird der Fehler nur dann auftreten, wenn beide Ereignisse zur gleichen Zeit auftreten. Und hier liegt jetzt das Problem: Wie oft müssen die Ereignisse jedes für sich auftreten, dass sie irgendwann mal gleichzeitig auftreten. Dauere jedes der beiden Ereignisse 10µs (+-1µs, Schwankungsbreite!) und tritt alle 1ms (+-10µs) auf, kann man eine Berechnung anstellen, wie oft jedes einzelne Ereignis eintreten muss, um plötzlich gemeinsam aufzutreten. In deinem Falle würde ich jetzt sagen: Ein Ereignis muss 1Mio auftreten, um mit einem zweiten zusammenzufallen, sodass ein Fehler resultiert: 1Mio*1Sekunde ca. 250Stunden. Das Inkrementieren z.B. kann als Ereignis aufgefasst werden. Salopp gesagt: Treten zwei Ereignisse zur selben Nanosekunde ein, passiert ein Fehler. Nanosekunde klinkt zwar wenig. Das ist aber eine Milchmädchenrechnung: Der Prozessor arbeitet nämlich so schnell und so viel, dass er innerhalb einer bestimmten Zeit einen Algorithmus Giga-Mal abgearbeitet hat - und dann erwischt er garantiert auch einmal diese eine Nano-Sekunde. Soviel zur Theorie (falls sie denn einer verstanden hat).

Derartige Effekte sind zwar mit Hardware leichter zu realisieren und zu verstehen. Nichtedestoweniger gilt das Prinzip aber auch für Software.

Ich gestehe, ich hab das selbst schon gehabt: Ein Array als globale Variable in zwei unabhängigen While-Schleifen geschrieben und gelesen. Das ging immer so etwa drei, vier Wochen Dauerlauf gut, bis plötzlich das Programm einen Bluescreen bekam. Dann hab ich mich doch dieser einen "Nonosekunde" erinnert und mir überlegt: Naja gut, theoretisch(?!) könnte dieser Effekt genau hier doch passiert .... Also: umgeschieben - und siehe da: Kein Fehler mehr. Da haben sich zwei Operationen, die jede für sich gerade mal 10ms dauern und nur (weis nicht mehr) einmal die Stunde gemacht werden, getroffen.


Ein zu langsamer Rechner mag die Wahrscheinlichkeit des Auftretens des Fehler positiv beeinflussen können (im Sinne, dass der Fehler eintritt) und umgekehrt. Der Fehler selbst liegt dann aber doch am Algorithmus, nicht an der Geschwindigkeit des Rechners.

Ich tippe auf Achims Vorschlag. Der Millisekunden-Counter schafft "gerade" 1200 Stunden:
[attachment=24527]
Rainito, du bist am Zug, trifft irgendetwas zu?

Gruß, Jens

Hallo ihr,

hab meine Laufzeiterfassung mal augebaut, wie sie in einem meiner 9 Zustandsautomaten aussieht. Zu beachten ist, dass entweder der Timer bei null gestartet werden kann oder durch Eingabe von zeiten eine laufzeit geladen werden kann, wie es auch bei mir im Programm der Fall ist.

Für meine Zeiterfassung benutz ich das ExpressVI "Verstrichene Zeit" aber das seht ihr ja im VI selber.

Zu eurem Verdacht auf Zeitgleiche Abarbeitung: Wenn ich 9 parallel ausgeführte Zustandsautomaten hab, die ihre Messdaten über Melder bekommen. Da diese Zustandsautomaten nicht zeitgesteuert ablaufen könnte es hier zu dieser Nanosekunde kommen oder? Versteh ich das richtig?

Grüße Rainito

Kleiner Hinweis, fast off-toppic:
Das Hin-und Herrechnen von Sek. nach/von 3 getrennten Anzeigen hh, mm, ss kannst Du dir ersparen. Durch Änderung der Anzeigeeigenschaften auf "relative Zeit" ändert sich die Anzeige von Sek in hh:mms , und dieses Format ist außerdem allemal besser lesbar als eine auf 3 Anzeigen verteilte Zeit.
Hier 2 mal der gleiche Wert:
[attachment=24538]

' schrieb:Wenn ich 9 parallel ausgeführte Zustandsautomaten hab, die ihre Messdaten über Melder bekommen. Da diese Zustandsautomaten nicht zeitgesteuert ablaufen könnte es hier zu dieser Nanosekunde kommen oder? Versteh ich das richtig?

Ja, das hast du richtig verstanden.

Die neun Statemachines sollen ja unsynchronisiert laufen. Wenn jetzt der Zeitzähler allen neun Prozessen übergeordnet ist und jeder einzelne der neun Prozesse für sich diesen Zeitzähler, u.U. auch synchronisiert, manipulieren könnte - dann kann ich mir vorstellen, dass es zu dem beschriebenen Effekt (Fehler nur alle 250 Stunden) kommt.

@Lucki: Danke für den Tipp....werd ihn in Zukunft berücksichtigen...aber jetzt ist es zu spät. Müsste alles umprogrammieren...Messdatenspeicherung und Messdatenvisualisierung. Keine Lust!! :-)

@ich selbst: ich glaub ich bin ausgestiegen. Die einzelnen State-machines müssen ja unabhängig voneinderlaufen und können nicht synchronisiert werden, da die Abläufe ja unterschiedlich sind und jeder Prüfplatz selbstständig agiert. Somit hat jeder Prüfplatz einen eigenen Laufzeitzähler der beim starten aktiviert wird.

Wie komm ich jetzt aus dem Schlamassel raus? Ich dachte wenn ich 9 prüfstände parallel ausführen will muss ich 9 unabhängige Whileschleifen bzw. Statemachines haben die nicht synchronisiert werden. Damit läuft jede statemachien autark und keine probleme entstehen.

Bin echt ratlos!