TIA ET200SP als Modbus RTU Master mit CM PtP Kommunikationsmodul

[ZailerGTH]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der HW-Konfig kann man auch noch einiges zum Modbus-RTU-Master konfigurieren...

Ja stimmt, aber wenn man den Comm_Load FB nutzt, dann wird die HW-Config überschrieben. Dann muss man alle Einstellungen im Instanz-DB anpassen.

 

[WhyyGee]

Hallo zusammen,

ich hatte ähnliche Probleme bei der Kommunikation zwischen ET 200SP als Master und einem Sensor (Halbduplex (RS485) Zweidraht-Betrieb).
Obwohl Hardwareaufbau und Einstellungen korrekt waren, kam keine Kommunikation zustande.

Die Lösung war der "Compatibility_Mode" des Modbus Masters. Der dient dazu "Abweichungen im Protokollverhalten auszugleichen" (für ältere / Drittanbieter-Hardware).
Ich denke, der von mir verwendete Sensor verwendet ein nicht ganz normgerechtes Protokoll, was zum Kommunikationsabbruch geführt hat.

Dank Kompatibilitätsmodus funktioniert die Kommunikation stabil.

 

[sebi2110]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich hatte ähnliche Probleme bei der Kommunikation zwischen ET 200SP als Master und einem Sensor (Halbduplex (RS485) Zweidraht-Betrieb).
Obwohl Hardwareaufbau und Einstellungen korrekt waren, kam keine Kommunikation zustande.

Die Lösung war der "Compatibility_Mode" des Modbus Masters. Der dient dazu "Abweichungen im Protokollverhalten auszugleichen" (für ältere / Drittanbieter-Hardware).
Ich denke, der von mir verwendete Sensor verwendet ein nicht ganz normgerechtes Protokoll, was zum Kommunikationsabbruch geführt hat.

Dank Kompatibilitätsmodus funktioniert die Kommunikation stabil.

Hi,
ich habe das gleiche Problemem mit der Kommunikation zwischen einer ET200SP (CPU 1512SP-1PN) sowie einerm CM PtP und einem Janitza UMG 96 RM.

Der ModbusMaster Baustein scheint die Anfrage zu senden. Jedoch meldet der Baustein den Error 16#80C8 (
Der Slave antwortet nicht innerhalb der eingestellten Zeit).

Der "Compatibility_Mode" hat bei mir leider nicht geholfen.

Habt Ihr noch ideen wo und was ich schauen könnte?

Danke und viele Grüße

 

[vollmi]

Hi,
ich habe das gleiche Problemem mit der Kommunikation zwischen einer ET200SP (CPU 1512SP-1PN) sowie einerm CM PtP und einem Janitza UMG 96 RM.

Der ModbusMaster Baustein scheint die Anfrage zu senden. Jedoch meldet der Baustein den Error 16#80C8 (
Der Slave antwortet nicht innerhalb der eingestellten Zeit).

Antwortet denn der Slave?

 

[PN/DP]

RS-485 Verdrahtung und Abschlußwiderstände prüfen (siehe die Handbücher des UMG 96 RM und CM PtP)
testweise mal Draht A und B tauschen am CM:12 und CM:14
Ist der CM PtP auf RS-485 konfiguriert?

 

[sebi2110]

Zuviel Werbung?
-> Hier kostenlos registrieren

Antwortet denn der Slave?

Auf der CM PtP Karte wird etwa gesendet. Das sehe ich jedenfalls durch das aufläuchten der "TX" LED auf der Karte.
Eine Antwort bekomme ich wohl nicht, die "RX" LED bleibt aus.

RS-485 Verdrahtung und Abschlußwiderstände prüfen (siehe die Handbücher des UMG 96 RM und CM PtP)
testweise mal Draht A und B tauschen am CM:12 und CM:14
Ist der CM PtP auf RS-485 konfiguriert?

RS-485 Verdrahtung habe ich geprüft und sogar "A und B" getauscht, so wie in den vorherigen Beiträge schon angesprochen wurde.

Habe auf beiden Seiten ein 330 Ohm Abschlußwiderstand.

Der CM PtP ist wie im Bild konfiguriert

 

[vollmi]

Auf der CM PtP Karte wird etwa gesendet. Das sehe ich jedenfalls durch das aufläuchten der "TX" LED auf der Karte.
Eine Antwort bekomme ich wohl nicht, die "RX" LED bleibt aus.


RS-485 Verdrahtung habe ich geprüft und sogar "A und B" getauscht, so wie in den vorherigen Beiträge schon angesprochen wurde.

Habe auf beiden Seiten ein 330 Ohm Abschlußwiderstand.

Der CM PtP ist wie im Bild konfiguriert

Die Konfiguration kommt bei Modbus RTU komplett aus dem ComLoad Baustein. Die Konfiguration der Hardware wird ignoriert.
Was für ein Telegramm siehst du denn wenn du auf dem Buskabel mitliest z.B. mit Realterm

