25.02.2013, 13:02
Beitrag #1
|
Atilla
LVF-Gelegenheitsschreiber
Beiträge: 65
Registriert seit: Oct 2012
11
2012
DE
Deutschland
|
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.
|
|
|
25.02.2013, 13:20
Beitrag #2
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
RE: Queued State Machine, paralleles lesen und schreiben.
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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Einführende Links zu LabVIEW, s. GerdWs Signatur.
|
|
|
25.02.2013, 13:25
Beitrag #3
|
|
|
25.02.2013, 13:50
(Dieser Beitrag wurde zuletzt bearbeitet: 25.02.2013 13:54 von Lucki.)
Beitrag #4
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
RE: Queued State Machine, paralleles lesen und schreiben.
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.
|
|
|
25.02.2013, 14:14
Beitrag #5
|
Atilla
LVF-Gelegenheitsschreiber
Beiträge: 65
Registriert seit: Oct 2012
11
2012
DE
Deutschland
|
RE: Queued State Machine, paralleles lesen und schreiben.
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: 321)
|
|
|
25.02.2013, 14:57
Beitrag #6
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
RE: Queued State Machine, paralleles lesen und schreiben.
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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Einführende Links zu LabVIEW, s. GerdWs Signatur.
|
|
|
25.02.2013, 15:17
(Dieser Beitrag wurde zuletzt bearbeitet: 25.02.2013 15:35 von Atilla.)
Beitrag #7
|
Atilla
LVF-Gelegenheitsschreiber
Beiträge: 65
Registriert seit: Oct 2012
11
2012
DE
Deutschland
|
RE: Queued State Machine, paralleles lesen und schreiben.
(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: 237)
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: 250)
typumwandlung.ctl (Größe: 4,09 KB / Downloads: 224)
|
|
|
| |