TIA Sensor Anschluss über CB 1241 RS485

[ban-al]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Morgen,


vielleicht hat jemand von Euch noch eine zündende Idee für mein Problem.
Ich versuche einen Sensor über RS485 über eine S/-1200 auszulesen. Über einen Serial / USB Converter und die Software Realterm "Serial Capture Programm" kann ich mir die Kommunikation der Geräte ansehen.


Nun ist es so, dass ich sehe, wie die S7 den korrekten Code zum Ansprechen des Sensors sendet.

Bild 1

Der Sensor antwortet allerdings nie.
Ziehe ich die S7 vom Bus ab, kann ich (mit dem Code, den vorher die S7 gesendet hat) über Realterm den Sensor ansprechen und der antwortet auch korrekt.


Bild 2

Ebenso kann ich den Antwort-Code des Sensors mit Realterm an die S7 senden, wo er auch ankommt.


Bild 3 und Bild 4


Auch wenn nur die S7 und der Sensor im Bus sind, kommt keine Antwort.


Ich benutze folgende Siemens Hardware:
S7 1200 CPU 1212C AC/DC/Rly mit CB 1241 RS485
Programmiert habe ich mit TIA V15.1
Die verwendeten Bausteine sind auf den Bildern 4 und 5 zu sehen. Ich habe sowohl Modbus-Comm_Load und -Master als auch MB_Comm_Load und Master ausprobiert. Beides bringt die gleichen Ergebnisse.


Bild 5 und 6



Bin für jeden Hinweis extrem dankbar!

Beste Grüße
Al

 

[Thomas_v2.1]

Welche Betriebsart Halbduplex/Vollduplex unterstützt denn das Gerät?
Wie kürzlich aus einem Thread hier hervorging, unterstützt das CB nur Halbduplexbetrieb.
Oder hast du bei denen Versuchen mit dem eigenen Adapter immer nur Halbduplex verwendet?

 

[ban-al]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
das Gerät unterstützt Halbduplex, sollte also kein Problem darstellen.
Besten Gruß

 

[Heinileini]

Passt denn die Verdrahtung?
Sender auf der einen Seite mit Empfänger auf der anderen verbunden und umgekehrt?

 

[ban-al]

Ja, danke, die Verdrahtung passt.

 

[corrado]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bild 3 erste Zeile nach dem grünen Block kommt die Sequenz: "01 83 03 01 31" bevor wieder das Abfrage-Telegram kommt.
Diese Sequenz ist doch die Antwort und wenn du sie auswertest steht darin: 01=Slave-Adresse, 83=Fehler bei Funktionscode 3, 03=Exeption-Code ILLEGAL DATA VALUE (Zitat aus Modicon Modbus Protocol Reference Guide: A value contained in the query data field is not an allowable value for the slave), 01 31 = CRC.

prüfe doch mal die Startadresse und die Blocklänge des auszulesenden Datenblocks. Sehe ich es richtig, dass du 2 Worte auf einer ungeraden Adresse lesen willst?

Gruss Corrado

 

[ban-al]

Hallo Corrado,

danke für den Hinweis! Auf Bild 3 ist ja sozusagen die "simulierte" Antwort des Sensors an die S7 dargestellt. Nachdem in den DB der S7 (plausible) Werte geschrieben wurden, habe ich auf die Antwort der S7 gar nicht mehr geachtet. Ich schaue mir das noch einmal genau an.
Zu Deiner Schlussfrage. Ja, genau 2 Worte auf einer ungeraden Adresse. Ist das ein Problem? Die Adressierung ist vom Hersteller des Sensors so vorgegeben.

Besten Gruß und danke noch mal,
Al

 

[Heinileini]

Ja, genau 2 Worte auf einer ungeraden Adresse. Ist das ein Problem? Die Adressierung ist vom Hersteller des Sensors so vorgegeben.

So Vorgegeben? In Form eines Beispiels? Es ist nicht einmal bei Siemens selbstverständlich, dass Beispiele auch tatsächlich aus Sicht des "Anwenders" funktionsfähig sein sollten.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Welche Register-Nummern willst/sollst/mußt Du laut Hersteller des Sensors auslesen? Gibt es dazu ein Handbuch?
Dein Anfrage mit der Modbus_Master-Anweisung will die Register 2219 und 2220 lesen.

Harald

 

[ban-al]

Hallo Heinileini und Harald,

anbei die beiden Dokumente vom Hersteller in denen die Adressierung beschrieben wird.

Anhang anzeigen 1-DatenPaket Modbus Sauerstoffsensor ODOS_V2.pdf
Anhang anzeigen 2-ODOS_Register_Table_And_Additional_Informations_EN_V12.pdf

Beste Grüße,
Al

 

[ban-al]

Hallo noch einmal zusammen. Ich glaube, die Fehlermeldung, die Corrado entdeckt hat, war ein falscher Alarm. Die kommt nämlich vom Sensor, den ich versehentlich noch im Bus hatte (er hat sozusagen auf seine eigene Antwort geantwortet). Wenn ich nur die S7 am Rechner habe und die Antwort des Sensors simuliere, kommt gar keine Rückmeldung der S7, die Werte werden nur in den Datenbaustein geschrieben (so wie es sein soll).

Beste GRüße
Al

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wie hast Du den Sensor an den CB angeschlossen? Hast Du die Terminierung mit BIAS auch angeklemmt oder nur die die beiden Datenleitungen?

Eventuell solltest Du es mal mit der Terminierung versuchen.

