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 

Modularer Aufbau eines größeren LabVIEW Programms - Kommunikation zw. Programmteilen



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!

19.06.2015, 12:15
Beitrag #6

Trinitatis Offline
LVF-Guru
*****


Beiträge: 1.694
Registriert seit: May 2008

7.1 / 8.0 /2014-1, 18
2002
DE

18055
Deutschland
RE: Modularer Aufbau eines größeren LabVIEW Programms - Kommunikation zw. Programmteilen
(19.06.2015 10:51 )n4f3ts schrieb:  Die MasterQueue wo alle Slaves reinschreiben sieht dann in etwa so aus. Sie wird im Blockdiagramm des Masters wie folgt initialisiert:
im Prinzip ja. Ich würde allerdings den Queuedatentyp anders wählen. Das schöne bei den LabViewqueues ist ja, dass jede (bestehende) Queue namentlich von jedem VI des Prozesses angefordert werden kann. Dann würde ich Absender und Adressaten auch namentlich (als String) verwenden

(19.06.2015 10:51 )n4f3ts schrieb:  Und wenn beispielsweise Slave A mit Slave B kommunizieren möchte schreibt Slave A folgendes in die Master Queue (die wiederum im Blockdiagramm von allen Slaves angefordert wird):

Die Masterqueuereferenz würde ich einfach in eine GV oder in eine FGV schreiben. Das erspart dir die Anforderung derselben Queue in jedem Teilnehmer. Da der Master das zuerst aufzurufende VI sein sollte, muss diese Queue für jeden Teilnehmer bereits bestehen und referenzierbar sein.

(19.06.2015 10:51 )n4f3ts schrieb:  Der Master sieht dann von wem die Nachricht kommt und für wen sie ist und leitet entsprechende Befehle über die Queue des Empfängers (in diesem Beispiel Slave B) weiter.

Der Master muss sich im Normalfall nicht um den Absender kümmern. Er kann einfach den Adressaten auslesen und die Nachricht weiterleiten.

Was bei dir komplett fehlt ist eine Nachrichten-ID. Mach verschiedene ID-Klassen auf, die dem Master sagen, was für eine Art Nachricht das ist.
z.B.

Klasse 0-1000 --> Nachrichten der Slaves für den Master bestimmt
ID:1 --> Anmeldung
ID:2 --> Abmeldung


Klasse 1001-2000 --> Nachrichten der Slaves untereinander
ID:1001 --> Nachricht zum weiterleiten
ID:1002 --> Nachricht von einem Slave an alle anderen (z.B. für Zugriffssteuerung, Ausgrauen etc.)

So kannst du die ID an eine Casestruktur koppeln und die entsprechenden Aktionen ausführen.
Und schreib dir von Anfang an eine Doku (Excelsheet) in der du aufschreibst, welche ID wofür ist

(19.06.2015 10:51 )n4f3ts schrieb:  Eine Frage noch hierzu:
Zitat:Danach muss sich dieser Slave beim Master anmelden und ihm seinen Queuenamen oder die Queuereferenz mitteilen.

Das hört sich für mich danach an, dass die Slave Queues dynamisch im Master erstellt werden könnten. Oder liege ich da falsch? Also ich hätte diese jetzt manuell für jeden Slave hinzugefügt.
Die Slavequeues sollen nicht dynamisch im Master erstellt werden, er muss nur wissen, welche Teilnehmer es gibt und wie deren Queues heißen. Es kann ja sein, dass der Master von sich aus mit seinen slaves reden will. Dazu braucht er eine Übersicht, welche Slaves überhaupt da sind. Du kannst dr auch eine schlaue Namenshierarchie der slaves ausdenken und deren Queuenamen an ihre VI-Namen koppeln. Dann muss der Master nur die Namen der angemeldeten slaves kennen und kann so auf ihre queuenamen schließen um mit ihnen zu reden.


Gruß, Marko
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Nachrichten in diesem Thema
RE: Modularer Aufbau eines größeren LabVIEW Programms - Kommunikation zw. Programmteilen - Trinitatis - 19.06.2015 12:15

Gehe zu: