Signal LED als globale Variable

Was spricht eigentlich gegen Sequenzen? Ja sicher, man kann den Ablauf sehr viel eleganter steuern indem man den über das Datenflussprinzip sicherstellt. Und ja man sieht bei der gestapelten Sequenz nicht alles. Andererseits ist es denke ich gerade für Anfänger hilfreich erstmal mit Sequenzen zu arbeiten bis sie das Konzept auch verstanden haben. Und natürlich gibt man seinem Code so auch noch eine gewisse Gliederung.

Tatsächlich wäre ich selbst sogar fast ein Fan von gestapelten Sequenzen, wenn die übergabe von Werten von einem Rahmen zum nächsten nicht so umständlich wäre. Ich meine mal ernsthaft: Ob ich meine Funktionalität eines Teils des Programs in einem Rahmen einer gestapelten Sequenz oder einem SubVI kapsele ist doch relativ egal, am Ende ist mir der Code ähnlich "umständlich" zugänglich und ich sehe ihn nicht direkt....

Hallo Kiesch,

Zitat:Ob ich meine Funktionalität eines Teils des Programs in einem Rahmen einer gestapelten Sequenz oder einem SubVI kapsele ist doch relativ egal, am Ende ist mir der Code ähnlich "umständlich" zugänglich und ich sehe ihn nicht direkt...

Ein subVI hat/ist:
- ein aussagekräftiges Icon
- eine aussagekräftige Dokumentation, die in der Kontexthilfe angezeigt wird
- durch ihre Benennung aussagekräftige Ein- und Ausgänge
- wiederverwendbar, bei richtiger Programmierung sogar parallel
- eigenständig testbar

Eine (gestapelte) Sequenz dagegen hat nichts dieser genannten Punkte und verhindert nebenbei auch die parallele Nutzung von Resourcen...

