Variable ohne Element -einfach unsichtbar machen?

Durch die FGVs habe ich begriffen, wie gut sich Schieberegister als "lokale Variablen" eignen, wenn sie in einer While-Schleife verbaut sind, die genau 1 Mal durchläuft (was ja eigentlich wenig Sinn macht). Ihr habt mir hier etwas richtig wichtiges beigebracht. Ein ganz dickes Danke nochmal dafür!


Zwei Fragen hätte ich dazu an euch noch bitte.


Die erste Frage habe ich versucht in einem Bild zu verdeutlichen. Hab dazu ein kleines VI zu modelliert:

   

Das Haupt-VI soll einen Summanden einer Gesamtsumme aufaddieren. Diese Gesamtsumme wird in einem SR in einem SubVI gespeichert und der Summand auch dort aufaddiert. Nun bieten sich 2 Möglichkeiten, beide funktionieren. Der Übergabewert, also der Summand, kann sich innerhalb der Schleife befinden oder außerhalb und über einen Tunnel in die Schleife hineingegeben werden. Mach das irgendeinen Unterschied? In meinem eigentlichen Projekt geht es da um einige Übergabewerte, die entweder innerhalb der Schleifen oder außerhalb sein können. Wird durch den Tunnel eine weitere Kopie der Variable angelegt? Vor allem was die Performance angeht, wollte ich euch nach den Unterschieden fragen, aber auch allgemein.


Meine zweite Frage wäre:

Wenn ich das VI erneut starte, sind immernoch die Werte, in diesem Fall die Gesamtsumme, vom letzten Start im Schieberegister des SubVIs gespeichert. Ich möchte aber jedes Mal wieder bei 0 beginnen und in manchen Fällen wäre auch ein spezieller Startwert nötig. Gibt es eine elegante Möglichkeit, Schieberegister oder SubVIs zu initialisieren? Oder muss man sich hier irgendwie mit einer Abfrage verkünsteln, ob die SubVI zum ersten Mal aufgerufen wird? Wie geht ihr hier vor? Das müsste ja eine eher alltägliche Angelegenheit sein. Anzeige-/Bedienelemente lassen sich ja ganz simpel initialisieren: lokale Variable im Schreibmodus zu Beginn des Programms mit einer Konstante versehen -fertig. Wenn ich aber links der Schleife links an das Schieberegister eine Konstante hänge, wird ja bei jedem Aufruf auf den Initialisierungswert zurückgesetzt.... Nur ungerne würde ich das Schieberegister aus dem SubVI herausnehmen und in die äußere Schleife der des Haupt-VIs versetzen...

Anzeige

(18.08.2018 23:20 )catbull schrieb:  Mach das irgendeinen Unterschied?

Die Vorschrift besagt: außerhalb.

Zitat:Wird durch den Tunnel eine weitere Kopie der Variable angelegt?

Guckst du Werkzeuge->Profil->Pufferzuweisung

Zitat:Vor allem was die Performance angeht, wollte ich euch nach den Unterschieden fragen, aber auch allgemein.

Der Verlust an Performance, der durch einen Tunnel auf der While-Schleife entsteht, ist zu 100% vernachlässigbar gegenüber der Performance, die benötigt wird, auch nur den kleinsten Buchstaben am Bildschirm darzustellen. Meine Performance-Überlegungen fangen immer erst dann an, wenn DBL-Arrays größer als 20MB werden.

Zitat:Gibt es eine elegante Möglichkeit, Schieberegister oder SubVIs zu initialisieren? Oder muss man sich hier irgendwie mit einer Abfrage verkünsteln, ob die SubVI zum ersten Mal aufgerufen wird?

Ich mach das immer mit "Erster Aufruf" (Palette Synchronisation, Element Erster Aufruf). Und das ist kein verkünsteln, sondern normales Initialisieren. Mach in die While-Schleife eine Case-Sequenz rein. Entweder True/False oder mit Enumarator. Bei True/False schließt du den "Erster Aufruf" an (Ersatz hierfür: Rückkopplungsknoten in der Palette Strukturen). Bei Enumerator gibst du von außerhalb an, was gemacht werden soll: Methode "Initialisieren".

