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 

Dieses Thema hat akzeptierte Lösungen:

Queue und (kein) Dataflow



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!

29.05.2015, 08:19
Beitrag #1

NoWay Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 241
Registriert seit: Jul 2013

LV-2019
2013
EN


Deutschland
Queue und (kein) Dataflow
Hallo zusammen.

Als ich mit Labview einstieg, habe ich relativ schnell mit Queues gearbeitet. Das Dataflow Prinzip war zum damaligen Zeitpunkt nicht ganz so gefestigt, wie es heute der Fall ist. Man lernt ja schließlich jeden Tag etwas Neues. Nun habe ich es mir zur Aufgabe gemacht, ältere Anwendungen aus meiner Anfangszeit zu überarbeiten und gemachte Fehler auszumerzen und den Code im allgemeinen auf meinen "heutigen Wissenstand" zu optimieren.
Dabei ist mir eine sehr unschöne Sache aufgefallen, die mit den Queues zusammenhängt. Bei einer etwas größeren Anwendungen werden mehrere VI´s als Klon-UI´s aufgerufen, über die der Anwender diverse Steuerungsmöglichkeiten an die Hand bekommt. Dazu wurden verschiedene Queues verwendet, um z.B. Statusmeldungen an ein weiteres VI zu senden. Was die Queues machen, spielt erstmal keine Rolle, sondern wie ich sie implementiert habe. An dieser Stelle breche ich mit dem Datenflussprinzip indem ich in VI 1 ein Obtain mit dem Queuenamen ausführe, der Queue ihre Daten mitgebe und die Queuereferenz nicht explizit an das zweite VI weiterreiche. Die Queue erfasse ich dann im zweiten VI einfach durch den Aufruf eines weiteren Obtain Queue Elements mit dem gleichen Namen. Das führt natürlich dazu, dass man irgendwann total den Überblick verliert. Um dem entgegenzuwirken, will ich die Referenzen nun komplett durchverdrahten. Die Arbeit betrachte ich als Lehrgeld.
Was mich aber jetzt interessiert, ist die Tatsache was das neben der Unübersichtlichkeit für Konsequenzen haben kann. Könnt ihr mir dazu etwas sagen? Gewollt ist das sicher nicht, so wie ich es anfangs gelöst habe.

Gruß
NoWay
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
29.05.2015, 09:23
Beitrag #2

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
RE: Queue und (kein) Dataflow
Queues brechen prinzipiell den Datenfluss, somit spricht erst einmal nichts gegen dein Vorgehen. Du musst bloß aufpassen, dass du pro "Obtain Queue" auch jeweils 1x "Release Queue" verwendest, ansonsten frisst das Speicher.

Ich persönlich verteile Queue-Refnums auch gerne per "Globaler Variable" oder per FGV.

Gruß, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 09:50
Beitrag #3

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: Queue und (kein) Dataflow
Schau Dir mal diese FGV an. Die FGV initialisiert sich beim ersten Aufruf. Damit braucht man keinen Schreibzugriff auf das FGV, es hat als einzigen Anschluß nur den Referenz-Ausgang. Man beachte auch rechts oben das sehr kleine Ikon, es ist kleiner als die meisten globalen Variablen. Damit kommt Ordnung in das System - zumindest was das Aussehen des BD betrifft.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 10:21
Beitrag #4

NoWay Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 241
Registriert seit: Jul 2013

LV-2019
2013
EN


Deutschland
RE: Queue und (kein) Dataflow
Das heißt, ich erzeuge mir FGV´s mit den entsprechenden Datentypen für die Queues und brauche dann keine Queuenamen. Die Zuordnung erfolgt quasi über den VI Namen. Im Klartext: Drei unterschiedliche Queues, drei unterschiedliche FGVs mit den zugehörigen Datentypen. Anstelle der Obtain Queue Elemente rücken dann die FGV´s?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 10:33
Beitrag #5

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
RE: Queue und (kein) Dataflow

Akzeptierte Lösung

Ja, das ist eine Möglichkeit. Alternativ kannst du auch mehrere Queue-Refnums in einem FGV erzeugen und verwalten. Das liegt bei dir.

