Hallo,
ich bekomme bei meiner State Machine eine Fehlermeldung: "Selector values are not unique. A selector value is used by more than one case. It may be in the middle of a range in one of the cases."
Ich hab auf der NI Seite schon geschaut (
http://zone.ni.com/reference/en-XX/help/...t_unique/) Bin aber der Meinung, dass das bei mir nicht zutrifft
Was sagt ihr dazu???
Danke,
Garth
' schrieb:Was sagt ihr dazu???
String als Selektor finde ich nicht gut.
Ohne es ausprobiert zu haben, sage ich folgendes: "Leak Test" ist größer als "6". Demzufolge befindet sich die Zeichenfolge "Leak Test" im Bereich ["6"...]. Somit ist nicht eindeutig, welcher Case bei "Leak Test" ausgeführt werden soll.
Hhmm, ich kenne die State Machine nur mit String als selector, dachte das wäre die einfachste Art dies umzusetzen. Übrigens hab ich die anderen Tasks auch mal probeweise anders benannt, also A,B, C usw. Ging auch nicht!
Edit: Ich hab gerade hier gerade gesehen, dass es auch mit dem Enum geht...ist diese Variante vorzuziehen?
Auf jeden Fall, aber dann bitte als TypeDef.
Gruß Markus
' schrieb:Edit: Ich hab gerade hier gerade gesehen, dass es auch mit dem Enum geht...ist diese Variante vorzuziehen?
' schrieb:Ohne es ausprobiert zu haben, sage ich folgendes: "Leak Test" ist größer als "6". Demzufolge befindet sich die Zeichenfolge "Leak Test" im Bereich ["6"...]. Somit ist nicht eindeutig, welcher Case bei "Leak Test" ausgeführt werden soll.
Nachtrag: Hier der Versuch:
[
attachment=24762]
@Garth:
Das Hauptproblem bei deiner Case-Strukur ist, dass du 2x einen Bereich hinzugefügt hast, also [..."Leak Test"] und ["6"...]. Lass das weg, gerade wegen den Strings als Case-Selector. Denn was bedeutet schon größer oder kleiner bei Strings? Definiere lieber einen Case als Default-Case, der immer ausgeführt, wenn dein String nicht zur Auswahl passt.
Gruß, Jens
' schrieb:Edit: Ich hab gerade hier gerade gesehen, dass es auch mit dem Enum geht...ist diese Variante vorzuziehen?
Auf jeden Fall.
Ein Enumerator macht nämlich genau das, was du haben willst: Im Selektor wie auch im Rest des Programmes steht ein "lesbares Wort", also ein "String". Außerdem eliminiert das Verwenden eines Enumerators automatisch alle Nachteile eines Strings: Enumes haben aufgrund ihrer expliziten Typdefinition eine nachvollziehbare Reihenfolge, man kann sich nicht vertippen wie bei Stirsniggs, sie vereinfachen das Debugging erheblich und verbrauchen weder Speicher noch CPU-Ressourcen.
An den Selektoreingang kannst du anschließen, was du willst (naja, sag ich mal sehr viel): Bool, Enums, alle Festpunktzahlen (U8 .. I64), Errorcluster. Und - ich glaub es ja nicht - sogar DBL! Die Case-Struktur passt sich automatisch an. (Diese Sache, an einen Eingang anschließen zu können, was man will, heißt polymorph: Ein sehr wichtiger Bestandteil von LabVIEW.)
Nachtrag:
Ihr seht schon, ich hab heute langeweise. Ich muss Küche und Bad renovieren. Da kommt jede Abwechslung recht.
' schrieb:Auf jeden Fall, aber dann bitte als TypeDef.
Hier sollte man einem Newbie noch die Erklärung liefern warum das sinvoll ist:
Bei State-machines ist es im Entwicklungsstadium unvermeidbar, daß States hinzugefügt oder weggenommen werden. Das bedeutet dann jedesmal: Alle State-Konstanten im Enum-Format müssen von Hand geändert werden. Erstellt man hingegen ein Enum-Bedien- oder Anzeigeelment als Typdefinition und erzeugt davon mit der rechen Maustaste die Enum-Konstanten, dann haben diese eine wunderbare Eigenschaft: Wenn das Hauptelement editiert wird, dann ändern sich wie von Zauberhand alle Konstanten mit.
Super, danke! Werds am Montag gleich ausprobieren!!!