Es kostet mich zwei Klicks aus einem Rahmen einer Sequenz ein SubVI zu machen... Und nicht alle Dinge die ich in einen solchen Rahmen packe sind komplex genug das sich ein SubVI wirklich lohnt. Noch dazu kann es sogar beliebig umständlich werden. Man nehme allein Initialisierungsroutinen.
Da wir hier in der Regel nicht mit compilierten VIs arbeiten, muss ich programmatisch sicherstellen, dass das Program in einem konsistenten Displayzustand startet (ergo: Bestimmte Dinge explizit per lokaler Variable auf einen Startwert setzen). Mir ist bis heute keine andere Variante als die Sequenz bekannt, die ähnlich leicht garantiert, dass das zuerst passiert (leider haben die Lokalen Variablen ja keinen Fehlerausgang oder ähnliches den man nutzen könnte. (ach ja, natürlich kann mans über Referenzen und da wert setzen machen, dann kann mans über den Fehler steuern, aber na ja.... ist auch nicht grade handlich).

Noch dazu sind die Sachen in der Regel so spezifisch, dass man dafür schlecht eine Subroutine schreiben kann die Wiederverwendbar ist (zumindest muss man dafür die Methode so auslegen, dass sie potentiell vielseitig genutzt werden kann - zum Beispiel nen Array von Refs auf Controls vorgeben und startwerte für die als Array übergeben, potentiell als Array von Variants etc. pp; beliebig kompliziert).

Will damit sagen: Die Sequenzstruktur führt tatsächlich teilweise schneller und besser zu einem guten Ergebnis UND liefert im Program eine klare (kommentierbare [sic!]) Gliederung des Programs. Ich meine, machen wir uns nichts vor: Wer SubVIs mit Hilfetexten und Aussagekräftigen Bezeichnungen der ein / Ausgänge versieht UND mit nem ICON (ich bin kein Grafiker, deswegen tu ich das selten, auch wenn es sicher hilfreich wäre... Nur Aussagekräftige Icos zu machen finde ich persönlich garnicht so einfach und besonders bei sehr vielen VIs schwierig (sollten sich ja alle hinreichend gut unterscheiden)), der schreibt auch entsprechende aussagekräftige Kommentare in seine Sequenzen.
Ich meine, mal ernsthaft: Sequenzen mögen für manche Sachen nicht die beste Lösung sein und den Datenfluss zu nutzen ist nunmal deutlich eleganter (ergo: Geschmackssache !) und wenn man das tut ist meist die Sequenz die man vielleicht noch drüberpackt völlig unnötige, ABER: Muss man deswegen mit missionarischem Eifer das benutzen von Sequenzen jedes mal als Fehler beim Programmieren anprangern?

(25.07.2012 09:30 )Kiesch schrieb:  Will damit sagen: Die Sequenzstruktur führt tatsächlich teilweise schneller und besser zu einem guten Ergebnis UND liefert im Program eine klare (kommentierbare [sic!]) Gliederung des Programs. Ich meine, machen wir uns nichts vor: Wer SubVIs mit Hilfetexten und Aussagekräftigen Bezeichnungen der ein / Ausgänge versieht UND mit nem ICON (ich bin kein Grafiker, deswegen tu ich das selten, auch wenn es sicher hilfreich wäre... Nur Aussagekräftige Icos zu machen finde ich persönlich garnicht so einfach und besonders bei sehr vielen VIs schwierig (sollten sich ja alle hinreichend gut unterscheiden)), der schreibt auch entsprechende aussagekräftige Kommentare in seine Sequenzen.
Ich meine, mal ernsthaft: Sequenzen mögen für manche Sachen nicht die beste Lösung sein und den Datenfluss zu nutzen ist nunmal deutlich eleganter (ergo: Geschmackssache !) und wenn man das tut ist meist die Sequenz die man vielleicht noch drüberpackt völlig unnötige, ABER: Muss man deswegen mit missionarischem Eifer das benutzen von Sequenzen jedes mal als Fehler beim Programmieren anprangern?

Das Problem an Sequenzen ist, dass sie meiner Meinung nach schlechten Programmierstiel fördern. Eine Statemachine löst die von dir beschriebenen Probleme mit etwas mehr Aufwand gleichwertig jedoch wird die Wartbarkeit dadurch wesentlich erhöht. Hast du schon mal die Unterschiede zwischen einer historisch gewachsenen Statemachine und einer historisch gewachsenen Sequenz gesehen? Da liegen Welten in der Lesbarkeit/Wartbarkeit dazwischen. Zudem ist die Datenübergabe in einer Sequenz absolut nicht Datenfluss freundlich geschweige leicht zu lesen bei grösseren Mengen.

Zudem haben die SubVI's den Vorteil einer klar definierten Schnittstellte (Eingänge&Ausgänge am besten noch mit Typdef bei Enums oder Clusters) wordurch bei Anpassung ebenjener alle betroffenen VI's geändert werden.

Aber das ist natürlich nur meine Meinung aufgrund meiner Erfahrungen.

Gruss Marc

Danke Marc,

für die weiteren guten Argumente

@Kiesch:

Zitat:Was spricht eigentlich gegen Sequenzen? Ja sicher, man kann den Ablauf sehr viel eleganter steuern indem man den über das Datenflussprinzip sicherstellt.

Du gibst doch selbst die besten Argumente...

Zitat:Da wir hier in der Regel nicht mit compilierten VIs arbeiten, muss ich programmatisch sicherstellen, dass das Program in einem konsistenten Displayzustand startet (ergo: Bestimmte Dinge explizit per lokaler Variable auf einen Startwert setzen).

Sowas löse ich i.A. durch Nachladen einer Config-Datei und setzen von Ctrl-Werten über ihre Referenzen - mit 3 subVIs (Datei laden, Referenzen zusammensuchen, Werte anhand von Name und Referenz setzen). Egal ob in der Entwicklungsumgebung oder im Executable...
Edit: Wozu gibt es die Möglichkeit, Standardwerte für Bedien- und Anzeigelemente zu setzen? Ich sehe hier keinen Grund für lokale Variablen...

Zitat:Noch dazu sind die Sachen in der Regel so spezifisch, dass man dafür schlecht eine Subroutine schreiben kann die Wiederverwendbar ist

Ich versorge nach diesem Schema diverse Prüfstände mit jeweils eigenen Bedienoberflächen. Es hilft unglaublich, wenn man ein striktes Namensschema für Bedienelemente einhält

Zitat:ich bin kein Grafiker, deswegen tu ich das selten

Ich bin auch keiner, bei mir bekommen Icons meist 3-4 Zeilen Text und eine farbliche Kodierung der Titelzeile...

Zitat:ABER: Muss man deswegen mit missionarischem Eifer das benutzen von Sequenzen jedes mal als Fehler beim Programmieren anprangern?

Wenn es mit dem übermäßigen Gebrauch lokaler Variablen einhergeht: Ja! (Meine Meinung...)

(25.07.2012 11:54 )GerdW schrieb:  Danke Marc,

für die weiteren guten Argumente

@Kiesch:

Zitat:Was spricht eigentlich gegen Sequenzen? Ja sicher, man kann den Ablauf sehr viel eleganter steuern indem man den über das Datenflussprinzip sicherstellt.

Du gibst doch selbst die besten Argumente...

Ich hab doch gesagt - ist ein Vorteil, wenn du mich aber vollständig zitiert hättest steht da nunmal auch das das letztlich geschmackssache ist und keine Auswirkungen auf die Funktionalität hat ;-)
Einigen wir uns einfach darauf das wir uns einig sind.

Zitat:

Zitat:Da wir hier in der Regel nicht mit compilierten VIs arbeiten, muss ich programmatisch sicherstellen, dass das Program in einem konsistenten Displayzustand startet (ergo: Bestimmte Dinge explizit per lokaler Variable auf einen Startwert setzen).

Sowas löse ich i.A. durch Nachladen einer Config-Datei und setzen von Ctrl-Werten über ihre Referenzen - mit 3 subVIs (Datei laden, Referenzen zusammensuchen, Werte anhand von Name und Referenz setzen). Egal ob in der Entwicklungsumgebung oder im Executable...
Edit: Wozu gibt es die Möglichkeit, Standardwerte für Bedien- und Anzeigelemente zu setzen? Ich sehe hier keinen Grund für lokale Variablen...