Gruß, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 10:40
Beitrag #6

NoWay Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 241
Registriert seit: Jul 2013

LV-2019
2013
EN


Deutschland
RE: Queue und (kein) Dataflow
Das ist ja richtig sexy Tongue
Spiele gerade damit rum und schon erschließen sich haufenweise neue Möglichkeiten. Danke für diesen Codeschnippsel!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
29.05.2015, 11:56 (Dieser Beitrag wurde zuletzt bearbeitet: 29.05.2015 11:59 von Kiesch.)
Beitrag #7

Kiesch Offline
LVF-Stammgast
***


Beiträge: 394
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04103
Deutschland
RE: Queue und (kein) Dataflow
So wie ich verstanden habe, ist die FGV eigentlich nur für eine einzelne Queue brauchbar, die man an verschiedenen Stellen benutzt. Hier geht es so wie ich das verstanden habe ja eher um viele Queues die verwendet werden / werden sollen und darum, dass die bisher per Queue Name erzeugt werden (so dass über den Namen die Verknüpfung der beteiligten VIs entsteht).

Der offensichtliche Worst Case ist dabei natürlich, dass man Queues verbindet die eigentlich nix miteinander zu tun haben sollten, weil man die Übersicht verloren hat (= nicht so schön für die Wartbarkeit; wird nicht automatisch sichergestellt, dass das nicht der Fall ist).
Das muss aber nicht so gravierend sein, dass man deswegen alles ändern muss. Kann man ja auch durch Regeln zur Namensfindung sicherstellen.

*edit*
Da es auch zur Sprache kam: Klar kann man auch unterschiedliche Queues damit verwalten, aber letztendlich landet man dann doch wieder im Namensgebungsproblem. Und ob LV von Haus aus verwaltet, welche Namen man den Queues gegeben hat und die entsprechend verknüpft, oder ob das meine FGV für mich macht, ist dann unterm Strich vermutlich der gleiche Aufwand und hat das gleiche Problem (das man eindeutige Namen braucht an einer Stelle).
Dafür würde ich mir vermutlich nicht den Aufwand machen das umzubauen ^^

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 12:03
Beitrag #8

Trinitatis Offline
LVF-Guru
*****


Beiträge: 1.694
Registriert seit: May 2008

7.1 / 8.0 /2014-1, 18
2002
DE

18055
Deutschland
RE: Queue und (kein) Dataflow
Der Vorteil bei der Verwendung der FGV liegt halt darin, dass es diese nur einmal gibt. Und darin kann ich ja auch mehrere Queuereferenzen verwalten.

Die Verwechslungssicherheit stelle ich über die Nutzung immer derselben FGV mit eindeutiger Namensgebung der Queue-Referenzenausgänge (wenn es denn mehrere sind)
Im übrigen muss ja auch der Datentyp passen - ich kann also nicht 2 verkehrte Queue-Referenzen miteinander verknoten, wenn deren DTyp nicht gleich ist.


Gruß, Marko
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.05.2015, 15:29
Beitrag #9

BNT Offline
LVF-Freak
****


Beiträge: 740
Registriert seit: Aug 2008

5.0 - 22Q3
1999
EN

64291
Deutschland
RE: Queue und (kein) Dataflow
(29.05.2015 09:23 )jg schrieb:  Queues brechen prinzipiell den Datenfluss,...
Gruß, Jens

Das stimmt nicht. Queues brechen den Datenfluß NICHT! Ein Element wird in den Enqueuer hineingeschoben und kommt beim Dequeuer wieder heraus. Das ist Datenfluß, nur dass man den Draht nicht sieht. Die Daten bewegen sich sozusagen durch den Hyperraum.

Gruß Holger

NI Alliance Partner & LabVIEW Champion
GnuPG Key: 6C077E71, refer to http://www.gnupg.org for details.
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
01.06.2015, 11:56
Beitrag #10

Kiesch Offline
LVF-Stammgast
***


Beiträge: 394
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04103
Deutschland
RE: Queue und (kein) Dataflow
(29.05.2015 12:03 )Trinitatis schrieb:  Der Vorteil bei der Verwendung der FGV liegt halt darin, dass es diese nur einmal gibt. Und darin kann ich ja auch mehrere Queuereferenzen verwalten.

