Hallo,
ich stelle gerade Recherchen über verschiedene Architekturen an. Leider ist der Informationsfluss meiner Meinung nach recht mau.
Vielleicht könnt ihr mir da helfen. Bisher habe ich folgende Architekturen ausgemacht.
-Statemachine
-Master Slave Architektur
-Producer - Consumer Loop
-Event Loop
Fallen euch noch welche ein und könnt ihr mir zu den bisherigen was sagen?
Ich kann mir z.B. ein Master Slave Betrieb bei Wasserpumpen vorstellen, aber keine Master Slave Architektur bei Software.
Meiner Meinung nach ist diese Liste leider nicht wirklich gut recherchiert
Master/Slave und Consumer/Producer ist exakt das gleiche, den Event-Loop würde ich nicht wirklich als "Architektur" sondern eher als Bauteil ansehen (kann zum Beispiel Bestandteil der Producer/Consumer-Struktur sein)
LabVIEW bietet hier schon eine sehr nette Beispiele mit ihren vorgefertigten Templates unter File -> New... -> from Template -> Frameworks -> Design patterns. Dort findest du dokumentierte Grundgerüste.
***edit*** achja, die State-Machine hab ich vergessen. Hier hatte ich selbst ein paar Verständnisschwierigkeiten, was die Implementierung bzw. sinnvolle Nutzung in LabVIEW angeht. Hier hat mir ein Tutorial weitergeholfen, was die Wichtigkeit von Typedefs und die Nutzung von Statemachines sehr schön illustriert. Wenn du des englischen mächtig bist, findest du diese Tutorials
hier
Hallo Wendigo,
Kasi hat ja schon etwas Licht ins Dunkel gebracht.
Ich würde noch als eine Art von "inline" Architektur die FGV (Funktionale Globale Variable alias Action Engine) ins Feld werfen.
Die ist hier im Forum schon häufig behandelt worden. z.B.
hier oder bei IBB
hier und
hier.
Lohnt sich allemal anzuschauen und zu verstehen wie das funktioniert.
Grüße
Andreas
FGV würde ich gern als Schnittstelle bzw. zur Kommunikation zwischen einer Master und zwei Slave Schleifen verwenden.
Würdet ihr das befürworten oder doch eher was anderes empfehlen?
Hm...Queue oder Notifier?
A.
Das geht aber evtl. auch sehr simpel mit Queues.
Hängt alles davon ab, welche Daten vom Master (Erzeuger) erzeugt werden und was die Slaves (Verbraucher) damit anstellen sollen.
Bekommen die Slaves vom Master unterschiedliche Daten oder arbeiten sie mit den selben Daten?
Grüße
Andreas
Die Master-Schleife habe ich als GUI vorgesehen. Also einfache Bedienung und die Anzeige von ein paar Werten, die eine Slave ausspucken sollen.
Die zweite Slave ist für die Statistik, einfache Zahlenwerte zuständig.
(09.10.2012 08:13 )Wendigo schrieb: [ -> ]Die Master-Schleife habe ich als GUI vorgesehen. Also einfache Bedienung und die Anzeige von ein paar Werten, die eine Slave ausspucken sollen.
Die zweite Slave ist für die Statistik, einfache Zahlenwerte zuständig.
Das muß ich jetzt erst mal ordnen.
Ein Slave spuckt Daten aus, ein Slave macht damit statistische Berechnungen und der Master regelt die Anzeige.
In meinem Verständnis wäre dann die Daten erzeugende Schleife der Master (Erzeuger).
Statistikberechnung und Anzeige (Verbraucher) wären dann die Slaves.
Schau dir erst mal unbedingt das Producer/Consumer Template an und erstelle ein Flußdiagramm für Deine Anwendung.
Grüße
Andreas
Hmmm. Vielleicht habe ich mich undeutlich ausgedrückt.
Zum Bleistift:
Ich habe ein Programm das die Anzahl von Controls in einem VI zählt.
Im GUI habe ich den Button "Start","Abbruch" und "Statistik". Der Funktionszweck der Buttons müsste klar sein
Die eine Slave Schleife Zählt die Anzahl der Controls in einem VI und gibt deren Anzahl für den aktuell laufenden Test auf einem Display in der GUI geordnet nach deren Class ID aus.
Die zweite Slave Schleife erfasst vorlaufend die erfassten Werte aller bisher gestarteten Tests und gibt die Anzahl aller bisher erfassten Controls in der Statistik aus, sowie nach Class ID geordnet.
Zitat:Master/Slave und Consumer/Producer ist exakt das gleiche, den Event-Loop würde ich nicht wirklich als "Architektur" sondern eher als Bauteil ansehen (kann zum Beispiel Bestandteil der Producer/Consumer-Struktur sein)
Zitat:Ein Slave spuckt Daten aus, ein Slave macht damit statistische Berechnungen und der Master regelt die Anzeige.
Der "Master-Slave-Modus" ist eine Busarchitektur bei der Datenkommunikation, aber doch wohl keine Architketur von Programmen.
Der "Slave" sendet für gewöhnlich Daten, das ist richtig, aber deswegen ist er noch kein "Slave". Er ist es dewegen, weil er nur dann senden darf, wenn er vom Master dazu aufgefordert wird. Ansonten hat er die Klappe zu halten.
Das macht die Kommunikation in einem Bussysten mit mehreren Teilnehmern einfach. Der Master bestimmt, wer seine Daten senden darf. Damit kann es keine Daten-Kollisionen auf der Leitung geben.
Und es es gibt außerdem Anfänger, die von beiden (also Erzeuger-Verbraucher- und Master-Slave-Srukturen) mal etwas gehört haben und das dann durcheinander werfen oder denken, es handele sich um Synonyme.