LabVIEWForum.de

' schrieb:I. Soweit so gut. Der Verbraucher
fordert diesen Melder nun an und mit "auf Meldung warten" verarbeitet er den Melderinhalt.
Klappt auch alles soweit. Nun ist es aber ja so, dass während der Melder wartet der restliche
Programmteil lahmgelegt ist.

So kann man das nicht sagen. Es wird nur das nicht ausgeführt, was von den Daten das Melders abhängig ist, alles andere wird ausgeführt. In Deinem Fall ist das Einzige, was abhängig ist, die Aktualisierung des Graphen. Nicht abhängig ist alles andere, als in Deinem Beispiel der Eigenschaftsknoten und alles andere was sich innerhalb und außerhalb der While-Schleife befindet. Aber natürlich wird der Eigenschaftknoten nur einmal pro Scheifendurchlauf ausgeführt, also nicht häufiger als die Aktualisierung des Graphen. Du kannst aber davon ausgehen, daß der Eigenschaftsknoten bei jedem Schleifendurchlauf als erstes ausgeführt wird.

Aber ich stimme Dir zu, daß das Diagramm sowohl ruckelt als auch daß Du das subjektive Gefühl haben mußt, der Eigenschaftknoten wird lahmgelegt. Das liegt an Deiner Programmierung, Du solltest außerhalb der Schleife ein zweite Schleife mit einer Ereignisstruktur haben und die Wertänderung von XAchse.Maximum als Ereignis behandeln. Damit erreichst Du a) daß das Diagramm sofort auf das Bedienereignis reagiert (und nicht erst beim Eintreffen neuer Diagrammdaten), b) daß der langsame Eigenschaftsknoten nicht mehr in der Hauptschleife liegt, und c) daß die X-Achse nicht sinnlos bei jedem neuen Datenpunkt neu justiert wird (Was das Ruckeln verursacht), sondern nur wenn es wegen Wertänderung wirklich sinnvoll ist

Hmm ok danke erstmal.

So arbeite ich bisher, mit globaler Variable für das Signal.
Problem hierbei ist, dass ich eine unwahrscheinlich hohe CPU
Auslastung damit habe. Deswegen wollte ich das jetzt mit Notifier
realisieren. Damit das ganze nur bei Wertänderung abgearbeitet wird.

Also müsste ich sämtliche Eigenschaften jetzt in eine 2. parallele While-Schleife packen und ein
Ereignis für jedes Bedienelement erstellen? ich seh echt dagegen an, weil ich habe echt viele VIs
jetzt so gestaltet die alle mit dieser einen Global arbeiten.

Wenn ich jetzt auf die Verwendung dieser Global pochen würde, kann ich die CPU Auslastung von 100%
(tritt sofort bei Nutzung von nur einem Sub-VI auf) irgendwie anders runter drücken?

Bzw. würde es reichen innerhalb meiner gezeigten while Schleife aus den Eigenschaftsknoten
Ereignisse zu machen, so dass nur dann etwas passiert?

edit: Ok ich komme wohl nicht drum zu, da hab ich ja wieder einen ganz ganz tiefen
Griff ins Klo gelandet

So, brauche nochmal eure Meinung, bevor ich jetzt alles auf Notifier umstelle,
wollte ich nochmal nachfragen, ob dies jetzt die korrekte Herangehensweise ist.

Der Erzeuger erstellt den Melder und sendet das Signal aus.

Der Verbraucher soll nur den Melder abfragen, keinen neuen erstellen
wenn keiner da ist. Das hat den Grund dass der Verbraucher (Sub-VI)
geschlossen werden soll, wenn das Haupt-VI beendet wird.

Zu sehen im Verbraucherbild 1 ist der Timeout case, in dem der
Melderstatus als lokale Variable zum Schleifenabbruch verwendet wird.
Im Verbraucherbild 2 sieht man die Änderung des Maximalwertes der X-Achse.

So jetzt richtig oder kompletter Murks?

Murks nicht, aber Verbesserungen sind schon denkbar.
Erzeuger VI:
a) Die Sequenz ist komplett überflüssig, die richtige Reihenfolge der Ausführung ergibt sich von selbst durch die Datenfluss-Steuerung
b) Die Daten werden hier mit maximaler Geschwindigkeit, also was der PC hergibt, erzeugt. Es ist fraglich, ob das Verbraucher-VI da mithalten kann. Das Erzeuger VI kann synchronisiert zwar das Verbraucher-VI, aber bei Datenraten höher als die Daten- Verarbeitungszeit funktioniert das natürlich nicht mehr. (Also: Uhr einfügen)

Verbraucher-VI: Deine richtigen Worte ("Keinen neuen Melder erzeugen") stehen im krassen Widerspruch zu deinen (Un-) Taten: Du erzeugst sogar bei jedem Schleifendurchlauf den Melder wieder neu. Richtig wären zwei Möglichkeiten: a) Nur einmal den Melder vor der Schleife neu erzeugen, dabei auf gleichem Namen wie beim Haupt- VI achten ("Melder1" im Haupt-VI und "Melder 1" im Sub-VI würde nicht funktionieren), oder b) überhaupt keinen Melder im Sub-VI erzeugen, und den dicken Strang oben rechts aus der Meldererzeugung im Haupt-VI als Input in das Sub.Vi schicken.