(19.08.2018 09:24 )IchSelbst schrieb:  Die Vorschrift besagt: außerhalb.

Okay. Danke. Gilt das für alle Werte die in so ein SubVI hineingegeben werde? -Also nur für Anschlüsse oder auch für andere Art und Weisen Parameter zu übergeben wie FGVs, globale Variablen usw...? Sollten alle außerhalb der Schleife liegen und über einen Tunnel übergeben werden?

(Ich versuche globale Variablen zu vermeiden, ich weiß... )

(19.08.2018 09:24 )IchSelbst schrieb:  Ich mach das immer mit "Erster Aufruf" (Palette Synchronisation, Element Erster Aufruf). Und das ist kein verkünsteln, sondern normales Initialisieren. Mach in die While-Schleife eine Case-Sequenz rein.

Genau auf sowas habe ich gehofft! Danke! (Mit "verkünsteln" hatte ich ganz andere Verschränkungen im Sinn )

Vielleicht werde ich jetzt etwas kleinlich aber wenn wir schon beim Thema sind: Gibts Gründe dafür hier eher einen Case zu verwenden oder tuts dieses if-Dreieck genauso? Also so:

   


Am Rande: Ich habe es nun geschafft alle Werte die vorher in Unsichtbar-Zu-Machenden-Anzeigeelementen gespeichert waren in den von euch erklärten Alternativen unterzubringen -ohne Kabelsalat oder sonstiges Chaos! Danke nochmal!

(19.08.2018 12:40 )catbull schrieb:  Gilt das für alle Werte die in so ein SubVI hineingegeben werde?

Nein, das gilt nur für Anschlüsse.

Zitat:oder auch für andere Art und Weisen Parameter zu übergeben wie FGVs, globale Variablen usw...?

FGV's etc. werden nicht übergeben, sie sind einfach da. Alleine deswegen, weil sie im BD platziert sind. Werte aus den FGVs werden nicht gebracht, sondern geholt ...

Zitat:Sollten alle außerhalb der Schleife liegen und über einen Tunnel übergeben werden?

Das kommt darauf an ...
Eine FGV kann auch mehrmals innerhalb eines VIs aufgerufen werden - da es ja schließlich eine Klasse mit Methoden ist. In diesem Falle muss die FGV selbstverständlich irgendwo in einem Datenfluss platziert sein.

Zitat:Gibts Gründe dafür hier eher einen Case zu verwenden oder tuts dieses if-Dreieck genauso?

Erstens: Warum soll ich dir alles sagen, du kannst doch lesen, oder? Wichtiger ist, dass du offensichtlich meine Texte analysieren kannst und gegebenenfalls selbständig was ähnliches suchen kannst und auch findest: Ziel erreicht.
Zweitens: Ein True/False-Case lässt sich gegebenenfalls leichter in einen Enumerator-Case wandeln als dieses IF-Dreieck ...

Hallo catbull,

nachdem du ja über das Wochenende schon einiges zu Thema "THINK DATAFLOW!" gelernt hast (Link in meiner Signatur!), noch ein paar Hinweise/Gedanken:

Zitat:Gibts Gründe dafür hier eher einen Case zu verwenden oder tuts dieses if-Dreieck genauso?

- FGVs, die einfach nur Werte speichern/lesen lassen (wie in deinem Bild), bringen keinen echten Mehrwert ggü. einer einfachen globalen Variablen! Du handlest dir nur zusätzlichen Overhead ein! RaceConditions (Link in meiner Signatur!) kannst du mit einer solchen einfachen FGV auch nicht vermeiden: du weißt weiterhin nicht, wer zuerst lesen oder schreiben darf…
- Erst, wenn man weitere Methoden implementiert (z.B. Daten speichern oder aus Datei lesen), wird es wirklich sinnvoll! Und ein ErrorIO ist dann auch Pflicht…

