Datenfluss

Habt ihr ein paar kleinere Beispiele, wie man einen Datenfluss gezielt erzeugt und steuern kann? Also wie man eventuell ganz leicht sagen kann, erst kommt meine ForSchleife 1 und danach Die ForSchleife 2 und somit das umgekehrte ausführen verhindern?

Alles zum Thema "Datenfluss" kann auch gleich hier mit in den Thread.

Es gibt eine Brachialmethode: einfach einen Draht durch alles durchlegen. Dann wird alles so verarbeitet, wie es der Draht vorschreibt.

Oder schöner: Das Blockdiagramm in logische Teile zerlegen und die dann in SubVIs auslagern. Diese SubVIs werden dann - wie es sich gehört - mit dem sogenannten Errorcluster sequenziert. Manche Sachen, wie z.B. das Reagieren auf einen Button, werden normalerweise nicht mit Datenfluss, sondern mit Ereignisstrukturen realisiert.

Ein Beispiel hab ich gerade nicht bei der Hand.

Ich mache es mit Labview so wie mit meinem Hund: den lasse ich gern ohne Leine laufen. Dies Forum ist voll von geposteten negativen Beispielen der anderen Art: Die wird - hauptsächlich mit massenhafter Anwendung von überflüssigen Sequenzstrukturen - der Progammablauf in ein künstliches Korsett hineingezwängt, der von der Datenabhängigkeit her gar nicht zu begründen ist.
Wenn dieser Thread dieser Tendenz vielleicht noch Auftrieb geben sollte, dann wäre ich dafür, daß er lieber gleich wieder geschlossen wird.

Oh nein, der Thread soll nichts Flamepushen oder die Leute in ihrer Programmieart gänzlich versauen. Nur habe ich den Begriff "Datenfluss" eingegeben und bin dafür, in einem ordentlichen Forum sollte dann auch ein Thread "Datenfluss" ganz oben stehen und dadrin erklärt werden, was ist ein Datenfluss, wie realisiert man diesen. Ich als Neuling bekomme es ja auch hin, mir meine Informationen soweit es geht zusammen zu suchen und daraus zu lernen, aber wenn ich in einen Thread namens Race Condition gehe und da wird über ein Problem geschrieben statt eine Erklärung, was ein Race Condition ist, dann hilft mir das nicht so richtig weiter. Somit versuche ich meine Wissenlücken zu füllen und gleichzeitig das Forum zu komplettieren. (sry, wenn das so eigentlich nicht gedacht ist, ich will nur nicht zu dem "Ich hab 20 Fragen in einen Thread"-Stil zurück)

Also wie muss ich mir das vorstellen, einfachen einen Draht durch alles zu ziehen?

Zitat:Also wie muss ich mir das vorstellen, einfachen einen Draht durch alles zu ziehen?

Hast du die Antwort von IchSelbst nicht gelesen?!

Datenfluss in LabVIEW heißt: An einem Knotenpunkt geht es erst weiter, wenn alle angeschlossenen Drähte mit einem Wert belegt sind. Ein Knotenpunkt kann z.B. ein subVI oder eine Struktur (Schleife, Case-Struktur etc.) sein.

D.h. nicht, dass es sonst keine Möglichkeit gibt, bestimmte Algorithmen zu sequenzieren - siehe z.B. State-Machine.



PS Bitte jetzt keinen Thread namens "State-Machine" öffnen!

Der gößte Vorteil von LV ist, dass "quasi-parallele" Verarbeitung nicht nur möglich ist, sondern mehr oder weniger von vornerein gegeben ist.
Was Lucki sagen wollte war glaube ich, dass die meisten damit nicht zurecht kommen. Sie wollen in LV unbedingt so programmieren wie in C&Co. Deswegen nehmen sehr viele ständig die Sequenzstruktur (eine der einfachsten, aber wohl auch unschönsten Möglichkeiten, Datenfluss, also Abarbeitungsreihenfolge zu realisieren).
Ich LV sollte nur dann Datenfluss festgelegt werden, wenn ich das auch wirklich brauche (z.B. um die angesprochenen RaceConditions zu vermeiden) und nicht weil ich das von C oder C++ so gewohnt bin.

So, nun mal allgemein: Es gibt verschiedene Möglichkeiten Datenfluß sicherzustellen:

1. Sequenz (nur im Notfall nutzen; die geschachtelte am besten gar nicht! Da blickt keiner auf die schnelle durch, der ein Programm das erste mal sieht)

2. Drähte

Eine Schleife oder ein SubVI wird erst ausgeführt wenn alle Drähte Daten anliegen haben. D.h. wenn einer noch nicht so weit ist, wird einfach gewartet, und an anderer Stelle des Programms weitergearbeitet.
Ich kann einen Draht auch an eine Schleife anlegen, und ihn innen gar nicht nutzen oder nur durchschleifen, aber so habe ich den Datenfluß.
Für SubVIs sollte immer mit Fehler-Clustern gearbeitet werden. 1. Muss ich das VI vielleicht gar nicht mehr ausführen wenn vorher schon ein Fehler war, 2. wissen alle SubVIs und das MainVI wenn ein Fehler auftritt und 3. habe ich schon wieder Datenfluß und -sicherheit, wenn ich das brauche.


Hilft Dir das erstmal weiter?
Ich glaube nicht das das was ich hier jetzt von mir gegeben habe vollständig ist, aber es sollte zumindest nichts falsches dabei stehen, und bildet zu 100% meine Meinung ab

Anzeige

Hab ich halt mal ein Bild gemacht.

Ich muss mich da IchSelbst voll anschließen. Der korrekte Datenfluss entsteht in den meisten Fällen schon ganz von selbst wenn man konsequent und sauber den Fehlercluster verdrahtet. Gerade die korrekte Fehlerbehandlung erzwingt Datenfluss in meinen Augen von ganz allein. Wann soll was unter welchen Bedingungen ausgeführt werden. Man brauch keine serielle Schnittstelle auslesen, wenn die Initialisierung dieser vorher schief gegangen ist. Oder anderes herum gesagt, wenn die Initialisierung ohne Fehler von statten ging, dann lese die serielle Schnitstelle aus. Und woher weiß ich ob es klappte? Aus den Daten des Fehlerclusters. (ok da wäre noch die VISA Session, aber zur Anschauung sollte es reichen.) Auch bei parallel laufenden Prozessen kann man dieses Vorgehen teilweise anwenden. Ich lese zwei Geräte parallel und zunächst abhängig voneinander aus. Anschließend muss ich irgendwann einmal beide Messwerte für eine Berechnung heranziehen. Diese lohnt aber auch nur, wenn beide Messungen korrekt von statten gingen, ansonsten ist das Ergebnis irgendwie Müll. Spätestens nach den Messungen sollte man dann die Fehlercluster beider Prozesse zusammenfassen "Merge Errors.vi" und ab dieser Stelle greift dann wieder das Datenflussprinzip.

Schöne Grüße
Falk