Queued State Machine, paralleles lesen und schreiben.

Guten Tag,

ich habe zurzeit eine Denkblockade bei der umsetzung der Problemstellung und würde euch einfach um ein paar tipps bitten.

Funktionalität:
Momentan existieren 3 Optionen unter dennen der Benutzer wählen kann und mit der die Steuerung(serielle Schnittstelle) angesteuert wird (blöder Satz).
1. Option sendet nur einen Schreibe-Befehl
2. Option sendet in einer bestimmten Frequenz einen Schreibe Befehl.
3. Option fragt die aktuellen Werte ab und entscheidet dann, ob er schreiben muss oder warten.

Währendessen soll das Vi kontiuierlich Die Werte auslesen, damit der Nutzer weiß z.B. was für ein Strom momentan herrscht.

Denkblockade:
Ich denke, dass ich dieses Problem gut mit einer queued Statemachine umsetzen kann, aber ich komme da auf 3 Ebenen.
Die erste Schleife kümmert sich eigentlich nur um die Events, wie die Wahl der Option oder die Stopptaste.
Die zweite Schleife sollte eigentlich die Option abarbeiten.
Und die dritte nur lesen und die Werte Grafisch darstellen oder so.
Doch ich bekomme hier meinen Denkfehler rein, denn wenn ich nebenbei parallel auslese, könnte es doch zu Schwierigkeiten beim Puffer kommen, so das z.b. ein Befehl zum falschen Zeitpunkt ankommt. Außerdem muss ich bei einer Option die ausgelesenen Werte verarbeiten und zwischenspeichern usw.

Dann hatte ich mir noch überlegt, ob ich einfach meine 3. Schleife nur für die Kommunikation zwischen dem Pc und der Steuerung nutze, aber dann habe ich wieder das Problem mit dem hin und her senden...

Um Grund beschäftigt mich die Frage, wie ich sauber parallel Werte aktualisieren kann und diese wenn nötig abgreifen und verarbeiten kann.

Ich hoffe es ist nicht zu verwirrend geschrieben, aber ich kann es leider nicht besser formulieren. Ich hoffe denoch, dass ihr mir iwie helfen könnten, in meine Struktur eine Ordnung zu bringen.

Mit freundlichen Grüßen

Atilla

Ein konkretes Vi existiert nicht, nur unabhängiges zusammen geklicke.

Ich sehe keinen direkten Bedarf für 3 Schleifen, 2 langen voll und ganz.

Eine kümmert sich um das User-Interface, und die zweite um die RS-232-Kommunikation.
Wie du richtig erkannt hast, wirst du große Probleme bekommen, wenn 1 Prozess dauernd irgendwelche Messwerte abfragt, und ein anderer parallel bei Bedarf andere Anfragen sendet.
Also muss das in eine Schleife, die entweder - wenn nichts zu tun ist - aktuelle Werte abfragt oder - auf Anfrage - eine Sonderabfrage startet.

Gruß, Jens

Also, wenn ich dich richtig verstehe, soll ich die Abfrage in den Leerlauf stecken, weil wenn der eine Zustand durch ist kommt der ja automatisch dahin.

Aber wenn ich konkret was davon habe möchte, dann soll ich das auch ruhig direkt in dem gewissen state abfragen?

Gruß Atilla

Ich würde diese höher angesiedelten Fragen erst mal hintenanstellen und im ersten Schritt mich erst mal darum kümmern, dass die serielle Komnikation in beiden Richtungen sauber und stabil und läuft.
Dann würde ich das VI nebst Erläuterung zum Datenprotokoll hier posten und die Frage noch mal stellen.
Datenprotokoll: Das erscheint mir ungewöhnlich zu sein. Die Quelle sendet unaufgefordert, es wird also laufend vom PC empfangen, und beim Senden kommt es manchmal darauf an, dass das sofort nach einem bestimmten enmpfangenen Datensatz geschieht, bevor der nächste Datensatz abgeschickt wurde. Das ist aber mit dem Prinzip der Pufferung nicht richtig vereinbar, ich kann mir so keinen stabilen Betrieb vorstellen.
Normal wäre in so einem Fall der Master-Slave-Modus: Die Quelle sendet jeden Datensatz nur auf Anfrage, sonst nicht.

Also sagen wir mal so, es wäre schön wenn ich kontinuierlich einen aktuellen Wert liefern könnte. Es ist aber wahrscheinlich etwas zu hoch gegriffen für meine bescheidenen Labview Kenntnisse. Darum versuche ich jetzt alle meine Sende-Befehle einzureihen.

D.h. für aktuelle Werte muss ich zuvor eine Anfrage schicken. Nun möchte ich das so regeln, dass ich einfach alle "write" Vis hintereinander setze und und den Visa-ausgang per Schieberegister wiederhole.

Damit hätte ich doch dann eine Reihenfolge festgelegt, oder?

Mein Vi, es ist so konzipiert, dass es eigentlich überall funktioniert, die subvi werden nicht genötigt, da sie eigentlich nur einen String zusammen basteln und absenden.

   

  queue_manager.vi (Größe: 23,26 KB / Downloads: 326)

Inzwischen lautet meine Antwort: "Hängt vom RS232-Gerät ab"...

Konstruieren wir folgendes Bsp:
Der Antwort-String deines RS-232-Gerätes enthält eine eindeutige Identifikation, was gerade gesendet wurde.
Dann könnte man sich vorstellen, Lesen und Schreiben zu trennen, den prinzipiell ist RS-232 duplex-fähig.
In der Lese-Loop wird der Antwort-String entsprechend geparst und vorher versandten Befehlen zugeordnet.
Nicht ganz ohne, aber geht.

Der Standard-Fall ist das aber sicher nicht. Der ist, dass das RS-232-Gerät erst etwas auf Anfrage zurückmeldet. Und dann kommt du mit einer Kommunikationsschleife aus. Diese fragt im "Leerlauf-Fall" aktuelle Werte ab, und ansonsten führt sie das aktuell gewählte Kommando aus.

Gruß, Jens

Anzeige

(25.02.2013 14:57 )jg schrieb:  Der Standard-Fall ist das aber sicher nicht. Der ist, dass das RS-232-Gerät erst etwas auf Anfrage zurückmeldet. Und dann kommt du mit einer Kommunikationsschleife aus. Diese fragt im "Leerlauf-Fall" aktuelle Werte ab, und ansonsten führt sie das aktuell gewählte Kommando aus.

Der Standard-Fall trifft auch wohl auf mich zu. Also werde ich das dann auch so machen, wie es beschrieben hast.

Nun stellt sich mir aber dann eine weiterführende Frage und zwar werden die im Leerlauf abgefragten Werte grafisch Dargestellt oder zumindest einfach nur auf dem Frontpanel ausgegeben. Wenn ich aber nun in dem State bin, dass ich "extra Abfragen" starte, wie schaffe ich es, dass der Benutzer davon nichts merkt?

Und eine kleine zwischen Frage.
In meinem Vi-Ausschnitt kann man sehen, dass ich in der Eventstruktur eine Typumwandlung benutzt habe. Bei meiner ersten Anwendung hat alles funktioniert, aber nun geht gar nichts. Egal was ich auswähle, die Typumwandlung gibt immer das selbe zurück. Warum?


  states.ctl (Größe: 4,13 KB / Downloads: 243)
DAs wird dafür noch benötigt

Als Beispiel hab ich ein kleines Vi erstellt, was aber genau auf meine 2. Frage anspielt:


  typumwandlung.vi (Größe: 4,05 KB / Downloads: 256)


  typumwandlung.ctl (Größe: 4,09 KB / Downloads: 229)