Zitat:Ich versuche globale Variablen zu vermeiden,

Gegen globale Variablen ist nichts einzuwenden, wenn man sie bewußt verwendet.
Warum sollte es verkehrt sein, zu Programmstart in einer globalen Variablen die aktuelle Programmversion (und ähnliche Informationen) zu speichern, wenn man hinterher nur noch lesend darauf zugreift? (Stichwort "WORM"= "write once read multiple", zu finden im NI-Forum).
Es gilt wie sonst auch: der Programmierer sollte wissen (und dokumentieren), was er da macht…

Zum Thema "Variablen":
Dieser Begriff wird in LabVIEW anders verwendet als in textbasierten Sprachen.
- Dort benutzt du ihn, um Daten von einem Codeteil zum nächsten zu bringen: in LabVIEW benutzt man dafür den Draht!
- Dort benutzt du ihn, um Daten zu (in einem Memorybuffer) speichern: auch hier benutzt LabVIEW den Draht - oder ein Schieberegister/Feedbacknode!

Hier mal ein Beispiel für ein Snake-Spiel:
   
- Es gibt genau 4 FP-Elemente, die alle für den User sichtbar sind: String (Hinweistext), Spielfeld, Punktestand, Lebens-Anzeige der Schlange.
- Alle Daten befinden sich in Drähten und im Schieberegister.
- Es werden keine "Variablen" benötigt!
- Tetris sind fast identisch aus (dort habe ich nur einen QMH eingebaut)…

(19.08.2018 12:40 )catbull schrieb:  

(19.08.2018 09:24 )IchSelbst schrieb:  Die Vorschrift besagt: außerhalb.

Okay. Danke. Gilt das für alle Werte die in so ein SubVI hineingegeben werde? -Also nur für Anschlüsse oder auch für andere Art und Weisen Parameter zu übergeben wie FGVs, globale Variablen usw...? Sollten alle außerhalb der Schleife liegen und über einen Tunnel übergeben werden?

Ich weiß zwar nichts von einer solchen Vorschrift, aber es kann sich dabei nur um eine Empfehlung in einem Style-Guide handeln. Es ist eben übersichtlicher, alle Ein-und Ausgansvariablen im BD übersichtlich ganz links und ganz rechts in einer Reihe angeordnet zu haben, als wenn sie teilweise unsichtbar in irgendwelchen verschachtelten Strukturen sitzen. Die paar Nanosekunden, die das Programm schneller ist und die Paar Byte die es als EXE kürzer ist, sind demgegenüber keine Argumente. Es könnte sogar sein, daß Labview bei der Kompilierung merkt, wenn solche zusätzlichen Knoten überflüssig sind. Dann gäbe es überhaupt keinen Unterschied.

Noch eine Amerkung zum Unsichtbar machen von Elementen: Mir gefällt es nicht, wenn sie als unsichbare Elemente irgendwo mitten im FP platziert sind. Man muß sie eigentlich gar nicht unsichtbar machen, es genügt doch, wenn sie sich außerhalb des Frontplatten-Rahmens befinden. Dann sind sie auch unsichtbar. aber jederzeit zugänglich.

Noch etwas: es wurde hier die Benamung von Drähten ins Spiel gebracht. Bei Schaltplänen von Leiterplatten-Programm gibts das auch. Man muß dort die Leitungen gar nicht mehr durchziehen. Wenn irgendwelche Drahtstücke auf einer Schaltbildseite den gleichen Namen haben, dann sind sie miteinander verbunden. In Labview gibts das nicht, man kann damit keinen Draht sparen.

Zitat:(Ich versuche globale Variablen zu vermeiden, ich weiß... )

Mit globalen Variablen kann man Drahtsalat am Drastischsten vermindern. Die Warnungen bezüglich nicht beabsichtigter Ausführungs-Reihenfolge bei globalen und lokalen Variablen sind berechtigt - für Anfänger. Ein Experte weiß das zu handlen, ihm wird da nicht so leicht ewas passieren.
Es ist damit so wie mit unserer Regierung: Mit Kernkraftwerken kann man den CO2-Ausstoß drastisch veringern, und dieses Ziel ohne KKW zu errechen ist die Quadatur das Kreises...

