Zeitsprünge bei der Laufzeiterfassung eines Prüfstandes

' schrieb: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!

Keine Hektik am frühen Morgen!

Wo befindet sich denn jetzt der Zähler, der plötzlich zu wenig anzeigt? In der Statemachine für jeden einzelnen Prüfstand? Also gibt es applikationsweit neun solcher Zähler, die plötzlich zu wenig anzeigen?

[*grübel*]

Gut, ich gehe jetzt davon aus, dass jeder der neun Prozesse einen eigenen, manchmal nicht richtig funktionierenden Zähler hat. Das spielt aber für die allgemeine Betrachtung keine Rolle. Auch in diesem Falle kann ich mir vorstellen, was ich oben dargelegt habe.

Achja, noch eins:
Dein Programm kann ich mir erst später ansehen.

Anzeige

Genau....jede State Maschine hat einen eigenen Laufzeitzähler der ab und zu und schon auf gar keinen Fall gleichzeitig versagt.

Und zu den 250 Stunden.......es ist egal ob ich eine vorhandene Laufzeit fortsetze oder eine neue messung starte. kann nach 3 minuten sein....oder nach 300 Std

Vielleicht fällt euch ja noch was ein!!

Ich sag auf jeden Fall schon mal nochmal danke und wünsche ein erholsames ideenreiches Wochenende.....auch mir!! :-)

Ich hab mir mal das MusterVI angekuckt und bin zu folgendem Ergebnis gekommen: Einen Zustand gemäß dem von mir oben beschriebenen Effekt kann ich hier nicht feststellen. Aber einen ablaufspezifischen:

Erstens:
Vor (nicht nach) einem "Dateneingabe" (siehe Statemachine) muss unbedingt ein "Neue Messung starten" gemacht werden. Würde ein "Neue Messung starten" vor einem "Dateneingabe" nicht gemacht werden, würde im Cluster nicht die aktuelle Laufzeit stehen. Damit würde in einem folgenden "Dateneingabe" ein alter Laufzeitstand (oberes DBL-Schieberegister) für neu genommen werden.

Beispiel für fehlerhaften Ablauf: "Dateneingabe", "Neue Messung starten", sonstiger Case (irgendwelche müssen gemacht werden, sonst könnte man sie ja auch weg lassen), sonstiger Case (irgendwie muss die Zeit ja vergehen), sonstige Cases, "Dateneingabe": Jetzt wird ein alter Laufzeitstand übernommen. Auf jeden Fall weniger. Es muss also geprüft werden, dass die Reihenfolge der Cases immer konsistent ist.

Das Problem hierbei kommt von folgendem:
Das VI "Verstrichene Zeit" liefert ja dem Namen nach die Dauer der letzten Messung (sag ich jetzt mal so). Eigentlich solle genau zu dem Zeitpunkt, zu dem diese Dauer ermittelt wird (nämlich mit dem VI), diese Dauer auch zum aktuellen Wert der Laufzeit addiert werden (also innerhalb des Clusters). Die Dauer wird aber in einem Schieberegister zwischengespeichert - zusammen mit der bisherigen Laufzeit. Jetzt gibt es aber zwei Speicherbereiche (Schieberegister und Cluster) mit der selben Eigenschaft: nämlich Laufzeit. Zwei Speicherbereiche für eine Eigenschaft zu haben ist aber redundant - und damit überflüssig und fehleranfällig.
Hinweis: Die Funktionalität "Anhalten" kann man auch anders, und auch sehr einfach, realisieren als hier dargestellt.


Zweitens:
Das mit dem VI "Verstriche Zeit" gefällt mir nicht. Problem: Dieses VI muss zum Startzeitpunkt und zum Endzeitpunkt der zu messenden "verstrichenen Zeit" aufgerufen werden. Das geht aber nur, wenn der selbe Case zweimal aufgerufen wird: Einmal am Anfang der Messung und dann am Ende der Messung. Den selben Case zweimal aufrufen zu müssen, kann aber Probleme beim Ablauf (Statemachine) aufwerfen. Was passiert zwischen Ende und Anfang? Es würde mir besser gefallen, wenn das VI "verstrichene Zeit" in einen SubVI wäre und wenn dann dieses SubVI im Case "MyStartOfMeasure" und im Case "MyEndOfMeasure" aufgerufen werden würde.


