Hilfe beim Gestalten eines modularen Programms gesucht

Hallo LV,

bezugnehmend auf den Beitrag von GerdW, moechte ich mein Programm komplett neu schreiben und "Designer Patterns" nutzen. Ganz sicher, wie es geht, bin ich noch nicht, deswegen habe ich erstmal Anforderungen versucht zu formulieren. Grundsaetzlich muss das Programm leicht erweiterbar sein, daher will ich versuchen, es so ordentlich wie moeglich zu programmieren.

1. Das Programm muss über Stunden laufen und dynamische Abfragen behandeln koennen. Wenn sich etwas aendert, soll das Programm damit fertig werden.
Ich glaube, ich muss es dafür in eine große While-Schleife setzen.

2. GerdW schreibt "schön wäre es, wenn du dein UI von deiner Arbeitsschleife trennst und ein Producer-Consumer-Pattern einführst. Und im Consumer dann noch eine State-Machine zur Abarbeitung deiner verschiedenen States!"

Ich habe mir mal UI in LabView angeschaut. Das sind ja while-Schleifen mit Eventstruktur. Der Plan ist jetzt mehrere "Value changed" in die Eventstruktur einzusetzen. Der User hat dann Knoepfe, um Ereignisse auszuloesen. Hierzu eine Frage: Muss ich die Eventdaten definieren wie in Vortrag p. 50 und sie dann in eine Queue fuettern oder kann der User erst den Knopf druecken, dann wird das Event definiert und an die Consumer-Schleife per Queue weitergereicht? Letzteres scheint mir irgendwie logischer, sonst muesste ich Platzhalter fuer Events vorhalten?

In einer zweitenwhile-Schleife sollen dann die Ereignisse abgearbeitet werden, wenn sie als ausgeloest detektiert worden sind.
Ich hoffe, diese und die Schleife mit den UserEvents ist zusammen ein Producer & Consumer-Pattern?

3. Neben User-Event im User-Interface habe ich noch Geraeteeigenschaften zu setzen und staendig abzufragen. Einige muessen nur einmal am Anfang gesetzt werden, andere können sich nach Usereingabe ständig ändern, müssen dementsprechend dann auch abgefragt werden und dies nicht nur, nachdem die Aktion gelaufen ist, sondern während diese läuft zur Kontrolle. Wo würdet ihr empfehlen, diese Sachen einzubauen?
Kopfzerbrechen bereitet mir auch, eine Art Logprogramm fuer die Pumpe zu integrieren. Dieses Programm soll die Aktionen des Users mitloggen und nach verschiedenen Punkten auswerten. Wo koennten dies denn bitte einen Platz finden?

Danke schoen fuer Eure Antworten und Hinweise.

Gruesse
Blue

Anzeige

Hallo Blue,

zu 1)
Da glaubst du richtig. Jedes (halbwegs vernünftige) Programm, das auf UI-Events wartet, sollte in einer "großen While-Schleife" laufen!

zu 2.)
Du musst nicht, wie in dieser Präsentation gezeigt, erst UserEvents erzeugen. Deine Knöpfe erzeugen schon genügend "Standard"-Events...
Außerdem schickt die ProducerLoop nicht diese Events an den Consumer! Der Producer wertet die UI-Events aus und sendet dem Consumer Kommandos. Diese Kommandos musst du definieren (viele würden hier ein Enum mit entsprechenden Einträgen empfehlen) und in einer geeigneten Datenstruktur an den Consumer weiterreichen. Dieser arbeitet dann die Kommandos ab...

zu 3.)
Ich würde aus den Geräteansteuerungen eigenständige (d.h. parallel laufende) Schleifen machen, die ebenfalls auf Befehle warten (d.h. neue Geräteeinstellungen) und ansonsten den aktuellen Status abfragen. Die Daten könnten man dann über eine FGV bereitstellen... Ein LogProgramm ist auch nichts weiter als eine weitere parallele Schleife, die auf Befehle warten...

' schrieb:Hallo Blue,
zu 2.)
Du musst nicht, wie in dieser Präsentation gezeigt, erst UserEvents erzeugen. Deine Knöpfe erzeugen schon genügend "Standard"-Events...
Außerdem schickt die ProducerLoop nicht diese Events an den Consumer! Der Producer wertet die UI-Events aus und sendet dem Consumer Kommandos. Diese Kommandos musst du definieren (viele würden hier ein Enum mit entsprechenden Einträgen empfehlen) und in einer geeigneten Datenstruktur an den Consumer weiterreichen. Dieser arbeitet dann die Kommandos ab...

Hallo Gerd, danke schoen fuer dein Feedback. Ich habe noch nicht verstanden, wieso der Producer (Erzeuger), die UserEvents verwerten muss.
Warum reicht es nicht, wenn die Events im Producer Loop abgefragt werden und dann an den Consumer-Loop gehen? Erstmal scheint mir das doppelt gemoppelt.
Ich habe mit dem Rohbau sehr schemenhaft angefangen, haenge aber an deinem Vorschlag, UserEvent-Loop mit Producer-Loop zu verbinden. Magst du mir diesbzgl. einen Hinweis geben, damit ich mich bitte weiter vorarbeiten kann?
Danke schoen.