Anzeige

Zitat: Der Übergabewert, also der Summand, kann sich innerhalb der Schleife befinden oder außerhalb und über einen Tunnel in die Schleife hineingegeben werden. Mach das irgendeinen Unterschied?

Ein Sache darfst Du nicht vergessen. Wenn sich der Wert von Summand ändert, wird bei einem Tunnel sich in der While Schleife der Wert nicht mit ändern. Wenn Du aber Summand innerhalb der While Schleife stehen hast und der Wert ändert sich vor dem Verlassen der Schleife kann sich das Ergebnis entsprechend ändern.

Gruß Freddy

(20.08.2018 17:39 )Lucki schrieb:  Bei Schaltplänen von Leiterplatten-Programm gibts das auch. Man muß dort die Leitungen gar nicht mehr durchziehen. Wenn irgendwelche Drahtstücke auf einer Schaltbildseite den gleichen Namen haben, dann sind sie miteinander verbunden.

Gutes Beispiel. Und gleich ein Kommentar von mir.

Die Auswahl zu haben zwischen Draht und Beschriftung stellt ein Dilemma dar: Wie immer ergibt auch hier nur das richtige Verhältnis zwischen beiden Sinn. Ich habe schon beide Extreme erlebt. Offensichtlich schlecht ist ein zu großes Wirrwarr von Drähten. Durch die vielen Überschneidungen bekommt man kleinen Überblick. Aber auch nur Labels ist schlecht - weil: Wenn ich bei zwanzig Labeln die eine Weiterführung suche, muss ich im schlimmsten Falle alle zwanzig Weiterführungen finden(!) und lesen(!). Was ist aber, wenn ich genau diese eine überlesen habe? => Frust ist groß und Zeit, also Geld, verschwendet.

Es ist ein guter Vorteil der graphischen Oberfläche - nämlich alles als Bild zu machen: Nichts kann das Gehirn besser als Bilder zu entschlüsseln. Deswegen ist es richtig, gerade und nicht zu lange Drähte zu haben, die sich (nach Möglichkeit) nicht überschneiden.

Eben so, wie man das im Bild von GerdW's Schlangen-DingsDa sieht ...

Vielen Dank euch allen! Mir kommt es so vor, als würde ich langsam ein Gefühl für LabView bekommen, gerade auch durch das Arbeiten mit euren Posts.

(21.08.2018 12:03 )IchSelbst schrieb:  Offensichtlich schlecht ist ein zu großes Wirrwarr von Drähten. Durch die vielen Überschneidungen bekommt man kleinen Überblick. Aber auch nur Labels ist schlecht - weil: Wenn ich bei zwanzig Labeln die eine Weiterführung suche, muss ich im schlimmsten Falle alle zwanzig Weiterführungen finden(!) und lesen(!).

Würdet ihr sagen, dass das so noch in Ordnung oder schon in Richtung Wirrwarr geht?...

   

...Ich könnte manche von den Schieberegistern auch in die jeweiligen SubVIs verlegen. Mir gefällt es aber, dass alle Werte, die die Physik betreffen, in dieser VI gespeichert sind. Aus ästhetischen Gründen oder wegen sinnvoller Modularisierung oder um, was noch kommen soll, die Werte als Cluster an die Main-VI zu übergeben und in Tachos/Rundinstrumenten anzeigen zu lassen... Letzteres müsste ich sonst mit globalen Variablen realisieren, was dem von GerdW genannten WORM-Prinzip widersprechen würde. Nur eben:

Ich kenne mich in dieser VI auf den ersten Blick aus, aber wie wirkt das auf euch Außenstehende? Kann man das so lassen oder sind das schon zu viele Überschneidungen?

