Gemeinsame Nutzung serieller Geräte über ein Netzwerk

Ja, wenn der gemeinsam genutzte Port eine Serververbindung im Raw-Modus ist, erlaubt er mehrere Clients, und jeder verbundene Client erhält eine Kopie der Ausgabe des Geräts. Das ist ideal für ein Gerät, das Daten an viele Empfänger ausgibt (einen GPS-Empfänger, einen Sensor-Datenstrom). Beachten Sie, dass der Modus Telnet (RFC 2217) Peer-to-Peer ist — jeweils nur ein Client —, weil die portspezifische Steuerung pro Sitzung nicht gemeinsam genutzt werden kann; daher bedeutet die gemeinsame Nutzung durch mehrere Clients den Raw-Modus und den Verzicht auf die Remote-Aushandlung von Baudrate/Signalen.

Eine wichtige Einschränkung: Viele Computer können sicher von einem Gerät lesen, aber viele Computer, die Befehle an ein Gerät schreiben, sind unsicher. Eine serielle Leitung hat keine Multi-Master-Arbitrierung, daher werden sich überschneidende Befehle von verschiedenen Clients zu beschädigten Bytes auf dem einen physischen Port vermischt. Verteilung an viele Leser, ja; unkontrollierte mehrere Schreiber, nein — koordinieren Sie Befehle über einen steuernden Client, wenn das Gerät nach dem Prinzip Befehl/Antwort arbeitet.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Nein — und es ist wichtig, das klarzustellen, weil das eine häufige Annahme ist. SEC ist ein transparenter Byte-Weiterleiter, kein Protokollkonverter. Bytes, die in den seriellen Port eingehen, kommen am virtuellen Port unverändert heraus; Modbus RTU bleibt Modbus RTU. Ihre Anwendung am anderen Ende spricht weiterhin exakt dasselbe serielle Protokoll wie das Gerät — SEC transportiert diese Kommunikation lediglich über das Netzwerk.

Wenn Sie tatsächlich RTU-Frames in Modbus TCP umverpackt benötigen (anderes Framing, keine CRC, ein korrekter TCP-Transaktionsheader), dann ist das eine Protokollübersetzung, und stattdessen benötigen Sie ein dediziertes Modbus-Gateway. SEC passt, wenn beide Enden bereits dasselbe serielle Protokoll sprechen und Sie es nur über ein Netzwerk übertragen müssen. „Das Gerät remote erreichen“ ist unsere Aufgabe; „ändern, was das Gerät spricht“ nicht.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Die Softwareschicht selbst fügt nur wenig hinzu — unter normalen lokalen Bedingungen im Allgemeinen einen kleinen Overhead von unter 10 ms. Aber wir nennen keine einzelne universelle Zahl, denn der entscheidende Wert wird von Ihrem Netzwerk bestimmt, nicht vom SEC: In einem LAN ist die insgesamt hinzugefügte Latenz minimal; über das Internet oder ein VPN sind die Netzwerk-Round-Trips die eigentlichen Kosten, und sie können je nach Entfernung und Auslastung von wenigen Millisekunden bis zu Hunderten reichen.

Die Bandbreite ist praktisch nie der Engpass — serielle Datenraten sind im Vergleich zu jedem modernen Netzwerk winzig. Die Latenz ist der Faktor, für den man auslegen muss. Wenn Ihr Protokoll sie toleriert (Streaming, lockeres Polling), werden Sie sie nie bemerken. Wenn es enge Antwortzeitfenster erzwingt, messen Sie den tatsächlichen Round-Trip auf Ihrem realen Pfad, bevor Sie sich festlegen, und denken Sie daran, dass die Pufferungssteuerungen von SEC bei Bedarf etwas zusätzliche Latenz gegen saubereres Framing eintauschen.

Beantwortet von Bohdan Miniv · QA Engineering

Ja. Die Verbindungseinstellungen von SEC enthalten genau dafür Paketisierungssteuerungen, einschließlich einer Option „Daten senden, wenn ein Zeichen mit einem bestimmten Code empfangen wird“. Stellen Sie sie auf das End-of-Message-Byte Ihres Protokolls ein (zum Beispiel ein Wagenrücklauf oder Zeilenvorschub bei zeilenorientiertem ASCII), und SEC sammelt eingehende Bytes und überträgt sie als eine Einheit an das Netzwerk, wenn dieses Trennzeichen eintrifft, anstatt Bytes stückweise weiterzuleiten.

Das ist wirklich nützlich, um die Nachrichtenrahmung über ein Netzwerk hinweg intakt zu halten, das einen Bytestrom sonst aufteilen oder zusammenfassen würde, und es lässt sich mit den zugehörigen Steuerungen kombinieren — für eine festgelegte Zeit zurückhalten oder senden, sobald ein Block eine bestimmte Größe erreicht. Der Kompromiss, den Sie im Hinterkopf behalten sollten: Jede „Warte bis …“-Regel fügt absichtlich eine kleine Latenz hinzu, da Sie Bytes bewusst zurückhalten, bis der Auslöser eintritt. Für die meisten gerahmten Protokolle ist das genau das gewünschte Verhalten.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler

Die Mindestanforderung ist einfach: Installieren Sie SEC auf dem Rechner, der über den seriellen Port verfügt, den Sie freigeben möchten. Diese Seite veröffentlicht den Port über das Netzwerk, und das andere Ende kann damit wie mit einer gewöhnlichen Netzwerkverbindung kommunizieren — wenn Ihre Remote-Anwendung selbst einen rohen TCP-Socket öffnen kann, verbindet sie sich direkt und benötigt kein installiertes SEC. Dieses entfernte Ende könnte sogar ein Hardware-Gerät sein (ein Terminal- oder Konsolenserver), das das Protokoll bereits über das Netzwerk spricht.

Sie benötigen SEC nur dann an beiden Enden, wenn beide Enden ihrer lokalen Software einen echten COM-Port bereitstellen müssen. In diesem Fall führt jeder Knoten SEC aus, um den Port lokal verfügbar zu machen, und SEC überträgt die Daten zwischen ihnen. Einfach ausgedrückt: Installieren Sie SEC auf jedem Knoten, auf dem eine Anwendung erwartet, einen COM-Port zu sehen, und verzichten Sie darauf, wo die Software bereits direkt TCP spricht — oder wo der Endpunkt Hardware ist.

Beantwortet von Nikolai Svarachevsky · Leitender Entwickler