INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Architekturen in LabView



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!

08.10.2012, 13:27
Beitrag #1

Wendigo Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 114
Registriert seit: Sep 2012

2012
2011
EN

71672
Deutschland
Architekturen in LabView
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
08.10.2012, 18:00 (Dieser Beitrag wurde zuletzt bearbeitet: 08.10.2012 18:07 von Kasi.)
Beitrag #2

Kasi Offline
LVF-Stammgast
***


Beiträge: 342
Registriert seit: Dec 2010

6 - 2009
2005
DE_EN

79194
Deutschland
RE: Architekturen in LabView
Meiner Meinung nach ist diese Liste leider nicht wirklich gut recherchiert Wink
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

If you're havin' serial communication problems I feel bad for you, son, I got 99 problems but a baud ain't one! (except if using USB2serial converters, then I experience serialous problems)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
08.10.2012, 21:42
Beitrag #3

A.Berndsen Offline
LVF-Team
LVF-Team

Beiträge: 2.437
Registriert seit: Feb 2005

8.2.1 - 2011
2004
DE

724xx
Deutschland
RE: Architekturen in LabView
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

Geht nicht, gibts nicht!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 07:52
Beitrag #4

Wendigo Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 114
Registriert seit: Sep 2012

2012
2011
EN

71672
Deutschland
RE: Architekturen in LabView
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?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 08:03
Beitrag #5

Achim Offline
*****
*****


Beiträge: 4.223
Registriert seit: Nov 2005

20xx
2000
EN

978xx
Deutschland
RE: Architekturen in LabView
Hm...Queue oder Notifier?

A.

"Is there some mightier sage, of whom we have yet to learn?"

"Opportunity is missed by most people because it is dressed in overalls and looks like work." (Thomas Edison)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 08:09
Beitrag #6

A.Berndsen Offline
LVF-Team
LVF-Team

Beiträge: 2.437
Registriert seit: Feb 2005

8.2.1 - 2011
2004
DE

724xx
Deutschland
RE: Architekturen in LabView
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

Geht nicht, gibts nicht!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
09.10.2012, 08:13 (Dieser Beitrag wurde zuletzt bearbeitet: 09.10.2012 08:21 von Wendigo.)
Beitrag #7

Wendigo Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 114
Registriert seit: Sep 2012

2012
2011
EN

71672
Deutschland
RE: Architekturen in LabView
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 08:33
Beitrag #8

A.Berndsen Offline
LVF-Team
LVF-Team

Beiträge: 2.437
Registriert seit: Feb 2005

8.2.1 - 2011
2004
DE

724xx
Deutschland
RE: Architekturen in LabView
(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

Geht nicht, gibts nicht!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 08:50 (Dieser Beitrag wurde zuletzt bearbeitet: 09.10.2012 08:57 von Wendigo.)
Beitrag #9

Wendigo Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 114
Registriert seit: Sep 2012

2012
2011
EN

71672
Deutschland
RE: Architekturen in LabView
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 Smile


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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2012, 11:46 (Dieser Beitrag wurde zuletzt bearbeitet: 09.10.2012 11:50 von Lucki.)
Beitrag #10

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Architekturen in LabView
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Gehe zu: