Ich habe gerade mehrere Stunden mit einer Problemsuche zugebracht, die am Ende ganz einfach zu lösen war.
Folgende Situation:
Der Kunde hatte eine Xinje XL SPS
Xinje XL5
Er wollte über Modbus RTU auf die Kinco KS123-14DR zugreifen, einem Erweiterungsmodul mit Eingängen und Relaisausgängen:
KS123-14DR
Folgendes hat er dazu getan:
- Mit dem Kinco Modbus-Tool die Stationsnummer der Erweiterung auf 2 geändert
- In der Xinje SPS-Software XDPPro die COM2-Schnittstelle (RS-485 als A/B-Klemme) als Modbus RTU konfiguriert, mit der richtigen Baudrate von 38400 (Standard in der Kinco-Erweiterung)
- Die beiden COM-Schnittstellen der SPS und der Erweiterung durch eine verdrillte Zweidrahtleitung verbunden
- In der Xinje Software über die Befehle COLW K2 K0 M0 K2 den Zustand von Merker M0 an den Ausgang Q0.0 der Erweiterung übertragen
- In der Xinje Software über den Befehl INPR K2 K0 K8 M10 K2 die Zustände der 8 Eingänge ab K0 (= I0.0) in den Merkerbereich ab M10 (bis M17) übertragen
Das Schreiben des Ausgangs funktionierte auf Anhieb, aber das Einlesen der Eingänge schlug fehl. In SD160 sieht man den Fehlerstatus für Modbus an COM2 der SPS, dort tauchte 101 als Timeout auf.
Ich konnte das Problem sofort nachstellen, auch bei mir hat es nicht funktioniert.
Ich habe dann folgendes probiert:
- Die Erweiterung über einen RS-485-Adapter an meinen PC angeschlossen und mit Kinco DTools in der direkten Online-Simulation die Eingänge 1x 1 bis 8 abgefragt. Das hat sofort funktioniert!
- Die Kommunikation mit dem Free Serial Analyzer aufgezeichnet und die funktionierende Leseanfrage geprüft: 02 02 00 00 00 08 79 FF (sendet der Modbus Master mit Function Code 2)
- Die Xinje SPS angeschlossen, auch hier wurde richtig 02 02 00 00 00 08 79 FF gesendet, nur kam keine Antwort von der Erweiterung
- Die Erweiterung am PC angeschlossen und mit dem Serial Analyzer 02 02 00 00 00 08 79 FF an die Erweiterung geschickt, die hat prompt geantwortet
- Die Xinje SPS auf freie serielle Kommunikation eingestellt und mit SEND den Modbus-Befehl selber geschickt und mit RCV am Port gelauscht, was zurückkommt: NICHTS
Kurioserweise funktionierte das Setzen der COILs, nur die Antwort auf die Leseanfrage funktionierte nicht.
Die Lösung war am Ende denkbar trivial, hat mich aber extrem viel Zeit gekostet:
- In der Erweiterung ist im Standard die Paritätsprüfung ausgestellt = NONE
- In der Xinje SPS war die Paritätsprüfung auf EVEN
Die Erweiterung konnte mit dem EVEN-Protokoll trotzdem umgehen und hat richtig geschaltet, aber die Xinje hat die Antwort ohne passendes Paritätsbit als fehlerhaft verworfen. Als ich in der seriellen Schnittstelle der SPS das Prüfbit (Parität) auf None gesetzt, die Konfiguration in die SPS geschrieben und die SPS neu gestartet habe, funktionierte die Kommunikation plötzlich auf Anhieb.
Und die Moral von der Geschicht:
Prüfe die Verbindungseinstellungen der seriellen Verbindung aller Teilnehmer genau, vor allem die Paritätsprüfung kann zu kuriosen einseitigen Effekten führen!
Wer sich schlaumachen möchte und verstehen will, wie die Paritätsprüfung genau funktioniert, der liest hier nach:
Paritätsbit in Wikipedia
Es wird hier einfach für jedes Byte ein zusätzliches 9. Bit geschickt, um den Inhalt des Bytes zu prüfen. Kurios ist, dass die Kinco Erweiterung bei abgestellter Paritätsprüfung offensichtlich Modbus-Nachrichten mit Paritätsbit trotzdem richtig interpretiert, aber selbst kein Paritätsbit mitschickt. Damit hat die Xinje SPS die Antwort als fehlerhaft verworfen.
