VISA read/write eventuell zeitgleich

Hallo zusammen,

ich habe von einem Kollegen ein LabVIEW-Programm übernommen und soll es nun erst einmal so gut es geht optimieren. Meine grundsätzliche Erfahrungen in der Programmierung in LabVIEW sind auch eher zwischen Anfänger und Fortgeschrittener einzustufen.

Die Grundstruktur des Programms ist Producer/Consumer. In der Producer-Schleife wird auf den VISA-Port geschrieben und die Consumer-Schleife liest die Antworten des verbundenen Gerätes aus.

Nun zu meiner Frage: Kann es zu einer Race Condition kommen, wenn ich in zwei parallel laufende Schleifen einmal mit "VISA read" die bestehenden Bytes am Port auslese und in der zweiten Schleife Daten mit "VISA write" auf den Port schreibe? Ist das Problematisch? Können dadurch "nur" Verzögerungen entstehen, oder kann es soweit kommen, das Bytes nicht gesendet oder gelesen werden? Grundsätzlich weiß ich: Bloß nicht gleichzeitig auf etwas (egal ob Control, Indicator oder Local Variable) lesen und schreiben, ich würde halt gern wissen, ob das bei Com-Ports genau aussieht. Bisher ist mir leider auch noch keine Möglichkeit eingefallen, dieses Verhalten zu umgehen.

Ich hoffe meine Angaben reichen aus um meine Frage zu beantworten und sind Verständlich dargestellt! Falls das nicht der Fall ist, versuche ich das Problem näher zu erläutern.

Grüße
SM

Anzeige

(15.04.2011 14:24 )sm schrieb:  Nun zu meiner Frage: Kann es zu einer Race Condition kommen, wenn ich in zwei parallel laufende Schleifen einmal mit "VISA read" die bestehenden Bytes am Port auslese und in der zweiten Schleife Daten mit "VISA write" auf den Port schreibe? Ist das Problematisch?

Mit Blick auf RaceConditions gibt es keine Probleme (solange die Schnittstelle selbst eine bidirektionale ist wie z.B. eine RS232).

Zitat:Können dadurch "nur" Verzögerungen entstehen

Genau.
Wenn zwei eigentlich unabhängig gedachte Prozesse auf das selbe (VISA-)Modul zugreifen - dann kann es natürlich zu diesen Verzögerungen können. Die Prozesse sind dann eben nicht ganz unabhängig. Außerdem: Welcher der beiden Prozesse z.B. ist berechtigt, das (VISA-)Modul zu konfigurieren? Aus solchen Überlegungen heraus ist davon abzuraten, von zwei parallelen Prozesses aus auf ein und das selbe (VISA-)Modul zuzugreifen. Lieber ein eigenes Schnittstellenmodul machen, das die VISA-Schnittstelle vom Rest den Programms entkoppelt(!).

Zitat:oder kann es soweit kommen, das Bytes nicht gesendet oder gelesen werden?

Das kann nicht sein.
Lesen und Schreiben sind zwei unabhängige Kanäle, für die es im VISA-Modul jeweils einen eigenen Puffer gibt. Daher wird es nicht zu einem Verlust in einem der Kanäle kommen.
Außer:
Einer der beiden Prozesse konfiguriert gerade das VISA-Modul um, während der andere schreiben will. Dann geht selbstverständlich was verloren. Wenn man solche Umstände aber kennt und entsprechend behandelt, kann man natürlich auch mit parallelen Prozessen ...

Zitat:Grundsätzlich weiß ich: Bloß nicht gleichzeitig auf etwas (egal ob Control, Indicator oder Local Variable) lesen und schreiben

Du meinst wohl das richtige.
"Gleichzeitig lesen und schreiben" geht grundsätzlich immer. Das kann auch so gewollt sein. "Gleichzeitig zweimal schreiben" - da gibt es grundsätzliche Probleme. Einer der beiden Schreibvorgänge könnte umsonst sein - aber welcher? Bei zweimal Schreiben kann im schlimmsten Falle sogar was kaputt gehen.

IchSelbst hat ja schon geantwortet, hier nur noch etwas zusätzliche Information dazu:
Ja, es geht uneingeschränkt, und Race-Condition ist kein Problem.
Ein allgemeines Problem bei serieller Kommunikation ist eher die Synschronisation von Sendeinformation und empfangener Information. Da man auf LV-Seite in der Regel einen Empfangspuffer hat, kann man nicht von vornherein sicher sein, daß es sich beim Lesen um die Antwort des letzten gesendeten Befehls handelt, oder nicht vielleicht um eine alte Nachricht, sie sich außerdem noch im Empfangspuffer befindet.
Gerade umgekehrt ist es beim Senden, worauf ebenfalls IchSelbst schon hinwies:
Es ist eher unüblich, daß die Gegenstelle über einen nennenswert großen Empfangspuffer verfügt. Deshalb nach jedem gesendete Befehl besser die Quittung abwarten, bevor wieder gesendet wird.
Und wenn man das alles beachtet, dann läuft es letztlich darauf hinaus, daß Senden und Empfangen doch nicht gleichzeitig stattfindet..