ComLoad ist essentiell, da hat es konfiguration im STAT bereich des Bausteins, das sieht man an der Schnittstelle des Aufrufs nicht, muss aber korrekt sein. Das ist so eine Heldentat der Siemens leute.

 

[sebi2110]

Die Konfiguration kommt bei Modbus RTU komplett aus dem ComLoad Baustein. Die Konfiguration der Hardware wird ignoriert.
Was für ein Telegramm siehst du denn wenn du auf dem Buskabel mitliest z.B. mit Realterm

ComLoad ist essentiell, da hat es konfiguration im STAT bereich des Bausteins, das sieht man an der Schnittstelle des Aufrufs nicht, muss aber korrekt sein. Das ist so eine Heldentat der Siemens leute.

Ok, verstehe. Dann ist es wichtig den ComLoad Baustein richtig zu Konfigurieren.

Ich habe mich dazu an das Beispiel von Siemens ( 47756141_TIA_Portal_S7-1200_Modbus-RTU_V16.zip (2,6 MB) für TIA Portal V16) orientiert: https://support.industry.siemens.com/cs/de/de/view/47756141

In meinem Programm TIA V19, habe ich allerdings das Senden von Daten an den Modbus Slave weggelassen, da ich dies nicht benötige.

Das Telegramm mitlesen habe ich noch nie versucht, das wäre für mich neu. Hab da noch keine Erfahrung wie ich da am besten vorgehe.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

In deinem PDF sieht man nicht wie Mode belegt ist, keine Stopbits, keine Vorbelegung etc. das ist alles im STAT und das muss richtig eingestellt sein.

entweder indem du das in der Instanz als Startwert einträgst oder im Programm in den Statbereich schreibst bevor du den ComLoad aktivierst.

 

[PN/DP]

Wie sind die Modbus-Parameter im UMG96 eingestellt?
Standard:
Parameter 0 = 1 // Geräteadresse -----> Modbus_Master.MB_ADDR
Parameter 1 = 4 // Baudrate 4=115.2kbps
Parameter 3 = 0 // 0=1 Stoppbit

Im Instanz-DB von Modbus_Comm_Load ist MODE = 4 eingestellt (4 = Halbduplex RS485 Zweidraht-Betrieb)?

Bei Aufruf von Modbus_Master wird an MB_ADDR die eingestellte Geräteadresse angegeben?

 

[sebi2110]

In deinem PDF sieht man nicht wie Mode belegt ist, keine Stopbits, keine Vorbelegung etc. das ist alles im STAT und das muss richtig eingestellt sein.

entweder indem du das in der Instanz als Startwert einträgst oder im Programm in den Statbereich schreibst bevor du den ComLoad aktivierst.

Ok, jetzt bekomme ich eine Antwort. Die "RX" LED läuchtet nun auf.

Allerdings bekomme ich von dem Baustein "Modbus_Master" noch den Error 16#81E2.
Wenn ich das richtig verstanden habe, sagt mir dieser nun das irgend was mit dem Mode, Stopbits etc. nicht passt.

Im UMG96 sind die Einstellungen korrekt, diese habe ich gepüft.

Wie sind die Modbus-Parameter im UMG96 eingestellt?
Standard:
Parameter 0 = 1 // Geräteadresse -----> Modbus_Master.MB_ADDR
Parameter 1 = 4 // Baudrate 4=115.2kbps
Parameter 3 = 0 // 0=1 Stoppbit

Im Instanz-DB von Modbus_Comm_Load ist MODE = 4 eingestellt (4 = Halbduplex RS485 Zweidraht-Betrieb)?

Bei Aufruf von Modbus_Master wird an MB_ADDR die eingestellte Geräteadresse angegeben?

In der Insanz des ModbusCommLoad habe ich nun folgende Startwerte unter Static eingeragen:

MODE = 4

Alles andere habe ich erstmal belassen, da es so passen sollte.

Mit dem ändern auf MODE = 4, habe ich auch das aufläuchten der "RX" erreicht.

Seht ihr eventuell noch einen weiteren Fehler?

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, jetzt bekomme ich eine Antwort. Die "RX" LED läuchtet nun auf.

Da wir nicht wissen können wie du die Schnittstelle des Janiza eingestellt hast, können wir dir auch deine Fehler nicht sagen.
Da du aber ein RX bekommst, scheinst du zumindest nahe drann zu sein. Ich würde jetzt mal im Treiber auf 2 Stoppbits wechseln (Comload nochmal anstossen). Ausserdem die Vorbelegung der Empfangsleitung auf 2 setzen. Da du wie ich vermute kein aktives Abschlussterminal einsetzt.

ich rate dir den ComLoad intelligent anzusteuern, z.B. alle 10 misslungenen Kommunikationsversuche, Comload neu anstossen. Damit lädst du die Parameter neu falls sie verloren gehen z.B. durch stecken ziehen des PTP oder Ausfall des Rios.
Die Fehlersuche wäre einfacher wenn du mit einem Modbustester den Janiza mal ausliesst, damit stellst du sicher dass die Parameter passen und dann mal mit dem Bus mitliesst, damit stellst du sicher dass die Parameter des Masters auch passen.

 