Gruß

 

[ban-al]

Hallo Thruser,
danke für Deine Antwort. Die Terminierung ist mit angeklemmt, siehe Bild. Habe es auch schon ohne probiert. Funktioniert auch nicht

Beste Grüße
Al

 

[ban-al]

Hallo nochmal,
habe mittlerweile den Tip bekommen, dass Fehlermeldungen vom Modbus Master Baustein evtl. gar nicht zu sehen sind und entsprechend über einen "Move" Auftrag die Fehlermeldungen in eine Variable schreiben lassen. Ich bekomme die Fehlermeldung 80C8 (Slave Timeout). Parität, Baudrate und Anschluss stimmen. Der Sensorhersteller sagt, ich solle Read- und Write-Timeout richtig einstellen. Welche Parameter sind denn das im TIA Portal, genauso benannt kann ich sie nicht finden.

Beste Grüße,
Al

 

[Thruser]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

hatte Dich ganz vergessen.

Time Out setzt Du mit dem Baustein Modbus_Comm_Load, Parameter RESP_TO, nach Deinem Bild im ersten Posting z.Zt. auf 1000ms gesetzt. Was sagt denn der Hersteller wie groß die sein soll?

Es könnte aber auch sein, daß es Timing Probleme gibt, so daß der Slave die Daten als ungültig erkennt. Die Pause zwischen zwei Zeichen eines Telegramms (Frame) dürfen max 1,5 Zeichen betragen und zwischen zwei Telegrammen (Frames) muß mindestens 3,5 Zeichen gewartet werden.

Mit Realterm läßt sich so etwas leider nicht erkennen. Vielleicht kann Dir da Modbus Slave von https://www.modbustools.com/download.html helfen.

Gruß

 

[ban-al]

Hallo Zusammen,

danke noch mal für Eure Hilfe. Letztendlich habe ich das Problem lösen können, nachdem der Hersteller des Sensors am Sensor die Parität auf "gleich" gestellt hat. Dann funktioniert der Modbus Load und Modbus Master Baustein einwandfrei.

Beste Grüße,
Al

 

[Thomas_v2.1]

danke noch mal für Eure Hilfe. Letztendlich habe ich das Problem lösen können, nachdem der Hersteller des Sensors am Sensor die Parität auf "gleich" gestellt hat. Dann funktioniert der Modbus Load und Modbus Master Baustein einwandfrei.

Und das obwohl du den Modbus_Comm_Load mit Parity=0 aufrufst? 0 steht für keine Parität.

Was mir jetzt auch noch aufgefallen ist, ist die Anzahl der Stopp-Bits. Diese lassen sich beim Modbus_Comm_Load nämlich nicht über die Schnittstelle einstellen, sondern man muss in den Instanz-DB schreiben (Siemens Design at it's best). Wenn du den Wert nicht änderst, steht dieser in Voreinstellung auf 1 was 1 Stopp-Bit bedeutet.

 

[ban-al]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Thomas,

nein, wenn ich gerade Parität verwende setze ich natürlich am Modbus_Comm_Load die Parität auf "2".
Aber der Hinweis mit der Anzahl der Stopp-Bits ist ja extrem interessant. Das hab ich tatsächlich nicht gewußt. Vielleicht lag es ja daran. Ich probiere das noch aus!

Beste Grüße,
Al

 

[holgermaik]

Hallo AI
TIA schein da etwas eigen zu sein.
In deinem Handbuch auf Seite 4 steht explizit, dass bei einer Verwendung mit einer 1200 der Sensor auf 8bit Daten, 1Stop Bit und Parität even umprogrammiert werden muss.
Dort sind auch die Time Out Zeiten angegeben.
Holger

 

[Heinileini]

Letztendlich habe ich das Problem lösen können, nachdem der Hersteller des Sensors am Sensor die Parität auf "gleich" gestellt hat.

Hmmm.
Ist denn für ModBus das DatenFormat nicht festgelegt? Ich hätte jetzt vermutet, 8 DatenBits mit ohne ParityBit, weil 8 DatenBits mit ParityBit (egal, ob even oder odd) eher "exotisch" sind (ausser Siemens-intern).
Wenn das DatenFormat also nicht "in Stein gemeisselt" ist, dann sollte es doch eigentlich S7-seitig auch anpassbar sein.
Warum muss der Hersteller des Sensors den Sensor anpassen? Hat er versäumt, dem Anwender die Möglichkeit dafür zu geben?
Wenn das DatenFormat doch "in Stein gemeisselt" sein sollte, wer ist dann vom Standard abgewichen? Die S7-Seite oder die Sensor-Seite?
Warum muss der Hersteller des Sensors den Sensor anpassen? Hat er den Sensor falsch parametriert ausgeliefert? Oder hat es der Anwender (unwissentlich) geschafft, den Sensor umzuparametrierten?
Hat der Hersteller des Sensors nicht auf diese Falle hingewiesen?
Warum hat die Simulation funktioniert? Ist die Simulation so intelligent, automatisch festzustellen, ob der Sender ohne Parity oder mit Parity even oder mit Parity odd arbeitet?
Und insbesondere, ist die Simulation so intelligent zu wissen, ob der Empfänger ohne Parity erwartet oder mit Parity even oder Parity odd?
Hmmm.
Durch irgendetwas hätte man doch auf die Spur des ParityBits gelenkt werden müssen. Klar war nur, dass sich der Sensor anscheinend überhaupt nicht angesprochen fühlte.