Was wie oben ausgeführt eben mehr Planungsaufwand bedeutet und zu einer deutlich veränderten Methodik führt als es über ne Sequenz zu regeln.
Im übrigen denke ich muss ich mir da tatsächlich auch endlich mal ne wiederverwendbare Routine für Programmieren. Das liegt allerdings im wesentlichen daran, dass ich genug programmiere, so dass sich der Aufwand dafür lohnt.

Zitat:

Zitat:ich bin kein Grafiker, deswegen tu ich das selten

Ich bin auch keiner, bei mir bekommen Icons meist 3-4 Zeilen Text und eine farbliche Kodierung der Titelzeile...

Gibts da eigentlich irgendwelche Hilfsmittel für? Mal ab von Labview? Ich finde den eingebauten Icon editor eher schlecht als recht und die Lesbarkeit von Text ist zu oft auch eher schlecht als recht (so dass ichs wie gesagt praktisch selten nutze; und ja, mir ist bewusst das das ziemlich schlampig ist eigentlich; aber meist reicht mir fürs nachvollziehen was wo passiert die Kontexthilfe völlig aus. Macht mir auch nicht so besonders deutlich mehr Aufwand.

Zitat:

Zitat:ABER: Muss man deswegen mit missionarischem Eifer das benutzen von Sequenzen jedes mal als Fehler beim Programmieren anprangern?

Wenn es mit dem übermäßigen Gebrauch lokaler Variablen einhergeht: Ja! (Meine Meinung...)

Nun ja, das ist auch wieder ne ganz andere Baustelle. Für gestapelte Sequenzen dürfte das tatsächlich nen Problem sein. Wie schon vorher gesagt hat NI da noch keine wirklich zufriedenstellende Variante der Datenübergabe zwischen Rahmen.
Aber bei ner flachen Sequenz ist das nen völlig separates Problem. Ich mein, wer exzessiv Lokale Variablen nutzt, nutzt die auch ohne Sequenz. Mit Sequenz vermeidet er immerhin im besten Fall erstmal die Racing Conditions...


Bottom Line: Ich finde Sequenzen sollten nicht so verteufelt werden, da sie gerade für Anfänger und Leute die eben nicht hauptberuflich mit Labview Programmieren teils einfachere (weil schneller zu programmierende) Lösungen für ihre Probleme bieten. So lange man noch damit kämpft was funktionierendes zu programmieren sind Eleganz und Wartbarkeit und Wiederverwendbarkeit nunmal sekundäre Probleme...

P.S: Ich selbst vermeide auch in der Regel Sequenzstrukturen. Allerdings programmiere ich halt mittlerweile auch schon lange genug um zu wissen was ich tue (und was Labview tut)

p.P.S: Sorry fürs auseinanderklauben deines Posts, ich wollte nur das jeweils der Bezug klar wird.

Hallo Kiesch,

Zitat:die Lesbarkeit von Text ist zu oft auch eher schlecht als recht

Doppelklick auf das "T"-Symbol öffnet den Font-Einstelldialog. Ich nehme meist nur Großbuchstaben...

Ich bin auch ein Verfechter von dem Prinzip:
- Gestapelte Sequenzen mit mehr als einem Frame sind strikt zu unterlassen
- Verwendung von Locals für etwas anderes als intialisieren von den Controls und eventuel gekoppelte Updates, aber nur im Fall eines Events, ist schlampig
- Verwendung von Globals ist beinahe immer ein Zeichen von fehlender Softwarearchitektur

Natürlich darfst Du diese Regeln alle missachten, ich bin ja nicht Dein Chef .

Aber für etwas anderes als eine Schnellschussapplikation, erkaufst Du Dir damit einen wesentlich grösseren Aufwand bei späteren Anpassungen, Erweiterungen und Unterhalt der Applikation. Zudem ist Debugging von solchen Applikationen sehr schnell ein Alptraum.

Auch die Wiederverwendbarkeit von Code ist damit praktisch nicht gegeben und nein das Selektieren von einer Sequenz mit anschliessendem Create SubVI ist keine Lösung, denn erstens ist das kein wirkliches VI sondern allenfalls ein Wrack und zweitens handelst Du Dir noch immer das Problem ein dass Du eine Verbesserung an einem Algortithmus in diesem VI nicht einfach so in die ursprüngliche Applikation übernehmen kannst.

@GerdW

Oh. Das ist praktisch. Danke für den Tipp.

@rolfk

Äh. Gestapelte Sequenzen machen doch überhaupt nur Sinn mit mehr als einem Rahmen xD Oder entgeht mir da was? (ohne mehrere Rahmen kann man doch auch gleich die normale Sequenz nehmen)

(26.07.2012 20:15 )Kiesch schrieb:  Äh. Gestapelte Sequenzen machen doch überhaupt nur Sinn mit mehr als einem Rahmen xD Oder entgeht mir da was? (ohne mehrere Rahmen kann man doch auch gleich die normale Sequenz nehmen)

Historisch gesehen ist eine gestapelte Sequenz die normale Sequenz, da es diese schon viel länger gibt als die flache Sequenzstruktur.

Gruß, Jens