[PN/DP]

Allerdings bekomme ich von dem Baustein "Modbus_Master" noch den Error 16#81E2.

Inet-Suche nach "Modbus_Master 81E2" liefert einige Fundstellen, die erste ist eine Siemens FAQ:
Was verursacht den Status 16#8280, 16#8281, 16#81E2 an den Bausteinen Modbus_Master, Modbus_Slave, Receive_P2P?

Zusätzliche Punkte speziell bei Modbus RTU:

4. Um mit dem Baustein Modbus_Master/Modbus_Slave zu kommunizieren, muss zuerst der Baustein Modbus_Comm_Load erfolgreich ausgeführt worden sein, um das CM PtP für Modbus zu parametrieren. Wir empfehlen die Bausteine Modbus_Master/Modbus_Slave so lange nicht aufzurufen, bis der Baustein Modbus_Comm_Load erfolgreich durchlaufen wurde (DONE = 1).

5. Nach jedem Neustart des Cm PtP muss der Baustein Modbus_Comm_Load aufgerufen werden (z.B. nach Stationsausfall).


Hintergrundinformation zum Status = 16#81E2:

Die Beschreibung für den STATUS = 16 # 81E2 lautet "Telegramm abgebrochen: Zeichenrahmenfehler"

Der Status 16#81E2 sagt grundsätzlich aus, dass das CM PtP zwar Signale auf der Leitung erkennt, diese aber nicht auswerten kann. Das kann wie in der Bausteinhilfe beschrieben, an einer nicht übereinstimmenden Einstellung der Baudrate, Anzahl der StopBits, der Parität oder der StartBits liegen.


Mögliche Ursachen für den Status 16#81E2:

1. Zuerst sind die Einstellungen für Startbit, Datenbits, Paritätsbit, Stopbit(s) und die Baudrate zu prüfen. Diese müssen bei allen Kommunikationspartnern identisch sein.

2. Vertauschte Leitungen oder die falsche (keine oder doppelte) Vorbelegung der Leitungen (Spannungspegel R(A) = 0V, R(B) = 5V) können zu einem fehlerhaften Signalpegel auf den Leitungen führen, was in der Folge dann auch zum STATUS = 16#81E2 führen kann.

Serielle Kommunikation (Modbus RTU oder Freeport) wird oft für Kommunikation zu Geräten von Frendherstellern verwendet. Leider ist die Dokumentation von Fremdherstellern oft nicht eindeutig. Daher empfehlen wir durch strukturiertes Testen möglicher Optionen, die korrekte Verdrahtung und die korrekte Vorbelegung der Leitungen herauszufinden. Am Beispiel von RS485 kommen folgende vier Testoptionen in Frage:
1. Verdrahtung A > A, B > B ohne Vorbelegung der Empfangsleitung (bei Modbus RTU: LINE_PRE = 0)
2. Verdrahtung A > A, B > B mit Vorbelegung der Empfangsleitung (bei Modbus RTU: LINE_PRE = 2)
3. Verdrahtung A > B, B > A ohne Vorbelegung der Empfangsleitung (bei Modbus RTU: LINE_PRE = 0)
4. Verdrahtung A > B, B > A mit Vorbelegung der Empfangsleitung (bei Modbus RTU: LINE_PRE = 2)

 

[PN/DP]

Was verursacht den Status 16#8280, 16#8281, 16#81E2 an den Bausteinen Modbus_Master, Modbus_Slave, Receive_P2P?

Leider ist die Dokumentation von Fremdherstellern oft nicht eindeutig.

Nunja, die Konfusion liegt allerdings eher an Siemens als an den Fremdherstellern.
Die meisten Fremdhersteller bezeichnen die RS485-Signalleitungen durchaus sehr eindeutig. Nur Siemens bezeichnet die anders - das ist historisch durch die Entwicklung von PROFIBUS bedingt und wird nicht mehr geändert/korrigiert.

EIA-485 – Wikipedia

de.wikipedia.org

Die nicht invertierte Leitung wird meist mit A oder + oder ..P (positiv) gekennzeichnet, die invertierte mit B, − oder ..N. Bei zwei Busleitungen wäre das z. B. + und − oder RXTX-P und RXTX-N

Das entspricht den Signalbezeichnungen A und B an den RS485-Treiber-IC (z.B. TI SNx5176B)
TI: Polarity Conventions for RS-485 Transceiver (pdf)
RS485 elektrische Details: TI Application Report - RS-422 and RS-485 Standards Overview and System Configurations (pdf)

Im Gegensatz dazu die Bezeichnungen bei PROFIBUS, die Siemens auch für alle anderen Siemens-RS485-Schnittstellen verwendet:
https://www.felser.ch/profibus-handbuch/technik.html

Die zwei Leiter in der Zweidrahtleitung tragen die Signale "Daten Leiter Plus" (B-Leiter) und "Daten Leiter Minus" (A-Leiter).