Grüße an alle,
ich habe mir zu Übungszwecken einen Zufallsgenerator mit Mittelwertbildung erstellt und in meine eigene LabVIEW Library abgespeichert. Nun habe ich es als SubVI geöffnet und die Anschlüsse belegt aber meine FP-Elemente reagieren nicht. Der Screenshot im Anhang zeigt in der unteren Hälfte die rohe VI und in der oberen Hälfte als SubVI. Die Roh-VI reagiert wie gewollt auf die eigetragene Intervalldauer und Wertebereiche und zeigt demnentsprechend auch die Zufallszahlen und Mittelwerte an. Nur als SubVI reagieren meine Anzeige- und Bedienelemente nicht. Der Teufel steckt im Detail irgendwo in der while-Schleife, nur will mir partout auffallen wo.
Über richtungsweisende Antworten freue ich mich.
MfG
SimpleMinded
Hallo SimpleMinded,
schliess mal, in beiden Fällen, an die Leitung die vom Stop-Button weggeht eine probe an -- dann solltest Du es merken was falsch ist.
Grüße
kpa
Hallo kpa,
Proben habe ich angeschlossen und beobachtet, dass während der Ausführung bei meiner SubVI der Wert am Stopp-Button gelesen wird, der Wert des Stopp-Buttons der Test VI jedoch nicht. Ich ging eigentlich davon aus, dass ich durch die Verknüpfung der Eingabe- und Ausgabelemente der SubVI mit lokalen Variablen das Tunnelproblem der while-Schleife umgehe. Aber so wie es aussieht, wird ein Anschluss, sobald ich die SubVI als Knoten verwende, dennoch wie eine Tunnelverbindung verstanden. Sehe ich das soweit richtig?
Verzeih, falls ich Begriffe noch nicht korrekt verwende. Ich bin immernoch ein Anfänger.
Ich habe jetzt vorerst den Stopp-Knoten der while-Schleife der SubVI mit einer Schleifeniteration = 4 Funktion verbunden und die Test VI selber in eine zweite while Schleife gesetzt. So krieg ich zumindest immer nach 5 Werten einen Mittelwert raus, bis ich die Schleifenbedingung der Test VI auf TRUE setz.
Aber wie umgehe ich diese Tunnel Ein- und Ausgänge bei Verwendung von while- und for-Strukturen in SubVIs?
MfG
SimpleMinded
Ein- und Ausgänge von SubVIs sind Drähte und ändern ihren Wert nicht einfach zur Laufzeit. Dein SubVI macht in der Form nur Sinn wenn es allein läuft. Als SubVI ist die Konstruktion so unsinnig aus den beobachteten Problemen heraus.
Was willst du eigentlich erreichen bzw. ausprobieren?
Hallo Holy,
Danke für deine Antwort.
ich experimentiere gerade mit SubVIs. Dabei wollt ich nun eine SubVI erstellen, die Zufallszahlen von 0 bis zu einer einstellbaren Grenze erzeugt und mir den Mittelwert der 5 letzten Zahlen berechnet.
Zur Zeit habe ich das Problem, dass die "Drähte ihren Wert zur Laufzeit nicht ändern", mittels einer zweiten Schleife in der Test VI gelöst. Nur kriege ich jetzt immer nur die 5. und letzte Zufallszahl ausgegeben, bevor das Sub VI zurück gesetzt wird und wieder von neuem beginnt und eben auch nur den Mittelwert aller 5 neuen Zahlen, obwohl ich eigentlich den Mittelwert der letzten 5 haben möchte, d.h. bei Zahl Nummer 7 den Mittelwert von ( 3.+4.+5.+6.+7. Zahl / 5).
MfG
SimpleMinded
Dafür musst du die Schleife einfach sofort beenden (TRUE Konstante an Stop) und die Initialisierung (1) an den Shiftregistern entfernen. Dann wird in jeder Iteration eine weitere Zufallszahl generiert und der Mittelwert der letzten 5 ausgegeben. Die Erstinitialisierung würde man korrekterweise dann noch behandeln müssen.
Deine Versuche zeigen, dass du eines der Grundprinzipien von LabVIEW noch nicht richtig verstanden hast: Datenfluss
Hast du schon die Einführungskurse durchgeackert:
LabVIEW basics
Die dazu passenden Allgemeinplätze:
- Der Draht ist der Speicher.
- Eine Struktur wird erst gestartet, wenn alle Eingänge vorhanden sind.
- Eine Struktur wird erst beendet, wenn alle Ausgänge vorhanden sind.
- THINK Dataflow.
Gruß, Jens
So funktioniert das also. Danke Holy
@jg
Ich weiß, dass ich LabVIEW noch nicht so ganz verstanden habe. Ich bin das Buch "LabVIEW 1" von Peter Groppe und Bernd vom Berg durch gegangen und beschäftige mich mit einigen Tutorials und Seminar PDFs um mich reinzuarbeiten.
Deine Allgemeinplätze denke ich verstanden zu haben:
"Der Draht ist der Speicher" - Die Shiftregister sind hierbei der Draht, die den jeweiligen Zustand auch zwischen zwei Schleifendurchläufen behalten, da ohne die Initialisierung der 1 der Inhalt der Shiftregister nicht überschrieben wird.
"Eine Struktur wird erst beendet, wenn alle Ausgänge vorhanden sind." - Meine Ausgänge sind Zufallszahl und Mittelwert. Erst nachdem diese beiden gelesen wurden, wird der Zustand an der Schleifenbedingung abgefragt.
(18.06.2013 21:59 )SimpleMinded schrieb: [ -> ]"Der Draht ist der Speicher" - Die Shiftregister sind hierbei der Draht, die den jeweiligen Zustand auch zwischen zwei Schleifendurchläufen behalten, da ohne die Initialisierung der 1 der Inhalt der Shiftregister nicht überschrieben wird.
"Eine Struktur wird erst beendet, wenn alle Ausgänge vorhanden sind." - Meine Ausgänge sind Zufallszahl und Mittelwert. Erst nachdem diese beiden gelesen wurden, wird der Zustand an der Schleifenbedingung abgefragt.
"Der Draht ist der Speicher" betrifft insbesondere deine Konstrukte mit den lokalen Variablen. In dienem Mittelwert-VI gibt es keinen guten Grund die Eingabe- und Ausgabeelemente nicht direkt zu verdrahten. Lass die lokalen Variablen weg, denn diese können zu Race-Conditions führen.
"Eine Struktur wird erst beendet, wenn alle Ausgänge vorhanden sind" interpretierst du hier falsch. Wann das Abbruchkritierum deiner Schleife gelesen bzw. gebildet wird ist unbestimmt. D.h. es kann vor dem Code in der Schleife oder auch danach gemacht werden. Die Aussage bezieht sich hier eher auf den Fakt das erst der ganze Code in der Struktur ausgeführt werden muss und dementsprechend alle Ausgänge vorhanden sind bevor es weitergeht. In diesem Fall die Ausführung der nächsten Iteration.
THINK DATAFLOW. Der Datenfluss definiert die Ausführungsreihenfolge. Mit deinen lokalen Variablen hast du keinen Datenfluss der die Ausführungsreihenfolge bestimmt. In deinem speziellen Fall wird es über den Aufruf als SubVI definiert aber sieh es eher als langfristgen Ratschlag. Verwende keine lokalen Variablen wenn es auch ein Draht tut.