Hallo zusammen,
heute hat mir ein Kommilitone ein paar seiner Werke gezeigt. Bei folgender Struktur musste ich ein bisschen die Stirn runzeln ohne wirklich meine Skepsis begründen zu können.
Es war eine State-Machine, die im DAQ-Frame eine Producer-Consumer Architektur hatte.
[
attachment=30054]
Spricht da etwas dagegen? Ich hätte es halt definitiv nicht so gemacht und alles in den beiden inneren Schleife untergebracht ohne was drumherum.
Gruß dimitri
Das kommt darauf an.
Es spricht ganz schwer etwas dagegen, wenn der Datenaustausch über lokale Variable erfolgt. Dann ist die Synchronisation nicht gegeben. Der Producer produziert ohne Rücksicht auf Verluste in seinem Takt darauf los, und der Consumer liest, ja nachdem ob seine Schleife schneller oder langsamer läuft, entweder Werte doppelt oder gar nicht. Dann ist die Zusammenlegung von beidem in einer einzigen Schleife das einzig Wahre.
Bei Verwendung eine Queue zu Übertragung gibt es aber Vorteile bei dieser Struktur.
Z.B. dieses Szenarium:
Die Producer erzeugt gleichmäßig Werte. Der Consumer ist im allgemeinen schneller als der Producer. Solange das der Fall ist, befindet sich in der Queue immer höchstens 1 Element.
Nur manchmal, so sei jetzt mal angenommen, braucht der Consumer länger und ist langsamer als der Producer (wenn z.B. etwas abzuspeichern ist). In diesem Fall macht der Producer gleichmäßig weiter, lediglich die Queue, die sonst immer nur höchsten ein Element enthält, füllt sich mit mehreren Elementen an. Bei den folgenden Zyklen leert sich dann die Queue wieder.
Bei Verzicht auf die Queue und Zusammenlegung von Producer und Consumer in eine einzige Schleife würde der Producer in seiner Erzeugung hingegen sofort gestoppt, wenn der Consumer zur Verarbeitung der Daten mal etwas länger braucht.
Edit: Habe wohl nur Bekanntes gesagt, es ging ja eigentlich um die dritte Schleife ganz außen. Die wird ja nicht mehr durchlaufen, solange die Datenerfassung läuft.
Weder läßt sich die Datenerfassung dann abstoppen noch das ganze Programm beenden. Das sind aber alles nur Hürden für den Anfänger, wie Supergurus haben da natürlich unsere Tricks im Beutel, um das Problem zu lösen
Das mit der Queue hat er schon richtig gemacht. Es ging mir um etwas anderes.
Ich stelle mir das immer so vor, dass eine Schleife einen Thread bekommt und dann gegebenenfalls auch einen "eingenen" Kern zum rechnen (falls mehr als einer vorhanden). Wenn nun aber die Producer-Consumer ihrerseits in einer Schleife drinsteckt, könnte diese Verschachtelung vielleicht zu einer weniger optimalen Verteilung der Ressourcen führen. Wahrscheinlich quatsch und der LV Compiler schafft es trotzdem zwei separate parallele Threads zu erzeugen. Oder?
' schrieb:... und der LV Compiler schafft es trotzdem zwei separate parallele Threads zu erzeugen. Oder?
Bei dem Satz fällt mir was ein: Ich habe letzte Woche nach ner Nebentätigkeit im Institut für Sportinformatik gefragt und als Antwort bekommen: "Wir programmieren hier mit Compiler-Sprachen wie C oder Delphi" ... die halbe Welt denkt LV sei eine Scriptsprache ...
' schrieb:heute hat mir ein Kommilitone ein paar seiner Werke gezeigt. ...
Bei genau diesem Konzept gebe ich folgendes zu bedenken:
- Irgendwann wird das BD so groß, dass es unübersichtlich wird. => Auslagern der While-Schleifen in SubVI (dann ist es nicht mehr "genau dieses Konzept").
- Dieses Konzept verleitet dazu, Lokale Variablen quer zu verwenden. Siehe Lucki. Möglicherweise auch RaceConditions.
- Besteht hier die Möglichkeit, die Loops (eigentlich die Schrittkette) manuell abzubrechen?
Zitat:alles in den beiden inneren Schleife untergebracht ohne was drumherum.
Welches Konzept man verwendet, hängt (auch) vom Einsatzfall der Applikation ab: Habe ich ein professionelles System für einen Kunden oder reicht ein schnelles Laborprogramm, das ich selbst bediene. Für letzteres kann man ohne weiteres das obige Konzept verwenden. Für ein professionelles System würde ich auf jeden Fall zu einer Modularisierung raten. Dann wäre der Producer z.B. ein Standalone-Modul, das in einem SubVI läuft. Dieses SubVI würde dann im MainVI als paralleler Prozess laufen.
' schrieb:Wenn nun aber die Producer-Consumer ihrerseits in einer Schleife drinsteckt, könnte diese Verschachtelung vielleicht zu einer weniger optimalen Verteilung der Ressourcen führen. Wahrscheinlich quatsch und der LV Compiler schafft es trotzdem zwei separate parallele Threads zu erzeugen.
Mach dir da mal gar keine Gedanken. Ich hab zehn, manchmal bis zu zwanzig "Klassen", also parallele Prozesse laufen. Das ist gar kein Problem.
Zitat:und als Antwort bekommen: "Wir programmieren hier mit Compiler-Sprachen wie C oder Delphi" ... die halbe Welt denkt LV sei eine Scriptsprache ...
Ich kann ja auch nicht verstehen, warum man LV nimmt, nur weil man die RS232 abfragen will. Das geht in allen anderen Sprachen einschließlich VB leichter als in LV. Und bis LV die Qualität der Delphi-IDE erreicht hat, muss LV schon noch fünf Versionen nachschieben ...