Ende der seriellen Übertragung (RS232)

Hallo,

woher weiß LabVIEW eigentlich, dass ein Befehl/eine Antwort über die serielle Schnittstelle vollständig gesendet wurde (bei VISA Read und Write), um dann die Anzahl der anliegenden Bytes anzuzeigen. Es gibt doch nur ein Startbit und ein Stopbit und dazwischen ein Byte. Nach dem Stopbit könnte doch ein weiteres Byte (mit Start- und Stopbit kommen) kommen. Muss ich da was beachten, oder ist es so, dass LabVIEW automatisch erkennt, wenn ein Befehl/eine Antwort vollständig gesendet wurde?
Es läuft bei GPIB nämlich so ab, dass ich ein Befehl in in VISA Write reinschreibe und dann eine Antwort mit VISA Read auslese. Klappt das hier genauso problemlos?

Gruß Markus

Anzeige

' schrieb:woher weiß LabVIEW eigentlich, dass ein Befehl/eine Antwort über die serielle Schnittstelle vollständig gesendet wurde (bei VISA Read und Write), um dann die Anzahl der anliegenden Bytes anzuzeigen. Es gibt doch nur ein Startbit und ein Stopbit und dazwischen ein Byte. Nach dem Stopbit könnte doch ein weiteres Byte (mit Start- und Stopbit kommen) kommen. Muss ich da was beachten, oder ist es so, dass LabVIEW automatisch erkennt, wenn ein Befehl/eine Antwort vollständig gesendet wurde?

Du fragst hier nach zwei sachen: SIO senden und SIO empfangen.

SIO senden:
LabVIEW weis automatisch, wann alle Zeichen gesendet wurden. Nämlich wenn der Puffer (das ist der String, der dem Write-VI übergeben wurde) quasi leer ist und wenn gleichzeitig das Schieberegister im SIO-Controller (vorausgesetzt echte SIO statt USB-SIO, da wird es aber analoge Mechanismen geben) leer ist. Sobald das Schieberegister leer ist (das ist dann der Fall, wenn auch das Stoppbit gesendet wurde) ist das Zeichen im Empfänger angekommen (im fehlerfreien Fall).

SIO empfangen:
Auch hier geht im Prinzip alles automatisch. LV empfängt jedes Zeichen wie es kommt, da kannst du nix gegen macht (naja, fast nix). Die Anzhal der Zeichen im Empfamgspuffer kann man sich sagen lassen, ohne die Zeichen abzuholen.

Zitat:Klappt das hier genauso problemlos?

Zumindest hat das bisher immer problemlos geklappt.
Im Prinzip kommt es auf das Protokoll und den Dateninhalt an. Wenn du 10 Zeichen sendest und 380 erwartest, können die bei 9600 Baud natürlich nicht nach 150ms da sein. Wenn du's ganz genau nimmst, brauchst du hier wie überall bei DÜ ein "Sieben-Schichten-Modell" - was z.B. ein Treiber machen könnten sollte, der vom Hersteller der Gegenseite geliefert werden sollte. Ohne Treiber und selbermachen: Die einfachste Möglichkeit ist, zu warten, bis die erwartete Anzahl Zeichen angekommen ist. Gravierender Nachteil: Was tun, wenn eine Zeichen kaputt geht - und daher fehlt. Besser: Jedes Zeichen gepollt auslesen, sobald es da ist und einen Quasi-Parser drüberlegen. Das klinkt schwieriger als es in den meisten Fällen ist. Gravierender Vorteil: Man kann fehlende Zeichen praktisch festellen - und darauf reagieren.

Hast Du da ein VI, wie ich da pollen kann, oder pollt die VISA-Read-Funktion so lange, bis nichts mehr anliegt?

Gruß Markus

' schrieb:Du fragst hier nach zwei sachen: SIO senden und SIO empfangen.

SIO senden:
LabVIEW weis automatisch, wann alle Zeichen gesendet wurden. Nämlich wenn der Puffer (das ist der String, der dem Write-VI übergeben wurde) quasi leer ist und wenn gleichzeitig das Schieberegister im SIO-Controller (vorausgesetzt echte SIO statt USB-SIO, da wird es aber analoge Mechanismen geben) leer ist. Sobald das Schieberegister leer ist (das ist dann der Fall, wenn auch das Stoppbit gesendet wurde) ist das Zeichen im Empfänger angekommen (im fehlerfreien Fall).

SIO empfangen:
Auch hier geht im Prinzip alles automatisch. LV empfängt jedes Zeichen wie es kommt, da kannst du nix gegen macht (naja, fast nix). Die Anzhal der Zeichen im Empfamgspuffer kann man sich sagen lassen, ohne die Zeichen abzuholen.