Die Verwechslungssicherheit stelle ich über die Nutzung immer derselben FGV mit eindeutiger Namensgebung der Queue-Referenzenausgänge (wenn es denn mehrere sind)
Im übrigen muss ja auch der Datentyp passen - ich kann also nicht 2 verkehrte Queue-Referenzen miteinander verknoten, wenn deren DTyp nicht gleich ist.


Gruß, Marko

Bei der Frage ging es doch scheinbar um Skalierbarkeit auf sehr viele Queues mit unterschiedlichsten Namen. Wenn ich die in ner FGV mit ka 3 Ausgängen für die 3 Queues die ich möchte verwalten kann, dann kann ich auch gleich eindeutige Namen für die Zuordnung verwenden und mir darüber die Queues holen. Hab ich aber 100 Queues und bin mir deswegen nicht sicher ob es nicht doch mal bei der 101. zu ner Namenskollision kommt, dann ist meiner Meinung nach der FGV Ansatz genausogut / schlecht wie eindeutige Regeln zur Namensgebung. Schließlich kommt man bei so vielen Queues letztlich nicht umhin irgendwie anzugeben, welche genau man grade anfragen will. Und dann is man wieder dabei, dass man aus der FGV über nen Namen ne Queue Referenz holt - das kann LV numal auch schon mit Bordmitteln ohne FGV. Alternativ könnte man sicherlich auch nen Cluster bauen in den man alle Queue Referenzen reinpackt, dann dürfte sich LV vermutlich zumindest regen, wenn man eine Neue Queue identisch bezeichnen möchte. Allerdings wird auch das bei vielen Queues sicher schnell unübersichtlich.

Deswegen meiner Meinung nach: Wenn man durch sinnvolle Namensgebungsregelungen (Was weis ich; [Funktionsbeschreibung]_[VIName]_[Projekt]_[Out|In]) oder whatever sicherstellt, dass es eigentlich nicht zu Kollisionen kommen kann, dann fährt man genauso gut / schlecht wie mit der FGV. Will damit nicht sagen das die Idee schlecht ist; im Gegenteil, so kann man gut eine begrenzte Zahl an "Informationen" / Startparametern in den VIs verteilen bzw. zur Verfügung stellen. Nur löst die halt nicht wirklich das Problem Skalierbarkeit. Da würde man sich dann eher nen System anbieten, dass möglichst unabhängig von der Bezeichnung ist.
An sich (habe noch nicht damit gearbeitet) scheint da doch fast das Actor framework die passende Lösung für das Problem zu sein. Soweit ich das überblicke ist da doch grade die Idee, dass jedes Objekt als Akteur gehandhabt wird, mit dem man reden kann (intern über Queues). Die Verwaltung der entsprechenden Verbindungen ist da doch auch schon vereinfacht gehandhabt meines Wissens.

Tl; dr: Die FGV Lösung skaliert meiner Meinung nach genauso schlecht bei vielen Queues (und grad um Skalierbarkeit gings hier ja) wie das anfordern von Queues über einen eindeutigen Namen. Interessant für das eigentliche Problem könnte eventuell auch ein Blick auf das Actor Framework sein.

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Kein leeren sondern gar kein String in Array einfügen Philipp_O 3 3.067 25.08.2022 15:06
Letzter Beitrag: Kiesch
  kein proportionales skalieren ... erzengelsamael 2 3.538 05.12.2017 08:05
Letzter Beitrag: erzengelsamael
  Dataflow Verständnis Beispiel 911tom 9 5.015 28.11.2017 07:54
Letzter Beitrag: GerdW
  Wie auf abgearbeitete Queue warten mez15 11 6.768 28.09.2017 13:02
Letzter Beitrag: TR61
  Datum Uhrzeit Queue DeleteAll 8 4.663 24.03.2017 15:47
Letzter Beitrag: GerdW
  TDMS in Queue laden gifo 8 4.621 07.01.2016 16:41
Letzter Beitrag: GerdW

Gehe zu: