Ende der seriellen Übertragung (RS232)

' schrieb:Funktioniert es nicht einfach auch so, dass ich über VISA-Write einen Befehl an den Controller schicke, dann von mir aus 100 ms warte, bis der Controller alles verarbeitet hat und dann ein VISA-Read mache? Stehen dann nicht automatisch alle Daten (vorausgesetzt die 100 ms reichen) im VISA-Read-String?

Jawohl, das wird genau so gehen.
Ist die Voraussetzung erfüllt, werden am Ende die erwartete Anzahl von Zeichen automatisch im VISA-Read-String stehen. (Nebenbei: Dafür hab' ich ja eine Programmiersprache/IDE wie LabVIEW, damit nach Möglichkeit alles automatisch geht. Das Problem und gerade bei einer RS232-DÜ ist aber eben, was tun, wenn ein Zeichen auf dem Kabel verloren geht. Die wenigsten arbeiten mit einem selbstsicheren Protokoll. Diese Tatsache - und weil eben eine RS232-DÜ sehr applikationsabhängig ist - widerspricht einer Automatisierung).

Zitat:Durch das Read wird dann doch der Controller-Puffer geleert und bei der nächsten Anfrage schreibt der Controller die nächsten Daten in den Puffer...., oder nicht?

Durch den Read wird nicht der Puffer im SIO-Controller geleert. Der muss geleert werden, sobald die Daten da sind. Vom SIO-Controller-Puffer werden die Daten in einen Zwischenpuffer gelegt. Von dort holt sie dann das VISA-Read ab. Würde man das nicht so machen, träte im folgenden ein Problem auf: Baudrate 115kBd (beachte: ca. 100µs pro Byte, das sind zwei Taskswitches in Win32/W2K), Win32 ist beschäftigt und verweigert der LV-Applikation, in der der VISA-Read-Befehl läuft, die Prozessorzeit für Ring Drei. Wenn dieser Zustand für z.B. 30ms (vergleiche 100µs) andauern würde, würden Daten verloren gehen. Der SIO-Empfang auf Controller-Ebene findet daher im Ring Null statt und ist interruptgesteuert. Dieser Interrupt (und das damit verbundene Controller-Auslesen und sichere Datenspeichern) funktioniert immer, egal was Win32 in Ring Drei treibt (Voraussetzung ist natürlich, dass alle anderen Systemtreiber den Ring Null nicht blockieren. Mir ist das aber noch nicht untergekommen).

Zitat:Oder gibt es dann einen VISA-Timeout, da nach den paar Bytes, die ich gelesen habe kein weiteres folgt?

Im Prinzip ja. Wenn du lesen willst, und es kommt nichts, dann kannst du so einstellen, dass eben ein Timeout eintritt. Was auch richtig und wichtig ist. Das Programm soll ja schließlich nicht hängenbleiben beim Warten auf Zeichen, die gar nicht kommen können, weil jemand auf das Kabel getreten ist und das dann ...

Zitat:Oder ist es so, dass LabVIEW, sobald der Controller-Puffer ausgelesen wurde, den Read-Befehl automatisch beendet?

Erstens: Nicht der Controller-Puffer, der interne Zwischenspeicher.
Zweitens: Der Read-Befehl wird in erster Linie nicht beendet in Abhängigkeit vom Füllungsgrad des Puffers - sondern von deinen Vorgaben. Wenn du sagst, "Lese 10 Zeichen ohne Timeout" wird der Read-Befehl solange warten, bis eben 10 Zeichen da sind - notfalls auch ewig. Wenn du sagt "Lese was da ist", wird er genau das tun. Dann hast du entweder keine Zeichen, eines, sieben oder auch 12345 Stück. Sinnvoll ist aber - weil eben einfach - zu sagen "Lese 10 Stück mit Timeout".

Zitat:Wenn das mit der Wartezeit nicht funktioniert,

Öhm, warum sollte das nicht funktionieren. Das geht eigentlich immer.

Zitat:wie funktioniert das dann mit der Abfrage der Byte-Anzahl? Schaut LabVIEW in dem Puffer des Controllers nach, ob da die gewünschte Byteanzahl vorhanden ist und wenn ja, leert sich der Puffer ganz einfach mit dem Read?

(Nicht des Controllers, des Zwischenspeichers.) Genau: der Puffer leer sich ganz einfach mit dem Read. Natürlich leer er sich nur soweit, wie der Read-Befehl Daten anfordert.

Zitat:Was genau meinst Du mit Parsen?

Ein Zeichen lesen. In Abhängigkeit dieses Zeichens weitere Zeichen lesen. Die Anzahl der weiteren Zeichen kann vom Wert des ersten Zeichens abhängen. Genauso der Typ der weiteren Zeichen (String oder Zahl). Parsen kommt natürlich nur dann in Frage, wenn du nicht genau weist, das du erwartest.

Zitat:Hättest Du mir evtl. auch irgendwo ein VI, wo man das sehen könnte?

Da muss ich erst noch mit mir ringen. Da müsste ich LV6 nach LV8.2 (neues wird nicht mehr in LV6 gemacht) konvertieren. Und von den Problemen mit der Konvertierung hast du ja bestimmt schon gehört (in LV8.2 gibt es z.B. keine Referenzen auf Cursor-Legende mehr). Und die vielen Globalen.

Hallo,

vorerst mal vielen Dank für die ausführliche Hilfe. Jetzt habe ich es einigermaßen verstanden.
(Der SIO Controller - Puffer wird ja automatisch durch den Interrupt geleert und muss nicht durch mich erfolgen, oder etwa doch?)
Wenn ich mit dem Programmieren des Controllers anfange, dann probiere ich mit Deinen Tips, inwieweit ich das "Problem" gelöst kriege. Sollte es dann zu Problemen kommen, dann bin ich so frei und frage einfach nochmal nach.

Gruß Markus

PS: Ich kriege mit der Fragerei schon ein schlechtes Gewissen.

' schrieb:(Der SIO Controller - Puffer wird ja automatisch durch den Interrupt geleert und muss nicht durch mich erfolgen, oder etwa doch?)

Mit dem SIO-Controller als solchem hast du als Applikations-Programmierer gar nichts zu tun. Das ist zwei Ebenen unter der Ebene, bei der du das denken aufhören darfst. Du darfst bezüglich des Sendens/Empfangens getrost dem LV-System vertrauen. (Vorausgesetzt du hast die Schnittstelle richtig konfiguriert.) Du fragst ja auch nicht nach, wie die Analogdaten vom Analogcontroller mittels Interrupt oder gar DMA-Transfer in das DAQmx-Read-VI kommen - auch hier tust du nur konfigurieren. Um was du dir aber tatsächlich zumindest Gedanken machen musst, ist die Datensicherheit - das ist aber was ganz was anderes als die DÜ an sich.

Zitat:Wenn ich mit dem Programmieren des Controllers anfange, dann probiere ich mit Deinen Tips,

Wie du's tatsächlich machen kannst, kommt auf die Applikation an. Was für die eine sehr gut ist, kann für was anderes ganz schlecht sein.

Zitat:Ich kriege mit der Fragerei schon ein schlechtes Gewissen.

Kennst du die Sesamstraße? Wer nicht fragt, bleibt dumm.


Ach ja, und dass ich's nicht vergesse: Ein Beispiel für eine Steuerung eines Messgerätes (SMAC) über die Serielle Schnittstelle. Gesendet werden Befehle, was das Gerät tun soll. Empfangen werden während des Ablaufes immer die gleichen Daten: Aktuelle Position ("S") + Aktuelle Kraft ("F", 0..600N) + Aktuelle Ausregelindex ("K", 0..32500). Am Ende der Messung einmal die Anzahl der gesendeten Daten ("Z"). Das Programm besteht aus einer dreiteiligen Sequenz: Init, Arbeiten, Beenden. Arbeiten ist immer als While-Schleife ausgelegt, in der alles, was möglich ist (das hab ich natürlich alles gelöscht) überprüft bzw. nach Vorgabe abgearbeitet wird.

Vielen Dank noch mal für Deine Geduld, Deine hilfreichen Informationen und Dein Beispiel. Irgendwann Anfang nächstes Jahr fange ich mit dieser Programmierung an und melde mich dann einfach nochmal, falls ich irgendwo nicht weiterkommen sollte.

Gruß Markus

' schrieb:Mit dem SIO-Controller als solchem hast du als Applikations-Programmierer gar nichts zu tun. Das ist zwei Ebenen unter der Ebene, bei der du das denken aufhören darfst. Du darfst bezüglich des Sendens/Empfangens getrost dem LV-System vertrauen. (Vorausgesetzt du hast die Schnittstelle richtig konfiguriert.) Du fragst ja auch nicht nach, wie die Analogdaten vom Analogcontroller mittels Interrupt oder gar DMA-Transfer in das DAQmx-Read-VI kommen - auch hier tust du nur konfigurieren. Um was du dir aber tatsächlich zumindest Gedanken machen musst, ist die Datensicherheit - das ist aber was ganz was anderes als die DÜ an sich.

Wie du's tatsächlich machen kannst, kommt auf die Applikation an. Was für die eine sehr gut ist, kann für was anderes ganz schlecht sein.

Kennst du die Sesamstraße? Wer nicht fragt, bleibt dumm.
Ach ja, und dass ich's nicht vergesse: Ein Beispiel für eine Steuerung eines Messgerätes (SMAC) über die Serielle Schnittstelle. Gesendet werden Befehle, was das Gerät tun soll. Empfangen werden während des Ablaufes immer die gleichen Daten: Aktuelle Position ("S") + Aktuelle Kraft ("F", 0..600N) + Aktuelle Ausregelindex ("K", 0..32500). Am Ende der Messung einmal die Anzahl der gesendeten Daten ("Z"). Das Programm besteht aus einer dreiteiligen Sequenz: Init, Arbeiten, Beenden. Arbeiten ist immer als While-Schleife ausgelegt, in der alles, was möglich ist (das hab ich natürlich alles gelöscht) überprüft bzw. nach Vorgabe abgearbeitet wird.