Fazit:
Ich tippe auf einen Ablauffehler innerhalb der Schrittkette. Die Fehlerbeschreibung "plötzlich zu geringe Laufzeit" spricht dafür, dass einmal die Summe aus aktueller Laufzeit und verstrichene Zeit nicht richtig abgespeichert wurde, bevor diese Zeit wieder geladen wird.

Diese meine Überlegungen können natürlich ganz einfach widerlegt werden, indem man die Richtigkeit der Ablaufsteuerung nachvollziehbar und vollständig nachweist.

den ablaufspezifischen Fehler hab ich auch vermutet. Bin den Ablauf 100 mal durchgegangen und hab keinen Fehler entdeckt. Dann muss ich wohl nochmal ein paar mal drüber schauen!

Aber was mich dabei wundert, dass wenn es ein Ablauffehler ist.....dieser bei einer gleichbleibender Zyklusabfolge ....nicht reproduzierbar ist.....und vor allem nicht zyklisch auftritt!!!

Danke für eure Mühen. Falls sonst noch jemand eine andere Idee hat bitte posten.

Merci.

Gruß

Rainer

' schrieb:Aber was mich dabei wundert, dass wenn es ein Ablauffehler ist.....dieser bei einer gleichbleibender Zyklusabfolge ....nicht reproduzierbar ist.....und vor allem nicht zyklisch auftritt!!!

Der Fehler tritt nur ein, wenn ein unvorhergesehenes (nicht unvorhersehbares) Ereigniseintritt. Das kann z.B. das Unterbrechen des Ablaufes sein. Wenn dann durch weitere Benutzereingaben in unterschiedlichen Cases irgendein Case durcheinander kommt, könnte es zu einem Fehler kommen.

Hi,
ich glaube immer noch, das das grundsätzlich am Zeitgeber liegt. Im SubVI "VerstricheneZeit" wird die Funktion "First Call" verwendet. Das sieht man, wenn man das ExpressVI in richtigen Code umwandelt (rechtsklick...open Front panel). Dieses "First Call" funktioniert aber nur genau 1x nach dem Start des "Gesamt-VIs", d.h. nur nach dem ersten Aufruf innerhalb deines Ablaufs...danach kommt immer was verkehrtes raus. Du solltest mal in dieser Richtung forschen, meiner Meinung nach ist das VI nicht dazu geeignet, es mehrmals im Ablauf aufzurufen...

Gruß
Achim

Anzeige

Hallo Achim,

was für ein VI kann ich ansonsten verwenden das mir die gleiche Funktion bringt??

' schrieb:Im SubVI "VerstricheneZeit" wird die Funktion "First Call" verwendet.

Eine Sonde am Ausgang ergibt, dass das Verhalten dieses SubVIs genau so ist, wie sich Rainito es wünscht. Nämlich wiederholtes Messen von Zeitabständen (Zwischenzeiten). Dazu sind aber zwei Eingänge besonders zu belegen.

Was natürlich wieder heißt, dass das Verhalten der beiden Datenfüsse auf diese Leitungen im Gesamtzusammenhang überprüft werden sollte.

Denke auch dass das VI genau auf meine Anforderungen passt.....Sollte es nur definiert Rücksetzen wenn ich die Messung anhalte! Alle anderen Ausgänge sind doch unrelevant für mich!

Mir fällt noch mehr ein. ^_^

' schrieb:Sollte es nur definiert Rücksetzen wenn ich die Messung anhalte!

Das Rücksetzen dieses Elementes ohne die aufgelaufene Zeit zu speichern, bewirkt natürlich auch den beobachteten Fehler. Auch hier kannst du nochmals verifizieren.

Ich gehe bisher nicht davon aus, dass das SubVI von sich aus irgendwas falsch macht.