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!
Also die Radio-Button eignen sich nur für 1 aus n Entscheidungen. Z. B. Drucke (entweder) in farbe oder in schwarzweiß. Für die Auswahl von "welche Ergebnisse sollen gedruckt werden" sind sie nicht geeignet, da man hier mehrere Elemente auswählen möchte. Dazu ist eine Listbox oder ein Cluster von Schaltern besser geeignet.
Bei der Verwendung zur Programmsteuerung können sie eingesetzt werden, da hier in der Regel nur eine Funktion aus vielen gewählt wird. Die Programmsteuerung sollte generell mit der Ereignis-(Event)-Struktur durchgeführt werden, damit man nicht die ganze Zeit abfragen muss, ob ein bestimmter Schalter (Button) gedrückt wurde oder nicht. Und in der Ereignis-Struktur bieten die Radio-Button-Sammlung eher nur Nachteile: in dem Ereignisfall (Eventcase) für die Button muss noch eine Case-Strukture enthalten sein, in der je nach Wert unterschiedliche Programmteile ausgeführt werden.
Da ist es im Blockdiagram übersichtlicher, wenn mann gleich auf dem Frontpanel Knöpfe anlegt und für jeden Knopf einen eigenen Fall in der Ereignis-Struktur hat.
Anzeige
04.08.2009, 15:15 (Dieser Beitrag wurde zuletzt bearbeitet: 04.08.2009 15:19 von Lucki.)
Zu Deinen Enwänden gegen die Radio-Button Struktur:
Zitat:Also die Radio-Button eignen sich nur für 1 aus n Entscheidungen. Z. B. Drucke (entweder) in farbe oder in schwarzweiß. Für die Auswahl von "welche Ergebnisse sollen gedruckt werden" sind sie nicht geeignet, da man hier mehrere Elemente auswählen möchte. Dazu ist eine Listbox oder ein Cluster von Schaltern besser geeignet.
Das ist zwar richtig, und das Orignalposting von Thomas kann man auch so verstehen, daß er etwas anderes im Auge hatte als die Radio-Button-Struktur. Was aber dann an Antworten kam, waren, grob gesprochen, programmatischen Umsetzungen der Radio-Button Struktur. Und da das mit Lob und Zustimmung von Thomas geschah, war es doch klar daß er das auch suchte.
Zitat:Und in der Ereignis-Struktur bieten die Radio-Button-Sammlung eher nur Nachteile: in dem Ereignisfall (Eventcase) für die Button muss noch eine Case-Strukture enthalten sein, in der je nach Wert unterschiedliche Programmteile ausgeführt werden. Da ist es im Blockdiagram übersichtlicher, wenn mann gleich auf dem Frontpanel Knöpfe anlegt und für jeden Knopf einen eigenen Fall in der Ereignis-Struktur hat.
Das hat überhaupt nichts mit Vor- und Nachteilen zu tun, sondern ist eine reine Programmierer-Geschmacksfragre. Manche möchten alle lokalen und/oder globalen Variablen aus einem Programm verbannt sehen, andere haben eine Allergie gegen Express-VIs, und Du hättest eben bei z.B. 4 Auswahlbuttons lieber vier getrennte Ereigniscases als einen Ereignscase mit 4 Cases Inside. Dabei liegen die Vorteile eher bei der leztgenannten Struktur: Ein Teil des Codes bei der Ereignisbehandlung wird bei allen 4 Köpfen womöglich identisch sein. Und diesen Teil das Codes muß ich dann nicht 4 Mal kopieren, oder alternativ in ein SUB-VI verlegen.
oder die Zustandsmaschine für die kleinen Bedürfnisse
1Postingempfehlungen, 2Motivation Fragen und Anpassungswünsche per PM werden, gegen Rechnungsstellung gerne beantwortet und realisiert ....wenn's dann doch kostenlos sein soll... bitte hier im LVF unter Berücksichtigung der voranstehenden Links posten.
Wenn die Knöpfe eng zusammenhängen und sogar teilweise gleiche Funktionalität haben ist die Case-Struktur inside so wie Lucki sagt, die Lösung der Wahl. Ich dachte bei meinen Ausführungen vielmehr an so etwas wie "Konfigurieren", "Messen" und "Speichern". Da ist ein zusätzlicher Case inside nicht notwendig.
Jedoch möchte ich noch anmerken, dass Programmieren und der Programmierstil sich nicht am Geschmack ausrichten sollte , der sich bekanntlicherweise schnell ändern kann. Es sollte vielmehr nach bestimmten, festen, objektierten Regeln gearbeitet werden, damit programmierter Code auch für andere Personen lesbar und verständlich bleibt. Sicher hat jeder seine Vorlieben, die er auch nutzen soll. Das ist jetzt bei dem hier diskutierten Fall sicherlich kein Problem. Bei der programmtechnischen Umsetzung gibt es oft mehrere Lösungen. Jedoch ist bei Postings oftmals nicht der ganze Kontext bekannt, so dass man nicht eine Lösung als die optimale Lösung anbieten kann. So halte ich es nur für fair auch alternative Lösungen vorzuschlagen.
Hallo,
bevor ihr euch die Köpfe einrennt ;-)
Ich bin es gewohnt Anwendungen in C++ meistens für Linuxartige Betriebssysteme zu schreiben. Bei der Arbeit mit LabVIEW ist mir aufgefallen, dass es (zumindest für mich) extrem einfach ist. Signale von Messgeräten usw. aufzunehmen, auszuwerten usw. Meine Hauptprobleme liegen in der simplen Programmablaufsteuerung. In C würde ich einfach jede Funktion die ich öfters benötige in eine eigene Headerdatei auslagern und bei Bedarf einbinden, wobei genau festgelegt ist welche Übergabe und Ausgabeparameter in welcher Form anzugeben/auszugeben sind. Im Zweifelsfall kann ich sogar die Datentypen variabel halten, so dass es letztendlich egal ist, ob ich als Eingang für den Dateipfad ein String oder einen Pfad schicke. In LabVIEW muss ich konvertieren. Ich denke die Kabelmethode ist einfach genauso wie Schieberegister ein Relikt aus der Elektro-/Schaltungstechnik. Da muss man sich erst mal dran gewöhnen.
Was ich machen wollte ist: Ein Fenster mit Knöpfen, die dann jeweils einzelne Programmteile aufrufen. Also zum Beispiel sowas wie:
Das allein ist mit einem Caseselektor natürlich machbar, aber in meinen Augen viel aufwändiger, als unter C. Ein weiterer Punkt ist die Fehlerbehandlung. C++'ler kennen hier Throw und Catch. Unter LabVIEW habe ich nur Fehlerein- und Ausgänge. Eine Fehlerbehandlung ist eher schwer möglich.
Weiter möchte ich später ein Protokoll erstellen. Zu jedem Versuch - bezogen jetzt auf die Durchführung von Experimenten - wird ein eigenes Verzeichnis angelegt, in dem dann die zugehörigen Daten abgelegt werden. Hier soll der Benutzer - letztendlich ich - eine Liste von Punkten abarbeiten, derren Durchführung dann "abgehakt" und mit Zeitstempel versehen wird. Im "Menüpunkt" Protokoll erstellen könnte ich dann über die Radiobutton Geschichte gezielt auswählen, welche Daten ins Protokoll sollen. Bei einer Standardproduktion würden zum Beispiel eine Kurzübersicht ausreichen, während bei einem "Experiment" viel mehr Parameter erfasst und ausgewertet werden müssen.
Daher waren beide (in Wirklichkeit waren es ja mehr, aber im Grundsatz waren es zwei) Methoden für mich sehr interessant und lehrreich.
Natürlich wäre es für mich als alten "Linuxer" am schönsten, wenn ich die Anwendung Platformübergreifend schreiben könnte, aber ich sehe ein, dass mir dafür zur Zeit noch das KnowHow fehlt. Ich müsste bei jedem Aufruf, der Dateipfade betrifft erst überprüfen, welches Zielsystem ich habe, bzw. schon beim Start den Wert irgendwie speichern (hierfür würde sich entweder eine Datei oder eben eine globale Variable eignen.).
Ich habe mich jetzt entschlossen den schlechteren Weg zu gehen und erstmal die Anwendung für Windows zu entwickeln und dann später die Funktionen Nachzurüsten. Das ist deutlich mehr Arbeit, aber im Moment ist es nicht anders machbar.
Deswegen Vielen Dank für die großartige Hilfe hier im Forum!
Ohne dich hier angreifen zu wollen denke ich nicht, dass die Kabeltechnik ein "Relikt" ist. Die Programmablaufsteuerung per Kabeltechnik hat auch viele Vorteile gegenüber klassischen Programmiermethoden. Schnell genannt sei hier parallele Ausführung.
Ich denke eher, dass dein Problem ist - wie es nunmal immer ist, wenn man etwas neues erlernt -, dass du noch nicht gewohnt bist auf diese Art zu denken (programmieren), bzw. viele Funktionalitäten von LV noch nicht kennst. Dein Beispiel einer Funktion mit eigenem Header lässt sich z.B. sehr einfach mit einem SubVi realisieren. Mit Funktionen wie "Reentrant", Typdefinition "Variant" und polymorphen Vis kannst du auch in LV jegliches gewünschtes Verhalten erzeugen (wie z.B. unabhängigee Eingangstypen der Funktion). Es ist halt alles eine Frage des Know Hows, wobei dir hier im Forum mit Sicherheit gerne geholfen wird
Grüße
A few weeks of developement and testing can save a WHOLE afternoon in the library!
' schrieb:Ohne dich hier angreifen zu wollen denke ich nicht, dass die Kabeltechnik ein "Relikt" ist. Die Programmablaufsteuerung per Kabeltechnik hat auch viele Vorteile gegenüber klassischen Programmiermethoden. Schnell genannt sei hier parallele Ausführung.
Ich denke eher, dass dein Problem ist - wie es nunmal immer ist, wenn man etwas neues erlernt -, dass du noch nicht gewohnt bist auf diese Art zu denken (programmieren), bzw. viele Funktionalitäten von LV noch nicht kennst. Dein Beispiel einer Funktion mit eigenem Header lässt sich z.B. sehr einfach mit einem SubVi realisieren. Mit Funktionen wie "Reentrant", Typdefinition "Variant" und polymorphen Vis kannst du auch in LV jegliches gewünschtes Verhalten erzeugen (wie z.B. unabhängigee Eingangstypen der Funktion). Es ist halt alles eine Frage des Know Hows, wobei dir hier im Forum mit Sicherheit gerne geholfen wird
Grüße
Hallo,
da ich ja tatsächlich Anfänger bin, kann ich mich auch gar nicht angegriffen fühlen. Ich erkenne voll und ganz, dass ich hier Wissenslücken habe, aber gerade diese werde ich demnächst schließen. Ich bin froh, dass mir hier bisher immer geholfen wurde und nicht wie leider in anderen Boards üblich soetwas wie: "Lass die Finger davon, wenn du keine Ahnung hast". Daher an alle: Danke
