verknüpfte Schalter

Ich versuche mich in LV einzuarbeiten - also blutiger Anfänger.


Folgendes Problem möchte ich lösen:

2 Schalter wirken auf 2 Ausgänge und sollen sich wie folgt verhalten:

Schalter A auf EIN: Ausgang 1 UND Ausgang 2 gehen an (wenn Ausgang 2 vorher an war, soll er an bleiben).

Schalter B auf EIN: Ausgang 2 wechselt seinen Zustand (unabhängig vom vorherigen Zustand).

Schalter A auf AUS: Ausgang 1 UND Ausgang 2 gehen aus (auch wenn Ausgang 2 vorher schon aus war, soll er aus bleiben).

Schalter A soll auf einem 2. Bedienpanel ebenfalls unabhängig bedienbar sein.


Das angehängte VI ist natürlich völliger Quatsch - nur als Arbeitsgrundlage gedacht.
Ein direktes verdrahten der Schalter über eine Logik ist wohl nicht sinnvoll, da die Schalterzustände sich auch unabhängig ändern lassen sollen.

Bitte um eine Hilfe.

Anzeige

Ohne dir zunahe treten zu wollen: solche Fragen haben für mich immer einen Hausaufgaben Charakter.
Wo soll man da anfangen? Es wird nach einer Lösung gefragt ohne konkrete Anhaltspunkte zu haben. Wo bleibt da der Lerneffekt?
Hier gibt es ettliche, die das Problem schnell lösen können, aber davon hast du recht wenig (IMHO). Schreib mal was selber, Optimierungen wirst du dann sicher zu hauf erhalten!
Implenetiere erst mal eine Lösung wie es halbwegs geht und wenn du dann noch Probleme hast, melde dich wieder.
Als Anhaltspunkt: versuchs doch mal mit Schieberegistern und Case-Structures

Gruss,
Christian

Danke für den Hinweis.

Ich werde Besserung geloben und mich damit auseinandersetzen.

Das angehängte vi schafft es fast. Allein wenn Schalter A von EIN nach AUS wechselt UND Schalter B EIN ist, geht Ausgang 2 NICHT aus.

Dafür bräuchte ich eine Flankenerkennung. Gibt es sowas (habe es bisher nicht gefunden)?

Na also, sieht doch schon mal nicht schlecht aus
Und jetzt hast du sicher mehr gelernt, als wenn es dir jemand programmiert hätte.

Jetzt zu deinem Programm:
verwende keine lokalen Variablen innerhalb eines Schleifenaufrufs. Du zerstörst so den Datenfluss und es kann zu sogenannten RaceConditions kommen.
Platziere innerhalb von while-Schleifen immer ein wait-Baustein. Soll die Verarbeitung schnell vonstatten gehen, verdrahte 0ms daran. Bei GUI-Programmen sind 50ms schnell genug (meist sogar 200ms). Du ermöglichst es so dem LabVIEW compiler Ressourcen auch für andere Programmabschnitte zuzuweisen. Sonst geht dir die CPU an den Anschlag. Über die wait-Funktion kannst du dein Programm hierarchisch gestallten (sofern mehr als eine while-Schleife im Code vorkommt).
Hier jetzt mal ein Vorschlag von mir mit einer Event-Structur und Schieberegistern.

Schönes WE
Christian



[EDIT] Danke Jens für's ergänzen der LabVIEW Version....

Hallo Christian,

DANKE für Deine Bemühungen.

Aber auf diese Case-Struktur wäre ich im Leben nicht gekommen.

Ein Punkt funktionierte nicht so, wie ich es mir wünschte: der Schalter B blieb trotz AUS auf Ausgang 2 gesetzt (EIN).

Aber mit einer kleinen Änderung tut es jetzt genau so wie gewünscht.


Wenn ich noch auf Deinen Wissensschatz zugreifen dürfte: seit mehr als 15 Jahren "programmiere" ich in Dasylab, und muss sagen, es ist einfach intuitiver (ich komme aus der Messtechnik/ETechnik). Alle Messaufgaben konnte ich bisher damit lösen. Das Schalterproblem entlockte mir in Dasylab ein müdes Lächeln und 3 Funktionsblöcke.
Eine Funktion, die ich in Dasylab schätzen gelernt habe, ist der "Farbumschlag" bei Digitalinstrumenten, wenn bestimmte Wertegrenzen unter-/überschritten werden.
Geht das auch in LabVIEW?

Hallo renrew,

"seit mehr als 15 Jahren "programmiere" ich in Dasylab, und muss sagen, es ist einfach intuitiver (ich komme aus der Messtechnik/ETechnik)"

Ich habe vor LabVIEW lange Assembler programmiert und fand es auch intuitiver:)Ist alles eine Sache der Einarbeitung und Gewöhnung...

Den Farbumschlag kannst du in LV auch bekommen, nur nicht automatisch. Aber wofür sonst gibt es Vergleichsoperatoren und Propertynodes? Dafür hast du dann aber die Wahl, was du alles bunt machst oder zum Blinken bringst...
   
(Die PropertyNode gehört zum Control "Numeric", wird leider durch das Snippet so verhunzt...)

' schrieb:Wenn ich noch auf Deinen Wissensschatz zugreifen dürfte: seit mehr als 15 Jahren "programmiere" ich in Dasylab, und muss sagen, es ist einfach intuitiver (ich komme aus der Messtechnik/ETechnik).

Hallo renrew
das mit dem intuitiver ist immer so eine Sache. Ich kam aus der C/C++ Welt, da war mir alles dort intuitiver. Ich fand die Herausforderung jedoch spannend, meine C Gedanken in LabVIEW umzusetzen. Und jetzt mach ich fast nur das (und ein bisschen C#, wenn's mit LabVIEW nicht weiter geht oder unsere DUT-Treiber es verlangen).

Zu meinem Code: da hab ich dich wohl falsch verstanden, aber egal, es läuft ja jetzt. Die Case-Struktur ist eine besondere Case-Struktur. Es ist eine Ereignisstruktur, die die Cases dann abfeuert, wenn ein bestimmtes Ereignis eintritt (entweder ein GUI-Ereignis oder eins, das per Software ausgelöst wird)
Zu deinem Code: ich würde keine Referenz verwenden, um den Wert des Schalter B's zu verändern. Das braucht mehr Ressource, als eine lokale Variable. Referenzen verwende ich nur, um Einstellungen am Design zu verändern, so wie es GerdW in seinem Bild gezeigt hat. Um den Wert von Schalter B zu verändern, ist eine lokale Variable zu verwenden ok (bei den lokalen Variablen scheiden sich die Geister: manche vermeiden sie wie die Pest, andere setzten sie doch dann und wann ein), denn der Datenfluss wird durch die Ereignisstruktur gewährleistet. Wenn du dieses Pattern ein wenig erweiterst, kommst du zu einer State-Machine. Dort verwende ich für "kleine" Daten immer lokale Variablen, um die Daten zwischen den States auszutauschen.

viele Grüsse
Christian

@renew:

Bitte beachten, bzw. lies deine PNs:
http://www.LabVIEWforum.de/LV-Version-hoch...d39s-t7949.html

Gruß, Jens