| |
VB.NET - Ein- und UmsteigerRe: Mehrere Befehle über RS232 senden/empfangen | | | Autor: Preisser | Datum: 08.07.12 03:20 |
| Hallo,
Bibobernie schrieb:
Zitat: | |
Private Sub Fügen(ByVal Buffer As String)
Empfang = Empfang + Buffer 'Hier wird der empfangene Text
' zusammengefügt
If Buffer.Contains(Chr(13)) Then
Verarbeitung(Empfang, SerPort) 'Und hier an die Auswertung
' übergeben
Empfang = String.Empty 'Bei sehr kurzen
' Empfangsereignissen kommt es nicht zum löschen der globalen
' Variable. Die Sub beginnt einfach wieder von vorn.
End If
End Sub | |
Hmm, war das Zeichen mit dem Wert 13 nicht das Trennzeichen? Müsste dann nicht eigentlich der String jeweils an der Stelle dieses Zeichens gesplittet werden? Sonst könnte es ja passieren, dass mehrere Nachrichten gleichzeitig im Puffer liegen, oder dass eine Nachricht noch nicht vollständig übertragen wurde und der Rest erst beim nächsten Receive-Ereignis eintritt. (Das Splitten bzw. Lesen bis zum nächsten Vorkommen des Zeichens wird aber ja eigentlich bereits durch die blockierende SerialPort.ReadTo(String)-Methode erledigt, wenn man sie z.B. in einem separaten Thread aufruft... )
Übrigens sollte man eigentlich immer ChrW() statt Chr() verwenden; außer, es ist wirklich notwendig, ein Zeichen nicht durch den Unicode-Wert, sondern den ANSI-Wert des lokal verwendeten Zeichensatzes zu erzeugen.
Zitat: | | Hier habe ich aber scheinbar die Rechnung ohne VB gemacht. Das abarbeitet nämlich erst mal fluffig meinen Code mit den Befehlen ab und verarbeitet das Empfangsevent scheinbar nicht sofort. | |
Naja, wenn eine Kommunikation in zwei Richtungen geht, hat man einen Sende- und einen Empfangskanal, auf denen man meistens parallel senden und empfangen kann.
Wenn du z.B. im GUI-Thread etwas sendest, dann pausierst und wieder etwas sendest, bedeutet das nicht automatisch, zwischen den zwei Sendebefehlen eine Antwort empfangen wird; sondern es wird eben gesendet, und unabhängig davon wird irgendwann später, wenn das Gerät eine Antwort schickt, das Empfangsereignis ausgelöst (bzw. die blockierende Read()-Methode kehrt zurück).
Du könntest also z.B. erst einen Befehl schicken und dann warten, bis eine Antwort durch das Receive-Ereignis kommt. Wenn dies der Fall ist, kannst du die empfangene Antwort auswerten und entsprechend den nächsten Befehl schicken.
Oder, wenn du ein Request/Response-Prinzip verwenden willst, könntest du einen separaten Thread verwenden, der zuerst immer einen Befehl schickt und dann auf eine Antwort wartet, z.B. so in der Art:
Private Sub HandleConnection(sp As SerialPort)
Try
' 1. Befehl senden
sp.Write("ERSTER_BEFEHL" & ChrW(13))
' 1. Antwort auslesen
Dim firstAnswer As String = sp.ReadTo(ChrW(13))
If firstAnswer = "ABC" Then
' 2. Befehl senden
sp.Write("ZWEITER_BEFEHL" & ChrW(13))
' 2. Antwort auslesen
Dim secondAnswer As String = sp.ReadTo(ChrW(13))
End If
' usw.
Catch ex As ThreadInterruptedException '...
End Try
End Sub In dem Fall wird nur 1 Thread (statt 2) sowohl für das Senden als auch das Empfangen verwendet, wenn man erwarten kann, dass nach dem Senden eines Befehls immer eine Antwort erfolgt.
Beitrag wurde zuletzt am 08.07.12 um 03:40:33 editiert. | |
| Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
|
|
sevISDN 1.0
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevPopUp 2.0
Dynamische Kontextmenüs!
Erstellen Sie mit nur wenigen Zeilen Code Kontextmenüs dynamisch zur Laufzeit. Vordefinierte Styles (XP, Office, OfficeXP, Vista oder Windows 8) erleichtern die Anpassung an die eigenen Anwendung... Weitere Infos
|
|
|
Copyright ©2000-2024 vb@rchiv Dieter Otter Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.
Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel
|
|