Hallo,

vielen Dank erst einmal für eure hilfreichen Antworten!

Ok, dann weiß ich bescheid. Ja, es handelt sich um eine RS232-Schnittstelle. Konfiguriert wird die Schnittstelle nur einmal ganz am Anfang. In dieser Hinsicht dürfte also nichts weiter passieren.

Das Problem mit der nicht synchronität der Sende- und Empfangsinformation, dass Lucki anspricht, ist, fürchte ich, genau das, was in meinem Programm die Probleme bereitet. Da müsste ich mir dann etwas neues überlegen, wie ich das realisieren kann. Bisher habe ich da keine Idee. ;(

Grundsätzlich ist der Aufbau des Programms folgerndermaßen: Es gibt drei parallel laufende While-Schleifen. In der ersten ist eine Event-Struktur die reagiert, wenn auf dem FP eine Eingabe erfolgt. Die zweite Schleife erstellt die Sendebefehle und schreibt anschließend auf die RS232-Schnittstelle. Die dritte While-Schleife liest die Bytes auf der Schnittstelle und übersetzt die ankommenden Hex-Befehle in ASCII. Innerhalb dieser dritten Schleife ist noch eine Case-Struktur, die für jeden einzelnen (bisher implementierten) Empfangsbefehl einen Case hat und dementsprechend antwortet. Die verschiedenen Schleifen sind über eine Queue verbunden. In diese Queue werden dann die Sendebefehle hineingeschrieben und in der zweiten Schleife wieder entqueued.

Grüße
SM

Du hast zwar keine Frage gestellt, aber hier noch ein kleiner Tip:
Die stabilste Kommunikation hat man mit aktivierten Abschlußzeichen bei Senden unf Empfangen.
Wenn z.B eine empfangene Nachricht 5 byte lang ist, und man empfängt Nachrichten der Länge 5 byte, ohne das Abschlußzeichens aktiviert zu haben, dann ist es möglich, daß es in Wirklichkeit 3 Byte der letzten Nachricht und 2 byte der neuen Nachricht sind. Bei Empfang mit aktiviertem Anschlußzeichen kann so etwas nicht passieren.

Das mache ich bereits! Der Termination-Char ist aktiviert und auch definiert.

Anzeige

(18.04.2011 06:43 )sm schrieb:  Grundsätzlich ist der Aufbau des Programms folgerndermaßen: Es gibt drei parallel laufende While-Schleifen. In der ersten ist eine Event-Struktur die reagiert, wenn auf dem FP eine Eingabe erfolgt. Die zweite Schleife erstellt die Sendebefehle und schreibt anschließend auf die RS232-Schnittstelle. Die dritte While-Schleife liest die Bytes auf der Schnittstelle und übersetzt die ankommenden Hex-Befehle in ASCII. Innerhalb dieser dritten Schleife ist noch eine Case-Struktur, die für jeden einzelnen (bisher implementierten) Empfangsbefehl einen Case hat und dementsprechend antwortet.

Ich würde das so machen:

Eine While-Schleife mit Event-Struktur. Die reagiert auf Benutzereingaben und sendet Befehle (per Queue) an eine zweite While-Schleife. Darin befindet sich eine Statemachine. Die Statemachine macht den eigentlichen strukturierten Ablauf: Warten auf Arbeit, Senden per RS232 an Endgerät, Warten auf Antwort mit eingebautem Timeout, Auswerten und Verarbeiten der Antwort.

Zitat:Eine While-Schleife mit Event-Struktur. Die reagiert auf Benutzereingaben und sendet Befehle (per Queue) an eine zweite While-Schleife. Darin befindet sich eine Statemachine. Die Statemachine macht den eigentlichen strukturierten Ablauf: Warten auf Arbeit, Senden per RS232 an Endgerät, Warten auf Antwort mit eingebautem Timeout, Auswerten und Verarbeiten der Antwort.

Das hört sich sinnvoll an! Würde auf jeden Fall mein Ursprungs-Problem umgehen. Die erste von dir beschriebene Schleife ist bereits genau so umgesetzt. Habe nur keine Idee, wie ich die zweite While-Schleife realisieren sollte, wie du sie beschrieben hast. Kannst du mir eventuell, wenn es nicht zuviele Umstände macht, ein kleines Beispiel hierfür reinstellen? Das würde mir sehr helfen!

Vielen dank nochmal für eure Hilfe.