unterschiedliche Anzahl numerischer Eingabeelemente?

Hallo LV-Gemeinde,

Ich hätte mal folgende Frage:

Besteht irgendwie die Möglichkeit bei Aufruf eines VI ( von mir aus auch danach. ist erstmal unwichtig ) eine unterschiedliche Anzahl von
numerischen Eingabeelementen zu generieren?

Hintergrund ist der, dass in diesem VI für die unterschiedlichen Kanäle eines Prüfstandes Grenzwerte gesetzt werden sollen.
Die Kanalanzahl soll sich aber ändern können, je nachdem um was für eine Prüfung es sich handelt. Für die Anzeige der Kanalnamen und -adressen würde ich eine Tabelle nutzen, die ich ja in ihrer Zeilenanzahl dynamisch gestalten kann.
Nun hab ich halt das Problem mit der dynamischen Anzahl an Eingabeelementen der kanalzugehörigen Grenzwerte.

Ich hoffe ich hab mich verständlich ausgedrückt.

Vielleicht hat ja auch jemand einen anderen Vorschlag, wie ich die Eingabe der Werte realisieren könnte. Ich hab irgendwie keinerlei andere Ansatzpunkte.

Ach ja, LV 6.1 läuft da gegenwärtig auf dem Prüfstand und soll wohl auch erstmal drauf bleiben.

Vielen Dank schonmal im Vorraus

Mfg

Anzeige

(27.04.2013 14:00 )gerln schrieb:  Nun hab ich halt das Problem mit der dynamischen Anzahl an Eingabeelementen der kanalzugehörigen Grenzwerte.

Eine Möglichkeit wären natürlich Arrays. Dort kannst du dynamisch, z.B. Beim Aufruf des VI's die Anzahl der Elemente festlegen. Dies funktioniert auch mit komplexen Datentypen:

   

Optisch kann man das natürlich noch besser gestalten, nur so könnte es konzeptionell aussehen.

Beste Grüße,
NWO

Vielen Dank,
ich denk mal das ist der Ansatz den ich weiter verfolgen werde.

Ich frage mich langsam ob meine geistige Umnachtung wirklich schon soweit vorangeschritten ist, dass ich nicht selber auf so etwas komme.

Nur noch kurz:
Kann mir vielleicht jemand auf die Schnelle sagen, ob ich in einer Event-Struktur(Wertänderung) den Wert im Array sehen kann, der sich geändert hat oder nur das sich das Array geändert hat .


Mfg

Du siehst den neuen und auch den alten Wert des gesamten Arrays. Kannst das/die geänderte(n) Element(e) somit aber selbst herausbekommen.

OK,
hatte ich schon so vermutet, aber hätte ja sein können..

Trotzdem Danke.

Mfg

(28.04.2013 11:12 )gerln schrieb:  Kann mir vielleicht jemand auf die Schnelle sagen, ob ich in einer Event-Struktur(Wertänderung) den Wert im Array sehen kann, der sich geändert hat oder nur das sich das Array geändert hat .

In Deinem Satz steckt implizit die Ausssage, dass ein Ereignis der Kategorie "Weränderung" immer nur bei Wertänderungen stattfindet. Logisch ist das eigentlich selbstverständlich, solange man der Benennung "Wertänderung" überhaupt trauen kann. Dem ist aber nicht so. Das gilt nämlich nur für Bedienereignisse.

Man kann aber das Ereignis "Wertänderung" auch mit dem Eigenschaftsknoten "Wert, signalisierend" auslösen, und hiefür genügt allein das Lesen des Knotens. Wenn sich der Wert nicht geändert hat - das Ereignis findet trotzdem statt.

Anzeige

(28.04.2013 14:44 )Lucki schrieb:  ...
Man kann aber das Ereignis "Wertänderung" auch mit dem Eigenschaftsknoten "Wert, signalisierend" auslösen, und hiefür genügt allein das Lesen des Knotens. Wenn sich der Wert nicht geändert hat - das Ereignis findet trotzdem statt.

Wichtig wäre hierbei wohl, dass man "Wert, signalisierend" explizit schreiben muss. Ich war jetzt ganz überrascht das es auch lesend gehen soll

Na ja... und dann wären da noch die Fälle wo der Nutzer den gleichen Wert nochmal einträgt... Dann kriegt man auch nen Ereignis aber findet nix (händisch) was man geändert hat.

Bottom Line:

In der Variante musst du alle Fälle bei denen sich trotz Ereignis "Wertänderung" nichts ändert also separat behandeln (wird vermutlich auf "nichts tun" hinauslaufen).

Entschuldigung, Fehler von mir: Bei "Wert, signalisierend" gibt es ja nur Schreibzugriff.
Es stimmt aber nicht, dass man bei fehlender Wertänderung im Ereignisknoten immer nur "nichts" tun muss.
Es kommt häufig vor, dass man den Ereignisknoten aus 2 Gründen aufrufen möchte:
1. Ein einziges Mal bei der Initialisierung das Programms
2. Ansonsten bei Wertänderung durch Bedienung.
Punkt 1 löse ich so, dass ich im Initialisierungsteil eine lokale Veriable des Bedienelementes an den Eigenschaftsknoten "Wert, signalisierend" anschließe. Es findet damit garantiert keine Wertänderung satt, aber der Ereignisknoten wird wie gewünscht aufgerufen.

Mir ist aber inzwischen klar, das das nicht die eleganteste Methode ist, das Initialisierungsproblem zu lösen. Besser ist die "Queue driven" Ereignisstrukur: In den Ereigniscases selbst steht kein Code, sondern es werden nur Kommandos in eine Queue geschickt. Der eigentliche Code wird dann in einer State-Machine-Struktur abgearbeitet. Auf den Code in der State-Machine kann man auch ohne den Umweg über ein Ereignis zugreifen - also z.B bei der Initialisierung.