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!
09.02.2018, 13:58 (Dieser Beitrag wurde zuletzt bearbeitet: 09.02.2018 13:59 von blackberry.)
Hallo,
ich arbeite an einem LabView Projekt, in dem es um die Visualisierung und Fernsteuerung von Elektronischen Lasten/Quellen geht.
Es Geht um Elektronische Geräte der Firma EA aus der ELR9 und PSI9 Serie.
Meine Frage hier bezieht sich auf den grundsätzlichen Programmaufbau.
Im Rahmen meines Projekts werde ich maximal 6 Geräte dieses Herstellers einbinden. Das Gesamte Programm sollte aber so lange erweiterbar sein, bis 20 Geräte angeschlossen sind.
Bitte seht euch meine angehängte Grafik an. Das ist meine grundsätzliche Vorstellung von diesem Programm.
Ich möchte einen Home Bildschirm, in dem ich jedes Gerät auswählen kann und damit auf die Messanzeige des jeweiligen Gerätes komme. Auch sollen auf dieser Seite ein paar Daten jedes einzelnen Gerätes zu sehen sein.
Von der Messanzeige aus soll man zwei weitere Bedienfelder aufrufen können. Den Funktionsgenerator und die Fehlerbehandlung (interne Fehler des Gerätes). Von diesen beiden Seiten soll man entweder zurück zur Messanzeige kommen oder zur Home Seite.
Wichtig hierbei ist, dass die Messanzeige nicht nur ausgeführt wird wenn dieses SubVI geöffnet ist sondern auch im Hintergrund weiter läuft.
Ich habe bislang schon etwas herum experimentiert und mir ein Testprogramm erstellt nur um diesen mehrseitigen Aufbau zu testen.
Ansatz 1: Alle VI‘s laufen in meinem Main VI. Dort gibt es eine sich selbst, per Enum, aufrufende Case Struktur. Jedes untergeordnete VI hat eine Enum Ausgang und dieser geht wieder in die Case Struktur. Sobald sich der Enum ändert wird das damit verbundene SubVI sichtbar in den Vordergrund aufgerufen. Beispielsweise wird in Home der Button Quelle 1 gedrückt ändert sich der Enum Ausgang auf Quelle 1 und im nächsten Case Durchlauf wird Quelle 1 angezeigt.
Jeder Taster hat einen eignen Case, wenn er true wird, wird seine entsprechende Enum Konstante an den Ausgang geschickt.
Bei mehreren Tastern hat es bei mir auch noch funktioniert mit Case Strukturen allerdings ob dies bei 10 verschiedenen Tastern noch sinnvoll und zuverlässig ist, ist für mich fraglich.
Ansatz 2: Ähnlich zu Ansatz 1 aber das Umschalten des Enums passiert mit einer Ereignisstruktur. Das funktioniert gut und zuverlässig aber der restliche Programmablauf hat leider nicht mehr so geklappt. Jedes VI für sich hat sich noch ausführen lassen und auch gearbeitet aber die Kommunikation/Datenweitergabe zwischen den Panels hat leider nicht mehr geklappt.
Was ist eure Empfehlung um an ein solches Projekt heran zu gehen. Wie kann grundsätzlich eine solche Struktur wie auf meiner Grafik konstruiert werden
Hallo blackberry,
ich finde den 2. Ansatz die bessere Lösung.
Ereignis - Struktur in Verbindung mit Queue Verarbeitung sollte die Lösung sein.
LabView bietet unter Projekt erstellen "Handler für Nachrichten-Queues" das passende Grundgerippe dafür.
Stell dir folgendes, Programmiersprachen unabhängiges Konstrukt vor: Du hat auf der einen Seite Programmteile (also VIs), die eine Sache bearbeiten - also Messen und Steuern. Diese Programmteile laufen unabhängig von irgendwas anderem. Diese Programmteile brauchen nicht zwangläufig eine Bedieneinheit (spricht brauchen kein Frontpanel). Auf der anderen Seite gibt es Programmteile (also wieder VIs), die nur eine Anzeige machen und Bedienereingaben entgegen nehmen. Diese Programmteile führen also keinen richtigen Ablauf im Sinne von Messen und Steuern aus - haben aber ein Frontpanel, das der Bediener sieht und bedient.
Du kannst jetzt quasi beliebig viele Programmteile im Hintergrund laufen lassen. Alle Programmteile kommunizieren über Queues und Melder. Queues verwende ich immer zum Steuern der einzelnen Programmteile. Melder verwende ich zum Anzeigen der Daten, die die Programmteile ermittelt haben. Programmteile können auch per FGV miteinander kommunizieren.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Ich bin am Dienstag wieder an dem Programm und werde mir dieses Grundgerippe einmal ansehen.
Ich denke, dass es mit Meldern und Queues am besten funktioniert.
Ich werde mein Konzept so umstellen, dass ich dann die Bedienoberflächen komplett von den anderen Panels trenne. Damit wäre ein weiterer Vorteil, dass ich Mehrfachprogrammierung vermeide.
