Ich sitze schon wieder vor einem so komischen Effekt.
Ich hab ein VI (in LV8-2) angehängt. Darin befindet sich in der unteren Sequenz eine Wartezeit mit 0 Millisekunden. Mit aktivierter Wartezeit von Null Millisekunden dauert die Schleife 250ms. Ohne Wartezeit, also mit deaktivierter Wartezeit, dauert die Schleife ca. 275ms. Also 250 plus die Dauer der unteren Sequenz.
Ich hab das bei LV8-5 festgestellt. Wer kann denn das mal verifizieren, vielleicht auch bei (82 oder 86) und mir sagen, erstens ob das bei ihm auch so ist und zweitens warum das so ist. Respektive was an meinem Sourcecode falsch ist oder anders gehört.
Verifiziert unter LV8.6 unter einem SingleProcessor-PC. (wobei ich eher 45ms für die Darstellung brauche...)
Was mal wieder zeigt, dass man nicht vorhersagen kann, was der LV-Compiler aus einem BD wirklich macht.
Gruß, Jens
' schrieb:Was mal wieder zeigt, dass man nicht vorhersagen kann, was der LV-Compiler aus einem BD wirklich macht.
Das war ja nur das Versuchsmuster. Aufgefallen ist mir das in einem richtigen Programm: siehe Bild. Mit Sequenz: Schleifendauer 250ms. Ohne Sequenz: Schleifendauer von Prozessorleistung abhängig!
Es gilt also gar nichts. Selbst nicht sequenzierte Programmteile laufen nicht zwangsläufig parallel ab. Und wenn in einer Schleife ein 250ms-Wait steht, heißt das noch gar nichts?
[*grübel*]
Oder liegt das wieder nur an dem Graphik-Element? Bisher hab ich mit diesen Elementen nur Probleme gehabt.
Ich bekomme etwa daselbe Ergebnis, aber ich wundere mich nicht, denn kein Timer ist nicht dasselbe wie ein Timer mit 0 ms.
In der Hilfe steht ja: "Bei 0 wird der aktuelle Thread zur Abgabe der CPU-Steuerung gezwungen". Allerdings stehe ich jetzt auf dem Schlauch, was das im Klartext heißt und wie man damit das Ergebnis erklären kann...
Wer hilft? Meine Vermutung ist: Bei 0 wird wird die Sequenz unten sehr stark priorisiert, so daß oben der Timer zunächst gar nicht angestoßen wird.
' schrieb:In der Hilfe steht ja: "Bei 0 wird der aktuelle Thread zur Abgabe der CPU-Steuerung gezwungen".
1. Es muss nicht unbedingt 0 drinn stehen, es geht auch mit 25ms.
2. Das heißt, der Thread wechselt zwischen BD und FP. Das heißt, die Ausgabe der Daten am FP, respektive am Graph, wird erzwungen. Das Anzeigen der Daten im Canvas des Graphen dauer nämlich so lange - eben diese 25ms.
3. Was ist dann mit dem Sequenzrahmen?
[*grübel*]
Heißt das etwa, das BD wartet 250ms und tut nichts? Und danach werden alle Bildschirmausgaben gemacht? Ein Sequenzrahmen könnte das selbe bewirken wie ein Wait => Umschalten nach FP.
[*grübel*]
Was ist jetzt, wenn ich einen 250ms-Wait und einen 0ms-Wait parallel mache?
Bei mir dauert es immer 250ms.
Getestet mit Linux 8.6 mit P4
Ein Wait=0 in einer Sequenz ist mir neu,dass das was bringt, aber in einer Schlaufe schon.
Aber warum es bei euch nicht so ist, kann ich jetzt auch nicht sagen....
Windows?
Bei mir unter Vista und LV 8.6 laufen beide 250 ms lang.
Gruß, eg
XP Pro SP2; LV 8.2.1;
- beides 250 ms
So, nun habe ich das mal noch mit W2000 und Vista getestet.
jedesmal dauert es 250ms. Dauer Signal konstant 10ms auf Vista
Rest gelöscht ......
' schrieb:Bei mir dauert es immer 250ms.
@Role @eg
Kann es vielleicht sein, daß ihr denselben Fehler macht wie anfangs ich auch?
Falsch: In der Deaktivierungsstruktur mit der linken Maustaste den anderen Case sichtbar machen.
Richtig: Mit rechter Maustaste das deaktivierte Unterdiagramm aktivieren.
In einem Buch (Johnson/Jennings) finde ich noch diesen Hinweis:
"The 0-ms wait is a special instruction to the LabVIEW scheduler to let other waiting tasks run, but to put yours back in the schedule as soon as possible"
Also im Klartext: Wenn man eine Schleife so schnell als möglich ausführen möchte, aber ohne andere Tasks zu blockieren, dann Wait mit 0 ms verwenden.
Und damit ist eigentlich alles klar:
Das Updaten des Signalverlaufsgraph dauert 35ms, und wenn sich dort kein Timer befindet, werden andere Tasks blockiert. D.h. das obere 250 ms Wait wird in der Zeit nicht mal angestoßen, die Wartezeit beginnt erst nach den 35ms.
Mit 0-ms Timer sieht die Sache günstiger aus, andere anstehende Task werden nicht völlig blockiert. Das 250ms Wait wird quasi zur Zeit 0 mit aufgerufen, und nicht erst nach 35 ms.
Man muß sich auch mal von der Vorstellung lösen, die Waitfunktion habe magische Eigenschaften, wonach sie immer zu allererst ausgeführt wird. Sie ist ein paralleles VI wie jedes andere, und wenn Wait nicht in Datenstrukturen eingebunden ist und frei in der Fläche schwebt, passieren damit die gleichen Überraschungen wie man sie z.B. mit lokalen Variablen erleben kann.