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!
Das funktioniert nicht, weil der linke Konfigurationsknoten nur vor dem ersten Schleifendurchlauf ausgelesen wird. Man kann aber dem rechten internen Knoten (wo z.Z. nur ?! steht) die Periode übergeben. Dann hat deine Schleife beim nächsten Durchlauf die neue Periode. Allerdings kannst du nicht die Periode des gerade laufenden Durchgangs ändern.
Zur Wait-Function: Wenn du sie in eine Schleife/ Struktur/ Case/ ... einfügst und nirgends anschließt, dann läuft sie parallel zum Schleifeninhalt. Das bedeutet, dass die Zeitmessung weder zwingend VOR dem Senden der Befehle beginnt, noch erst DANACH. Es ist eben eher ein Mindest-Timer, als ein exakter Timer.
@ eg: Damit weißt du zwar, wann das Programm wie lange wartet, aber wie lange deine Schleife zur Ausführung braucht, ist genauso unsicher. Die Befehle benötigen ja auch Zeit. Also finde ich die Lösung auch nciht vorteilhafter als das Wait einfach so mit in die Schleife zu legen.
' schrieb:@ eg: Damit weißt du zwar, wann das Programm wie lange wartet, aber wie lange deine Schleife zur Ausführung braucht, ist genauso unsicher. Die Befehle benötigen ja auch Zeit. Also finde ich die Lösung auch nciht vorteilhafter als das Wait einfach so mit in die Schleife zu legen.
Damit kann man aber sicherstellen ob man vor dem Inhalt, während der Ausführung des Inhalts oder danach wartet, kann man eine Datenabhängigkeit durch den Errorcluster einführen und nicht einfach so das Wait irgendwo in die Schleife hinzuschmeissen.
' schrieb:das funktioniert nicht, weil man ja nicht weiß, wie weit es bis zum nächsten Vielfachen ist, weil man ja nicht bei 0 statet.
Wie weit es bis zum nächsten Vielfachen ist, ist doch uninteressant. Wichtig ist, dass der Beginn des nächsten Schleifendurchlaufes immer z.B. bei Vielfachen von 10ms liegt. Voraussetzung ist, dass der gesamte Schleifendurchlauf (außer Metronom) schneller ist, als das Raster (hier kleiner als 10ms). Beginnt immer alles bei einem Vielfachen (z.B. von 10ms), so findet jeder Befehl (vorausgesetzt der dauert immer gleich lang) in einem konstanten Raster - nämlich 10ms - statt.
Im übrigen macht eine zeitgesteuerte While-Schleife das selbe.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Im übrigen macht eine zeitgesteuerte While-Schleife das selbe.
Nicht zwingend - das kann man einstellen... Keine Ahnung, wie das in der deutschen Version heißt, findet sich aber in den Eigenschaften der Timed Loop rechts unten und sollte sich irgendwas in Richtung 'Phase beibehalten' nennen...
Hallo,
also ich habe es jetzt mal mit dem wait.vi programmiert und möchte euch mein ergebnis nicht vorenthalten. Dabei habe ich zum Test erstmal die Heizungen durch LEDs ersetzt, damit es auch ohne Hardware funktioniert.
So funktioniert es auf 2ms genau, das ist ok.
Ich bin noch recht neu in LabVIEW, deswegen habe ich nicht daran gedacht, dass bei wait die ander Loops weiter laufen. Bisher habe ich nur in Java, C, Basic oder Matlab programmiert, und da war es halt immer so, dass man wait vermeiden sollte, weil das Programm an der Stelle ja so lange wartet, bis die Zeit verstrichen ist.
Danke für eure Anregungen und Ideen.
MfG Jeffrey
Noch eine Anmerkung:
Schön, dass es jetzt funktioniert und ändere es ja nicht nochmal (never change a running system), aber ich würde prinzipiell keine Waits in Timed Loops verwenden. Schon gar nicht so viele mit variablen Wartezeiten... Das ist irgendwie sehr verwirrend und bestimmt auch nicht immer zwingend so lauffähig, wie man sich das vorstellt.
Entweder While-Loop + Waits, oder Timed Loop.
' schrieb:Ausserdem, eine Timed-Loop mit 1kHz, und dann ist da schon eine feste Wartezeit von 130ms drin, sprich maximal 7,7 Hz.
MfG, Jens
Hallo,
der timed loop dient nur dazu, die 3 s Periode für die Pwm und die Sensorabfrage zu erzeugen. Diese Zwit wird nie verändert. Habe das in meinem Programm bisher auch mit dem bis Vielfachen von ms warten VI gelöst. Aber hier in dem TestVI habe ich halt den timed loop verwendet, weil oben ja auch geschrieben wurde, das wäre das gleiche. Die Wartezeit von 130ms dient hier nur dazu die Sensorabfrage zu simulieren, diese dauert normalerweise ca 40ms, kann aber bis maximal 130ms dauern. deswegen wird auch die Zeit genau gemessen.
MfG Jeffrey
