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!
zwei Wait x Milliseconds in der gleichen Schleife bewirken dass ein Schleifendurchlauf immer mindestens so lang dauert wie die längste eingestellte Wartezeit
Käme hier statt einem "ist nicht gleich" ein "ist kleiner als" zum Einsatz dann könnte man damit prüfen ob der Timer übergelaufen ist. In dieser Konstellation kommt eig. immer ein True raus es sei denn man hätte das LV Programm gerade so gestartet dass beim 1. Durchlauf aus dem Timer-Wert eine 0 rauskommt (das ginge dann aber auch nur bei einem Strang ) weil eine nicht initialisierte Feedback Node - genauso wie ein Shift Register - dann den 1. Wert 0 rausgibt
@Lucki: warum soll der Timer denn zicken? Ich glaub nicht dass das nötig ist jedesmal den Rechner neu zu booten. Selbst wenn der Timer-Wert überläuft, vor dem Überlauf ist nach dem Überlauf
' schrieb:@Lucki: warum soll der Timer denn zicken? Ich glaub nicht dass das nötig ist jedesmal den Rechner neu zu booten. Selbst wenn der Timer-Wert überläuft, vor dem Überlauf ist nach dem Überlauf
Ja, hätte ich vielleicht diese Bemerkung noch mit [Humor] ... [/Humor] einrahmen sollen statt nur dieses Emotikon zu verwenden? Ich gebe allerdings zu, daß ich mich damit nicht auskenne und immer das im Editor links oben in der ersten Zeile verwende. Vielicht war es deshalb mißverständlich.
Zitat:zwei Wait x Milliseconds in der gleichen Schleife bewirken dass ein Schleifendurchlauf immer mindestens so lang dauert wie die längste eingestellte Wartezeit
Das ist zwar richtig, aber ich meine daß es Gottfried nicht darum ging, sondern um den Bullshit, der an den beiden Ausgängen der Timer dranhängt.
Übrigens Ich finde den Programmcode, um den es hier geht gar nicht schlecht. Es wurde endlich Zeit, daß mal jemand eine Rube-Goldberg-Maschine in LabVIEW programmiert. Einfach immer nur eine false-Konstante zu verwenden ist doch uncool.
' schrieb:zwei Wait x Milliseconds in der gleichen Schleife bewirken dass ein Schleifendurchlauf immer mindestens so lang dauert wie die längste eingestellte Wartezeit
Das ist richtig - aber irrelevant.
So wie das aussieht, befindet sich in dem Datenfluß ein ExpressVI. Und wenn sowas schon vorhanden ist, dann befinden sich da auch (mindestens) zwei parallele Datenflüsse. Jeder mit einem Wait(ms).
Mir fällt noch eine (un)mögliche Möglichkeit ein: Man kann damit prüfen, ob der Timer (respektive die "Timer-Task") abgestürzt ist. Bei zweimal dem gleichen Wert stimmt was mit dem Timer nicht.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Übrigens Ich finde den Programmcode, um den es hier geht gar nicht schlecht. Es wurde endlich Zeit, daß mal jemand eine Rube-Goldberg-Maschine in LabVIEW programmiert. Einfach immer nur eine false-Konstante zu verwenden ist doch uncool.
Hier gibt es eine ganze Sammlung davon. Einige sind echt gut ;-)
In theory, there is no difference between theory and practice; In practice, there is.
Also der Timer zickt nicht wie den auch immer. Er läuft einfach über und beginnt wieder bei Null. Das kann ein Problem sein wenn man grösser-gleich und dergleichen Vergleichsoperationen verwendet aber das wäre dann dumm programmiert. Was man mit diesen Werten machen sollte wenn man denn zwei oder mehr vergleichen muss, ist sie voneineander subtrahieren. Das Resultat ist immer die korrekte Differenz solange der Timer nicht mehr als einmal übergelaufen ist da gemäss IEEE die Subtraktion von unsigned Integern so definiert ist dass das halt gewährleistet ist und LabVIEW hält sich peinlich genau an diese Standards.
Der originelle Code ist tatsächlich minimal obscure zu nennen. Da es sich um ein festes Wait handelt kann der Ausgang niemals weniger Differenz haben dan der maximale Wait innerhalb einer Loop. Also wird der Wert aus dem Shift Register (sorry Feedback Node) niemals gleich sein an den Wert aus dem Wait. Habe das selber schon viel einfacher mit einer True Konstanten gemacht wie andere schon aufgezeigt haben und solcher True Konstanten Code ist ein 99.9% Kanditat bei mir um ganz aus dem Code gekippt zu werden.
Wertvoller Hinweis. Eigentlich ist es klar, eine U - Zahl verhält sich einfach so, wenn sie überläuft, da muß überhaupt nichts dazugetan werden, um die IEEE-Spezifikation zu erfüllen. Und trotzdem war mir das nicht bewußt, daß dadurch bei der Subtraktion bei einmaligen einmaligen Überlauf kein Fehler entsteht.
Falls es jemanden gibt, des das nicht gleich versteht hier ein Beispiel:
20.04.2010, 18:54 (Dieser Beitrag wurde zuletzt bearbeitet: 20.04.2010 18:55 von rolfk.)
' schrieb:Wertvoller Hinweis. Eigentlich ist es klar, eine U - Zahl verhält sich einfach so, wenn sie überläuft, da muß überhaupt nichts dazugetan werden, um die IEEE-Spezifikation zu erfüllen. Und trotzdem war mir das nicht bewußt, daß dadurch bei der Subtraktion bei einmaligen einmaligen Überlauf kein Fehler entsteht.
Falls es jemanden gibt, des das nicht gleich versteht hier ein Beispiel:
[attachment=54406:clip.png]
Also dass da heutzutage bei Verwendung moderner Compiler eigentlich nichts mehr speziell gemacht zu werden braucht stimmt schon, aber das war lange nicht allzeit so. Und wenn es um Floating Point Zahlen geht dann musst du in C immer noch spezifisch isnan() und isinf() benützen. Sonst rechnet Dir der Compiler unsinnige Resultate heraus.
aber was soll ich nun wirklich mit diesen Konstrukten machen?
Ich dachte, das wäre inzwischen klar: IGNORIEREN!
Und ich hatte schon einmal gefragt: Wohin führt der T/F Ausgang des Vergleichs? Was wird im FALSE-Case (der nach Meinung aller NIE auftritt) ausgeführt?
Gruß, 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!