(21.08.2018 11:14 )Freddy schrieb:  Ein Sache darfst Du nicht vergessen. Wenn sich der Wert von Summand ändert, wird bei einem Tunnel sich in der While Schleife der Wert nicht mit ändern. Wenn Du aber Summand innerhalb der While Schleife stehen hast und der Wert ändert sich vor dem Verlassen der Schleife kann sich das Ergebnis entsprechend ändern.

Wenn aber wie hier, die Schleifen nur genau 1 Mal durchlaufen, sollte das kein Thema sein oder verstehe ich dich falsch? Du redest von parallel laufenden Schleifen, oder?

(19.08.2018 17:28 )GerdW schrieb:  - FGVs, die einfach nur Werte speichern/lesen lassen (wie in deinem Bild), [...]

Redet man da schon von FGVs? Ich hätte gedacht, da gehöre noch etwas mehr dazu... (Ist wichtig für mich, damit ich den Begriff richtig verwende, wenn ich mein Projekt präsentiere) Ist es schon ine FGV, wenn ein SubVI nichts anderes macht, als einen Wert in einem SR zu speichern und zu übergeben?

Zitat:Gegen globale Variablen ist nichts einzuwenden, wenn man sie bewußt verwendet.
Warum sollte es verkehrt sein, zu Programmstart in einer globalen Variablen die aktuelle Programmversion (und ähnliche Informationen) zu speichern, wenn man hinterher nur noch lesend darauf zugreift? (Stichwort "WORM"= "write once read multiple", zu finden im NI-Forum).

WORM -werde ich nichtmehr vergessen! Ja, das Gefühl habe ich jetzt auch, dass es für Werte, quasi Konstanten, die einmal zur Laufzeit festelegt werden, genau das richtige ist. -Für Einstellungen usw... Wende ich so an jetzt.

(20.08.2018 17:39 )Lucki schrieb:  Mit globalen Variablen kann man Drahtsalat am Drastischsten vermindern. Die Warnungen bezüglich nicht beabsichtigter Ausführungs-Reihenfolge bei globalen und lokalen Variablen sind berechtigt - für Anfänger. Ein Experte weiß das zu handlen, ihm wird da nicht so leicht ewas passieren.

Ich lasse mich gerne mehr in Richtung Experte als in Richtung Anfänger erziehen bezüglich was geht und was nicht . Wie gesagt, habe angefangen globale Variablen zu verwenden (nach dem von GerdW genannten "WORM"-Prinzip)


.

Hallo catbull,

Zitat:Würdet ihr sagen, dass das so noch in Ordnung oder schon in Richtung Wirrwarr geht?...

Prinzipiell sieht das BD schon sehr geordnet aus!

Was ich machen würde: alle Schieberegister durch ein einziges ersetzen und alle Einzelwerte in einem Cluster zusammenfassen! (Dann bist du schon ganz knapp vor einer echten OOP-Implementierung.)

Zitat:was dem von GerdW genannten WORM-Prinzip widersprechen würde.

Als ich das Prinzip erwähnt habe, hieß das nicht, dass das die alleingültige Nutzweise von globals sein soll. Man kann sie auch anders verwenden: man landet dann wieder bei "Der Programmierer sollte wissen und dokumentieren, was er da macht!"
WORM ist eine Nutzungsart (von vielen), die aber recht sicher RaceConditions vermeiden hilft. Nicht mehr, aber auch nicht weniger.

Zitat:Redet man da schon von FGVs?

Der Begriff ist (IMHO) nicht 100% klar definiert.
Es gibt ja auch noch "LV2-style global" (das wäre die simple Lese/Schreibanwendung aus deinem Bild weiter oben) und AE (ActionEngine)…
(Fun fact zu "LV2-style global": bei LabVIEW2 gab es noch keine globalen Variablen, aber eben schon Schieberegister. Und da nutzte man eben dieses Schieberegister, um Werte speichern zu können und so globale Variablen zu simulieren.)

Zitat:Für Einstellungen usw... Wende ich so an jetzt.

Für Einstellungen, die der User auch beeinflussen kann/soll, nehme ich auch gern FGVs/AEs. Die bekommen dann gleich noch States zum Laden/Speichern in Dateien usw.