DO-Signal liegt nicht lang genug an

Hallo miteinander,
ich kämpfe immer noch mit meinem digitalen Ausgang. Das VI läuft auf einem echtzeitfähigen PC mit NI 6259 Messkarte.
Beim drücken eines Schalters soll für 1000ms ein True-Signal ausgegeben werden, dann wieder solange False, bis erneut der Schalter gedrückt wird. Wenn ich den Schalter auf dem Frontpanel betätige, kann ich aber am Osci nur einen High-Status für 10ms erkennen. Der High-Status wird also nicht lang genug ausgegeben, sondern nur für die Periode meiner zeitgetakteten Schleife. Wenn ich aber den Schalter kurz hintereinander 2mal betätige, liegt tatsächlich 1s lang ein High-Signal an (am Osci genau 1 s sichtbar). Wieso funktioniert es wenn ich den Schalter 2mal kurz aufeinander betätige, aber nicht, wenn ich ihn nur einmal drücke?

Danke im Vorraus

Anzeige

Hallo cRio,

abgesehen davon, dass mir der "Wenn TRUE dann TRUE"-RubeGoldberg schon wieder einen dicken Hals beschert: THINK DATAFLOW!!!
Dein bool-Ausgang wird erst nach Beenden der Case-Struktur gesetzt (warum wohl bei Dataflow?), und die Case-Struktur wird erst nach Ablauf der Wartezeit beendet. Dann wird die nächste iteration aufgerufen: ich vermute mal keine Wartezeit im FALSE-Case. Und jetzt darfst du selbst überlegen, was wohl (DATAFLOW sei Dank) passiert...

Erstmal fettes Danke!
Du willst mir also folgendes sagen: erst läuft die Zeit ab (dank dem Wait ms), dann wird noch kurz vor verlassen des CaseFalls das True auf den Ausgang gelegt und im nächsten Rechenschritt bin ich schon wieder im Zustand des Wartens auf den Startknopf. Deswegen lag das True also nur 10ms (=einen Schleifendurchlauf) an.

Ich hab es jetzt mal mit einer Enum-Struktur gelöst, so ähnlich wie du es hier mal erklärt hast:
http://www.labviewforum.de/Thread-Zeitsteuerung

Es war aber auch zu verlockend, zu glauben, dass Labview, im Gegensatz zu Simulink, alles gleichzeitig erledigt sofern man sich nicht explizit mit einer Sequenz um die Reihenfolge des Ablaufs kümmert. Mit Dataflow meinst du, dass LabView sehr wohl "von links nach rechts" (etwas plump formuliert) den Code abarbeitet oder? So dämlich wie ich es implementiert habe, wäre also die Wartezeit im False-Case dafür zuständig gewesen, den Status der DigitalLeitung auf High zu halten und nach Ablauf der Zeit wäre, dank Dataflow, erst der DigitalOut auf LOW zurückgesetzt worden. Und nicht die Zeitspanne im TrueCase, so wie ich dachte.

Hier für alle: so gehts

Eine Frage hätte ich doch noch zu meinem obigen Bild: wenn ich in meine CaseStruktur eine Sequenz einfüge, wobei ich erst ein True auf den dig. Out lege und im Rahmen danach das "Wait ms" einfüge, dann würde ich ihm die richtige Reihenfolge aufzwingen. Also erst True auf den Ausgang, dann Timer laufen lassen. Es funktioniert allerdings trotzdem nicht weil:
ich VERMUTE: er springt mir dank des Schalters "Latch when pressed" sofort wieder zurück in den Zustand, wo er wartet dass man den Startknopf drückt oder? Er kommt also garnicht dazu, das Wait ms auszuführen, denn da ist er schon zurückgesprungen in den False-Case. Neben der Reihenfolge aufgrund der SequenzStruktur müsste ich ihm also noch klar machen, dass er im Falle eines TrueCase diesen auch einmal komplett abarbeitet, auch dann, wenn der Schalter schon lange zurückgesprungen ist auf False. Und das löst man dann eben am besten mit mehreren Zuständen (Enum) die du in dem erwähnten Thread (siehe oben) verwendet hast

Hallo cRIO,

jetzt nochmal ohne Enums und Waitstates - mit einfachster Arithmetik: