Hallo wertes Forum,
ich versuche ein riesiges VI besser zu strukturieren.
Ich möchte gerne die Anzahl der lokalen Variablen in meinem Main VI reduzieren. Leider habe ich keinen blassen Schimmer wie dabei vorzugehen ist.
- Alles per wire zu verbinden würde sicher ultra unübersichtlich werden.
- Gibt es Möglichkeiten die Werte (sämtliche Formate) die derzeit per lokaler Variable übertragen werden durch Referenzen / FGVs / Eigenschaftsknoten zu ersetzen?
- Womit sollte man Signale unterschiedlichen Datentyps zusammenfassen (z.B. um die Anzahl der eingehenden Wires an einem SubVI zu reduzieren)?
Und einmal an einem konkreten Beispiel:
Im Blockdiagramm kann vom User per "Ring" eine Auswahl getroffen werden, die sowohl im MainVI, als auch in ca. 5 SubVIs und auch noch in einigen SubVIs dieser SubVIs verwedet werden soll.
Wie setze ich dies am Besten sauber um?
Vielen Dank im Voraus,
Philipp
(18.09.2019 17:07 )Philipp841 schrieb: [ -> ]riesiges VI zu strukturieren
Das geht dadurch, dass diverse Teile in SubVIs ausgelagert werden. Diese SubVIs kann man dann per Error-Cluster sequenzieren.
Zitat:Ich möchte gerne die Anzahl der lokalen Variablen in meinem Main VI reduzieren.
Das ist gegebenenfalls nach der Implementation der vielen SubVIs nicht mehr nötig …
Zitat:Alles per wire zu verbinden würde sicher ultra unübersichtlich werden.
Nicht nur das, auch nicht debugbar …
Zitat:Gibt es Möglichkeiten die Werte (sämtliche Formate) die derzeit per lokaler Variable übertragen werden durch Referenzen / FGVs / Eigenschaftsknoten zu ersetzen?
Egal, was du nimmst (Referenzen, Eigenschaftsknoten und auch FGVs), nichts von dem wird bewirken, was du willst - nämlich Übersicht. Alle drei Methoden ersetzen lediglich das optische Bild.
Zitat:Womit sollte man Signale unterschiedlichen Datentyps zusammenfassen (z.B. um die Anzahl der eingehenden Wires an einem SubVI zu reduzieren)?
Cluster. Cluster machen praktisch aus vielen Wire nur einen Wire.
Ansonsten ist es eine gute Lösung, Werte in einer FGV zu halten. Das erspart nämlich Eingänge an SubVIs, weil die FGV direkt im SubVI verwendet wird. Und weil das SubVI dann keine Eingänge und Ausgänge mehr hat (außer Errorcluster zum Sequenzieren), gibt es auch keine Wire. Somit sollte es ziemlich aufgeräumt aussehen.
Erster Grundsatz: Unterprogrammtechnik.
Zweiter Grundsatz: Programmstruktur.
https://www.labviewforum.de/Thread-Robus...#pid193388
Teil 1 vor allem !!!
Der Umbau auf eine State-Machine wird im ersten Schritt wahrscheinlich die lokalen Variablen nicht eliminieren, aber die Übersicht verbessern. Und mit mehr Übersicht fällt dann die Eliminierung unnötiger Variablen deutlich leichter.
Gruß, Jens
Hallo und danke für Eure Antworten.
(18.09.2019 17:32 )IchSelbst schrieb: [ -> ]Das geht dadurch, dass diverse Teile in SubVIs ausgelagert werden. Diese SubVIs kann man dann per Error-Cluster sequenzieren.
Dies würde ich sehr gerne umsetzen. Leider stoße ich dabei jedoch auf das Problem, dass sich innerhalb des Programmteils, welchen ich zu einem SubVI zusammenfassen möchte, teilweise mehrer Lokale Variablen befinden.
Wie gehe ich damit um?
Zitat: Der Umbau auf eine State-Machine wird im ersten Schritt wahrscheinlich die lokalen Variablen nicht eliminieren, aber die Übersicht verbessern.
Ich würde das VI sehr gerne in die Struktur einer State-Machine bringen. Ich habe auch eine Idee davon, wie eine State-Machine aufzubauen ist. Jedoch habe ich keinen Ansatz, wie ich das bestehende VI dahingehend umbauen könnte (step by step). Es wäre doch viel mehr ein "komplett neu schreiben" oder nicht?
Ich würde deinen Rat wirklich sehr gerne umsetzen; jedoch, wie ja auch schon mehrfach geschrieben, bräuchte ich dafür einfach wesentlich detailliertere Anweisungen.
Vielen Dank Euch und besten Gruß,
Philipp
Halo Philipp841
Kannst du das VI, das du umstrukturieren willst, posten? An einem Beispiel lässt sich viel leichter beschreiben, was du der Reihe nach machen könntest.
Hallo IchSelbst,
sehr gerne.
Da das Programm bereits aus einer Main und ca. zwei dutzend SubVIs besteht werde ich eine .zip posten.
Ein paar Anmerkungen zum VI:
Es werden zwei Stepmotoren angesteuert. Einmal für das Aufbringen einer Normalkraft (Vertikal) und einmal zum Abscheren einer Probe (Horizontal). Während des Verfahrens werden kontinuierlich 6 analoge Signale aufgezeichnet:
1 Verschiebung an der Probe (Displacement Horizontal) = Scherweg
2 Verschiebung nahe am Motor (Displacement Base Horizontal) = Scherweg + Deformation der Maschine
3 Setzung der Probe (Displacement Vertical) = Konsolidierung
4 Scherkraft
5 Normalkraft
6 Stromversorgung für die Wegaufnehmer
Mein Wunsch ist, das VI in Richtung NI-Guidelines zu modifizieren. Sprich, mit noch viel mehr mit SubVIs zu arbeiten, lokale Variablen zu eliminieren und die Übersichtlichkeit/Nachvollziehbarkeit erheblich zu verbessern.
Und noch eine Anmerkung:
Betreibt man das VI mit einem simulierten Gerät, dessen Signale sich mit ca. 1Hz ändern, nehmen anscheinend die Anzeigeinstrumente soviel CPU-Power in Anspruch, dass es zum einem DAQ-Error aufgrund Buffer-Overflow kommt. (Ich glaube es wird dann nicht mehr häufig genug gelesen). Mit stabilen Signalen an den Eingängen eines echten DAQ-Gerätes läuft das jedoch. Lässt sich vermutlich auch noch besser umsetzen (?).
By the way: Ist es bei einem simulierten Gerät möglich die Frequenz der simulierten Signale zu verändern?
Nochmals danke und schönes W.e.,
Philipp
Hallo Philipp,
- gestapelte Sequenzen in flache umwandeln, dann lokale Variablen darin durch Drähte ersetzen und Frames zusammenfassen (oder gar den ganzen Sequenzrahmen löschen)
- wenn nahezu (?) alle Terminals in dieser einen Sequenz ungenutzt rumliegen, ist etwas vollkommen falsch: jedes genutzte Terminal ersetzt (mindestens) eine lokale Variable!
- wenn innerhalb deiner Schleifen irgendwelche lokalen Variablen mehrfach genutzt werden: durch Draht ersetzen (Beispiel "Area Selection")
- aussagekräftige Icons! Wieso haben "H2Displacement new" und "H2Displacement base" das gleiche (generische) Icon?
- wenn innerhalb einer Schleife auf eine lokale Variable schreibend und lesend zugegriffen wird, dann sollte man ein Schieberegister nutzen! (Beispiel "Horizontal Offset")
- IndexArray kann man vergrößern, um mehrere Indizes abzufragen. Und man braucht keine (oder nur eine) Index-Konstante, wenn man fortlaufende Indizes abfragt!
Beispiel:
[
attachment=60388]
Ist nur ein Anfang: der Einsatz eines Schieberegisters ersetzt zwei lokale Variablen…
(Da gehört aber auch noch deutlich besseres Datenhandling dazu!)
Zitat:Betreibt man das VI mit einem simulierten Gerät, dessen Signale sich mit ca. 1Hz ändern, nehmen anscheinend die Anzeigeinstrumente soviel CPU-Power in Anspruch, dass es zum einem DAQ-Error aufgrund Buffer-Overflow kommt. (Ich glaube es wird dann nicht mehr häufig genug gelesen). Mit stabilen Signalen an den Eingängen eines echten DAQ-Gerätes läuft das jedoch.
Die Frequenz des Signals hat einen Einfluss auf die Anzeigeelemente???
Eher sind die übereinanderliegenden Anzeigeelemente ein Problem: LabVIEW mag sich überlappende FP-Elemente nicht so sehr.
Zitat:Ist es bei einem simulierten Gerät möglich die Frequenz der simulierten Signale zu verändern?
Nein.
Nachtrag:
Zitat:nehmen anscheinend die Anzeigeinstrumente soviel CPU-Power in Anspruch
Dein Programm läuft auch langsamer als erwartet, wenn man immer wieder Berechnungen wiederholt:
[
attachment=60389]
Wieso musst du jedesmal erneut wieder das Stringarray in ein Zahlenarray umwandeln? Und warum mussten das vorher dafür zwei FOR-Loops sein?
Und dieser RunningAverage (vorher per ExpressVI) ist auch ziemlich langsam bei 1000 Samples Breite…
Das gehört alles zum Thema "Effizientes Datenhandling": wenn du Kalibrierkurven etc einliest, dann kannst du sie einmal einlesen und gleich in das benötigte Format umwandeln - anstatt diese Wandlung immer wieder erneut vorzunehmen!
Allgemeiner Hinweis:
Ich würde dieses Programm von Grund auf neu schreiben.
Dazu als allererstes mal aufschreiben, was das Programm machen soll. ("WAS" und nicht "WIE"!)
Dann eine Programmstruktur überlegen und (auf Papier) skizzieren (Stichwort PAP Programm-Ablauf-Plan)
Dann die gewünschte Struktur umsetzen…
Hallo Gerd,
danke Dir erneut für deine Antwort. Sehr wahrscheinlich macht es Sinn die Anwendung neu aufzusetzen. Da ich mir das im Moment jedoch noch nicht zutraue, werde ich anhand der Optimierung des bestehenden VI´s zunächst erstmal weiter üben. Vielleicht werde ich das Projekt "Neu machen" in Angriff nehmen, wenn ich mich noch fitter mit LV fühle.
Mittlerweile habe ich bereits einige deiner konkreten Vorschläge umgesetzt. Ich melde mich sicher nochmal, wenn ich damit noch weiter fortgeschritten bin.
Gruß,
Philipp