Edit: Ich rate, dass ich es mit einer Queue machen muss, die eventuell als Eingabe das enum haben?

Gruss
Blue

PS: Ist das Vorgehen richtig, wie ich die Knoepfe Infuse, Pause, etc. zuruecksetze? Kann man das schon in der Eventstruktur machen?

Hallo Blue,

wenn du die "mechanische Operation" der Buttons von Switch auf Latch setzt, brauchst du sie erst garnicht "von Hand" zurücksetzen...

Du brauchst auch keine extra Loop, um die UserInterface-Events zu verarbeiten. In der Event-Struktur verschickst du einen Befehl an die Consumer-Loop, die dann die gewünschte Aktion ausführt... Mit dem Event selbst reagierst du ja schon auf die Benutzeraktion!

' schrieb:Hallo Blue,
wenn du die "mechanische Operation" der Buttons von Switch auf Latch setzt, brauchst du sie erst garnicht "von Hand" zurücksetzen...

Hallo. Verzeihung, dass ich die LV-Version vergessen habe.
Ich habe "switch" gewaehlt, weil ich lokale Variablen erzeugt habe, die in der Sequenz diese am Anfang auf false zuruecksetzen. Mit "latch" kann man doch keine lokale Variabeln nutzen. Wie sicherst Du dann bitte ab, dass der Button beim Start des Programms nicht ploetzlich auf true steht?

' schrieb:Du brauchst auch keine extra Loop, um die UserInterface-Events zu verarbeiten. In der Event-Struktur verschickst du einen Befehl an die Consumer-Loop, die dann die gewünschte Aktion ausführt... Mit dem Event selbst reagierst du ja schon auf die Benutzeraktion!

Hier bin ich jetzt verwirrt. Ich brauche also doch keine Producer loop und nur eine Consumer-Loop? Widerspricht das nicht dem Producer-Consumer-Pattern, wonach es zwei Schleifen nebeneinander gibt? Oder sollen Pumpeneigenschaften im Producer-Loop abgefragt werden?
Entschuldige bitte meine Verwirrung ob dieses zweiten Teils deiner Antwort.

Gruss
Blue

Hallo Blue,

du kannst zusätzlich zum "Latch" auch noch einen Default-Wert (bei dir: FALSE) setzen - dann ist der Schalter automatisch auf False, wenn das VI startet.

Du hast doch schon die Event-Struktur in einer Schleife. Diese Schleife ist dein Producer! Hier werden die UI-Aktionen ausgewertet und in Kommandos für den Consumer umgesetzt. Dafür brauchst du nicht noch eine extra Schleife...

Anzeige

' schrieb:Hallo Blue,

du kannst zusätzlich zum "Latch" auch noch einen Default-Wert (bei dir: FALSE) setzen - dann ist der Schalter automatisch auf False, wenn das VI startet.

Was spricht den gegen meine Version mit den lokalen Variabeln bitte? Schlechter Stil, untypisch?

' schrieb:Du hast doch schon die Event-Struktur in einer Schleife. Diese Schleife ist dein Producer! Hier werden die UI-Aktionen ausgewertet und in Kommandos für den Consumer umgesetzt. Dafür brauchst du nicht noch eine extra Schleife...

Aua, I see. Meinst du es so, wie es nun ist im angehaengten Beispiel?
Ich muss also gar nicht die Producer- und Consumer-Loop in eine weitere while-Schleife packen, wenn ich das LabView-Programm immer laufen lassen will? Das habe ich auch noch nicht so ganz kapiert.

Zu deinem dritten Punkt von vorhin, ich wuerde einfach weitere Schleifen neben Producer- und Consumer basteln, die die Geraeteeigenschaften staendig abfragen. Soweit verstehe ich dich. Aber muss man alle "kleineren" Schleifen in eine grosse Packen oder nicht, weil diese alle parallel laufen und ich untereinander mit den Schleifen kommunizieren kann?
Na , sobald das Geraet wieder da ist, probiere ich es sonst mal aus.

Danke schoen und einen Gruss.
Blue

Hallo Blue,

"lokale Variablen"
Warum etwas "von Hand" programmieren, wenn LabVIEW dir die Arbeit abnimmt?

"kleine Schleifen"
Um die Schleifen parallel arbeiten zu lassen, müssen sie nicht in einer großen drinstecken...

Alles weitere ab Montag, jetzt ist Feierabend und Wochenende

Hallo,

also ich halte mich immer eng an die Vorgaben im Labview Style Book.
Ist zwar leider auf Englisch aber ist echt nicht schlecht!

http://www.buch.de/shop/home/rubrikartikel...l?ProvID=271803

Ich hoffe ich habe geholfen.

Lg Jo