Das Beenden soll mal jemand anders kommentiere, mir fehlt jetzt die Zeit.

' schrieb:Verbraucher-VI: Deine richtigen Worte ("Keinen neuen Melder erzeugen") stehen im krassen Widerspruch zu deinen (Un-) Taten: Du erzeugst sogar bei jedem Schleifendurchlauf den Melder wieder neu.

Ah da habe ich glaube ich einen Denkfehler drin gehabt in der Angelegenheit.
Dann habe ich den Baustein "Melder anfordern" wohl irgendwie falsch verstanden.
Wozu ist denn dann der Eingang gut, "Neu erzeugen T/F"?

Ich möchte eigentlich nur in jedem Durchlauf des Verbrauchers gucken ob der Melder
überhaupt noch existiert. Ich denke dann muss ich den Melder quasi nur einmal
im Verbraucher anfordern, und in der Schleife dann den Baustein "Melderstatus" verwenden.

Weil wenn ich nur den "Melder anfordern" aus der Schleife herausnehme, funktionert das nicht mehr
so wie ich wollte, denn es wird dann einmal der Melder an die Schleife übergeben, und der Status
den ich diesem Melder entnehme bleibt ewig gleich und das Programm wartet ewig
auf den Melder.

Da ich aber möchte dass die Verbraucher aufhören ersetze ich das Melder anfordern jetzt mit Melderstatus.

P.S. Übers beenden usw braucht ihr euch keine Gedanken machen, das hier ist nur beispielhaft für
die Meldergeschichte.






edit: So hab ich den Verbraucher nun beispielhaft, danke Lucki (Hoffe mal ist jetzt keine Untat mehr)

edit2: Mir lässt das ganze irgendwie jetzt keine Ruhe, ich habe ein bisschen Probleme mit der Wortwahl in
den ganzen Beiträgen zu dem Thema..

Also nochmal zur Erzeuger-Verbraucher Sache:

Erzeuger: Baustein "Melder anfordern" Eingang erzeugen wenn nicht vorhanden = True
Das leuchtet mir ein, genauso stelle ich mir das vor.

Der Verbraucher wieder "Melder anfordern (mit gleichem Namen), erzeugen wenn nicht vorhanden = False.
Jetzt zur Frage, Lucki hat mir geantwortet dass bei mir im Verbraucher jedesmal wieder ein Melder erzeugt wird.
Aber sollte es nicht so sein, dass wenn "Melder anfordern" sieht dass dieser Name vorhanden ist er quasi nur
nen dicken Pfeil auf die Stelle legt wo dieser liegt und das weiter gibt zu "auf Melder warten"?
Sonst würden ja wie ichs erst hatte permanent 2 Melder mit dem gleichen Namen existieren, ich dachte aber
das läuft quasi so, dass 1 Melder existiert und einer was reinschiebt und danach der andere was rausnimmt,

Fazit: Ich habe aus der LabVIEW Hilfe das Anfordern so verstanden:
Fall a) Melder gibts noch nicht ---> erstelle einen oder nicht je nach Eingang T/F
Fall b) Melder gibt es schon ---> kommuniziere über diesen

irgendwie ist mir das unklar.. Wahrscheinlich ist es jetzt auch so unklar beschrieben

' schrieb:irgendwie ist mir das unklar.. Wahrscheinlich ist es jetzt auch so unklar beschrieben

Ich habe längere Zeit keine Melder mehr benutzt und habe Dich wohl zu Unrecht irgendwelcher "Untaten" bezichtigt. Hatte ganz vergessen, daß es da den booleschen Eingang "Erzeugen, wenn nicht gefunden?" gibt, und daß bei false dann kein neuer Melder erzeugt wird.
Trotzdem halte ich die jedesmalige Prüfung, ob der Melder noch existiert, für überflüssig. Auch in Deinem letzten Programm, in dem Du den Melderstatus überprüft. Wenn der Status einen Fehler anzeigt, dann wird ja trotzdem der Rest in der Schleife noch abgearbeitet, bevor sie beendet wird. Wenn Du also die Statusabfrage wegläßt und einfach den Fehlerstring hinter dem VI "Auf Meldung warten" abfragst, würde alles genau so funktionieren. Die Statusabfrage macht meiner Meinung nach nur Sinn, wenn Du daran einen Case anschließt, um in Abhängigkeit vom Status den Rest in der Schleife entweder auszuführen oder nicht auszuführen.

Ah ok, nun ist alles klar soweit. Dann lass ich den Status mal weg, weil
ob die Schleife diesen einen Durchlauf bei fehlendem Melder noch zuende
ausführt oder nicht spielt in meinem Fall keine Rolle.

Besten Dank Lucki