Zumindest hat das bisher immer problemlos geklappt.
Im Prinzip kommt es auf das Protokoll und den Dateninhalt an. Wenn du 10 Zeichen sendest und 380 erwartest, können die bei 9600 Baud natürlich nicht nach 150ms da sein. Wenn du's ganz genau nimmst, brauchst du hier wie überall bei DÜ ein "Sieben-Schichten-Modell" - was z.B. ein Treiber machen könnten sollte, der vom Hersteller der Gegenseite geliefert werden sollte. Ohne Treiber und selbermachen: Die einfachste Möglichkeit ist, zu warten, bis die erwartete Anzahl Zeichen angekommen ist. Gravierender Nachteil: Was tun, wenn eine Zeichen kaputt geht - und daher fehlt. Besser: Jedes Zeichen gepollt auslesen, sobald es da ist und einen Quasi-Parser drüberlegen. Das klinkt schwieriger als es in den meisten Fällen ist. Gravierender Vorteil: Man kann fehlende Zeichen praktisch festellen - und darauf reagieren.

Es ist doch so, dass ich einen String in VISA-Write reinschicke und dann einen String aus VISA-Read erhalte. Meine Frage ist eigentlich dann nur diese, ob ich da dann automatisch alle Bytes (unterschiedliche Anzahl je nach Antwort) in diesem String erhalte, oder wenn nicht, wie ich das dann gewährleisten kann.
Das müsste ja eigentlich automatisch gehen, weil in dem Beispiel im Example-Finder gibt es ja den "Bytes at port - Node" und das müsste dann ja auf die gesamte Antwort bezogen sein.

Gruß Markus

' schrieb:Hast Du da ein VI, wie ich da pollen kann, oder pollt die VISA-Read-Funktion so lange, bis nichts mehr anliegt?

Gruß Markus

Es ist doch so, dass ich einen String in VISA-Write reinschicke und dann einen String aus VISA-Read erhalte. Meine Frage ist eigentlich dann nur diese, ob ich da dann automatisch alle Bytes (unterschiedliche Anzahl je nach Antwort) in diesem String erhalte, oder wenn nicht, wie ich das dann gewährleisten kann.
Das müsste ja eigentlich automatisch gehen, weil in dem Beispiel im Example-Finder gibt es ja den "Bytes at port - Node" und das müsste dann ja auf die gesamte Antwort bezogen sein. Habe ich das so richtig verstanden?

Gruß Markus

' schrieb:pollt die VISA-Read-Funktion so lange, bis nichts mehr anliegt?

Leider hab' ich da nichts vorzeigbares.

Pollen geht ganz einfach: VI in Endlos-Whileschleife.

In erster Linie pollt nicht das VISA-VI, sondern die Applikation. Du kannst beim Konfigurieren der Seriellen Schnittstelle angeben einen Timeout, wann das VISA-Read-VI abbrechen soll, obwohl die eigentliche Operation noch nicht beendet ist (wegen des Timeout im VI obliegt das "richtige" Pollen eigentlich der Applikation) . Ich hab' da 10 zu lesende Zeichen eingestellt (weil mein Datensatz 10 Zeichen lang ist) und ein Timeout von 250ms. 10 Zeichen dauern (bei 9600Baud) ca. 10ms. Sollte also das Timeout eintreten - dann ist sowieso irgendwas ganz im Argen. Kommen 10 Zeichen an, kann ich die parsen - dafür hab ich ja ein übergeordnetes Datenformat (in Form eines Frames).

Natürlich muss man nicht zwangläufig pollen. Wenn das System einen Event liefert, wenn 10 Zeichen da sind oder der Timeout eintritt, dann ist das eigentlich schöner.

Anzeige

' schrieb:Es ist doch so, dass ich einen String in VISA-Write reinschicke und dann einen String aus VISA-Read erhalte. Meine Frage ist eigentlich dann nur diese, ob ich da dann automatisch alle Bytes (unterschiedliche Anzahl je nach Antwort) in diesem String erhalte, oder wenn nicht, wie ich das dann gewährleisten kann.
Das müsste ja eigentlich automatisch gehen, weil in dem Beispiel im Example-Finder gibt es ja den "Bytes at port - Node" und das müsste dann ja auf die gesamte Antwort bezogen sein.

Im Prinzip genau so.

Du weist, dass du (z.B.) 5 Zeichen sendest und 15 erwartest. Das macht bei einer Baudrate von 9600Baud eine Mindestzeit von ca. 22ms. Dann geben wir noch LV etwas Zeit und dem Betriebssystem etwas etwas etwas mehr Zeit - also zusammen maximal 75ms. Wenn nach 75ms (wie du die feststellst bleibt dir überlassen) nicht die 15 Zeichen im Eingangspuffer liegen, ist was schlimmes passiert. Ansonsten also abfragen (wie bleibt wieder dir überlassen, ob über den Eigenschaftsknoten oder mit dem Lese-VI) wie viele Zeichen schon da sind. Sind sie dann endlich da - auslesen.

Liest er die Zeichen nicht automatisch aus und gibt sie in dem String von VISA-Read aus? Muss ich zuerst die Anzahl der Bytes abfragen und erst dann auslesen? Weil das Problem ist, dass die zu erwartenden Daten variieren. Oder ist es so, dass wenn ich nur lange genug warte automatisch alle Bytes in den String gelesen werden?

