Com-Server Box-to-Box:

• Konfigurieren Sie den RS485-2-Draht-Modus in beiden Com-Servern über die internen DIP-Switches: 1,2,5 = ON, Rest = OFF. Die Zuschaltung der Terminierung (Schalter 6 und 7) ist abhängig von der vorhandenen RS485-Busstruktur. Ein physikalisches RS485-Segment darf max. zwei Terminierungsnetzwerke enthalten.

• Stellen Sie die Spannungsversorgung und den seriellen Anschluss der Com-Server an den RS485-Bus her, z.B. mit dem RS485-Schraubschnurzel.

  

• Vergeben Sie die IP-Parameter (IP-Adresse, Subnet Mask, Gateway) an beiden Com-Server mit WuTility.

  

• Stellen Sie die seriellen Übertragungsparameter an beiden Com-Servern passend zum RS485-Bus ein - dies ist i.d.R. auf beiden Com-Servern identisch. Das Handshake muss None sein.

  

• Aktivieren Sie die Paketierungsoption Interpacket Delay = 3ms an beiden Com-Servern. Hierdurch wird sichergestellt, dass Modbus-Datagramme geschlossen in einem Netzwerkpaket übertragen werden.

  

• Richten Sie den Box-to-Box-Modus an dem als B2B-Master gewählten Com-Server ein, inkl. der Option Activ. Packet Options.

  

• Aktivieren Sie die Option Activ. Packet Options auch in dem als B2B-Slave arbeitenden Com-Server.

  

• Wichtig: Alle vorgenommenen Einstellungen in den Com-Servern müssen über die Logout-Seite gespeichert werden.

  

Im besten Fall funktioniert nun die Verbindung zwischen dem Modbus-Master und den über die Box-to-Box-Verbindung abgesetzten Modbus-Slaves.

Sowohl im B2B-Master wie auch im B2B-Slave muss im Connection State der Status 'Locked' aufgeführt sein:

"Scanning", "Unlocked" und andere Meldungen weisen auf netzwerkseitige Probleme hin. Beispielsweise ist die jeweilige Gegenseite gar nicht erreichbar oder der TCP-Verbindungsversuch wird abgewiesen. Prüfen Sie:

• Die Einstellungen der B2B-Konfiguration im Master-Com-Server
• Die IP-Basisparameter der Com-Server (IP-Adresse, Subnet Mask, Gateway)
• Die Netzwerkverbindung zwischen den beiden Com-Servern
• Ob Firewalls in der Infrastruktur die Verbindung blockieren

Hier werden vom seriellen Übertragungsbaustein (UART) beim Datenempfang gemeldete Fehler angezeigt (Framing- oder Parity-Error).

Jede serielle Kommunikation wird durch den Modbus-Master initiiert, sodass der Error State zunächst auf dem dort angeschlossenen Com-Server geprüft werden sollte. Löschen Sie zunächst die aktuelle Liste, um alte Fehler zu löschen. Treten anschließend nach manuellen Aktualisierungen der Webseite neue Fehler auf, kommen folgende Ursachen in Betracht:

• Baudrate, Parität oder Anzahl der Datenbits sind am Modbus-Master und Com-Server nicht gleich konfiguriert
• Die Anschlüsse A/B bzw. +/- des RS485-Busses sind vertauscht
• Es gibt keine (oder mehr als zwei) Terminierungen des RS485-Busses

Unabhängig von der Betriebsart werden hier alle von dem jeweiligen Com-Server empfangenen (= Serial Rec) und gesendeten (= Serial Trans) Zeichen gezählt. Die Webseite ist nicht selbstaktualisierend, für die aktuellen Werte muss also manuell neu geladen werden (F5). Einige Beispiele:

1. Alles bestens:

2. Der RTU-Slave sendet keine Response:

Mögliche Ursachen:

• Nicht übereinstimmende Einstellung der seriellen Übertragungsparameter am Com-Server und RTU-Slave
• Vertauschte Bus-Polarität auf Seite des RTU-Slaves
• Kabelbruch, falsche Pinbelegung etc. auf Seite des RTU-Slaves
• Nicht zutreffende Modbus-Adressen in den Requests
• Die Paketierungsoptionen am B2B-Master sind nicht konfiguriert oder aktiviert

3. Alle Counter zählen ordnungsgemäß hoch, der RTU-Master meldet aber trotzdem Timeouts oder Fehler für die hinter dem Netzwerktunnel angeschlossene RTU-Slaves

Mögliche Ursachen:

• Die Paketierungsoptionen am B2B-Slave sind nicht konfiguriert oder aktiviert
• Zu knapp bemessener Response-Timeout am RTU-Master