Gruß Markus

' schrieb:Im Prinzip genau so.

Du weist, dass du (z.B.) 5 Zeichen sendest und 15 erwartest. Das macht bei einer Baudrate von 9600Baud eine Mindestzeit von ca. 22ms. Dann geben wir noch LV etwas Zeit und dem Betriebssystem etwas etwas etwas mehr Zeit - also zusammen maximal 75ms. Wenn nach 75ms (wie du die feststellst bleibt dir überlassen) nicht die 15 Zeichen im Eingangspuffer liegen, ist was schlimmes passiert. Ansonsten also abfragen (wie bleibt wieder dir überlassen, ob über den Eigenschaftsknoten oder mit dem Lese-VI) wie viele Zeichen schon da sind. Sind sie dann endlich da - auslesen.

' schrieb:Liest er die Zeichen nicht automatisch aus und gibt sie in dem String von VISA-Read aus?

Was würde bei dir denn "auslesen" bedeuten? Von wo auslesen?
Um das Auslesen aus dem SIO-Controller must du dir überhaupt keine Gedanken machen. Diese Ebene funktioniert ganz von selbst. Normalerweise gibt es einen internen Puffer, in den alles, was kommt, sofort eingelesen wird. Dieser Puffer kann so groß sein wie du will - von mir aus auch 37000 Zeichen. Mit dem VISA-Read liest du diesen Puffer aus. Solange du nicht mit VISA-Read liest, bleiben die Daten in diesem Puffer. Wenn neue über den SIO-Controller reinkommen, kommen die halt auch noch in diesem Puffer. Im Prinzip geht ein VISA-Read auch nicht anders als ein DAQmx-Read.

Zitat:Muss ich zuerst die Anzahl der Bytes abfragen und erst dann auslesen?

Müssen tust du nicht, es ist nur praktisch und einfach, es so zu machen.

Zitat:Weil das Problem ist, dass die zu erwartenden Daten variieren.

Da gibt es zwei Möglichkeiten. Entweder du kennst die variable Anzahl, die als nächstes erwartet wird. Dann legt die halt keine feste Zahl an den entsprechenden VISA-Read-Eingang, sondern eine Variable. Oder die Anzahl der zu empfangenen Zeichen ist unbekannt - dann bleibt dir nichts anderes übrig als zu parsen.

Zitat:Oder ist es so, dass wenn ich nur lange genug warte automatisch alle Bytes in den String gelesen werden?

Im Prinzip genau so. Nach einer Mindestzeit und vor einer Maximalzeit müssen die Daten angekommen sein. Wenn du dann mit dem Wert -1 (für Lesen alles, was da ist, musst du aber verifizieren) liest, liest du eben alle.

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?
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?
Oder gibt es dann einen VISA-Timeout, da nach den paar Bytes, die ich gelesen habe kein weiteres folgt? Oder ist es so, dass LabVIEW, sobald der Controller-Puffer ausgelesen wurde, den Read-Befehl automatisch beendet?

Wenn das mit der Wartezeit nicht funktioniert, 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?

Was genau meinst Du mit Parsen?

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

Auf diesem Gebiet habe ich leider noch gar keine Erfahrung , muss aber in naher Zukunft mit dem "Problem" beginnen. Daher möchte ich mir jetzt die Grundlage schaffen.

Gruß Markus

' schrieb:Was würde bei dir denn "auslesen" bedeuten? Von wo auslesen?
Um das Auslesen aus dem SIO-Controller must du dir überhaupt keine Gedanken machen. Diese Ebene funktioniert ganz von selbst. Normalerweise gibt es einen internen Puffer, in den alles, was kommt, sofort eingelesen wird. Dieser Puffer kann so groß sein wie du will - von mir aus auch 37000 Zeichen. Mit dem VISA-Read liest du diesen Puffer aus. Solange du nicht mit VISA-Read liest, bleiben die Daten in diesem Puffer. Wenn neue über den SIO-Controller reinkommen, kommen die halt auch noch in diesem Puffer. Im Prinzip geht ein VISA-Read auch nicht anders als ein DAQmx-Read.

Müssen tust du nicht, es ist nur praktisch und einfach, es so zu machen.

Da gibt es zwei Möglichkeiten. Entweder du kennst die variable Anzahl, die als nächstes erwartet wird. Dann legt die halt keine feste Zahl an den entsprechenden VISA-Read-Eingang, sondern eine Variable. Oder die Anzahl der zu empfangenen Zeichen ist unbekannt - dann bleibt dir nichts anderes übrig als zu parsen.

Im Prinzip genau so. Nach einer Mindestzeit und vor einer Maximalzeit müssen die Daten angekommen sein. Wenn du dann mit dem Wert -1 (für Lesen alles, was da ist, musst du aber verifizieren) liest, liest du eben alle.