Modbus verstehen

[wolf (Gast)]

Hallo an alle Experten,
ich versuche gerade Modbus zu verstehen.
Habe mir Daten aufzeichnet und verstehe diese nicht richtig.
Im Anhang das Bild zeigt meine Aufzeichnung.
Praktisch schickt der Master eine Anfrage (Markierte stelle)an den Slave 
01 mit der Funktion 03 das vom 6 Register 11 Register gelesen werden 
sollen danach das CRC mit E4 OC dann ist noch ein 00 das ich nicht 
verstehe.
Die Antwort ist dann:

Adresse 01 Kommando 03 und dann sollte eigentlich die Start Adresse 
Kommen aber es kommt 16 ? Das verstehe ich nicht.
Wäre sehr nett wenn mir jemand auf die Sprünge helfen könnte

Wolfgang

[Schorsch X. (bastelschorsch)]

Hallo Wolf,
Die 00 bei der Anfrage könnte vielleicht was mit irgendeiner Umschaltung 
der RS485 zu tun haben ???

Antwort auf function code 3 ist:
function 03
Byte count 16h -> 22d -> 2 Byte / Wort
22 Datenbytes h-l
CRC l b9
CRC h 09

Also eigentlich alles so wie es sein soll (hab allerdings den CRC nicht 
nachgerechnet).

[wolf (Gast)]

Schorsch X. schrieb:
> Hallo Wolf,
> Die 00 bei der Anfrage könnte vielleicht was mit irgendeiner Umschaltung
> der RS485 zu tun haben ???
>
> Antwort auf function code 3 ist:
> function 03
> Byte count 16h -> 22d -> 2 Byte / Wort
> 22 Datenbytes h-l
> CRC l b9
> CRC h 09
>
> Also eigentlich alles so wie es sein soll (hab allerdings den CRC nicht
> nachgerechnet).

Danke das mit dem Count hatte ich nicht verstanden.
Danke für deine Hilfe!
Noch eine Frage, muss der Slave nach Empfang auch 3 Zeichen Lang Warten 
bis er Antworten darf?
Lg
Wolfgang

[Christian M. (chrigi001)]

wolf schrieb:
> Noch eine Frage, muss der Slave nach Empfang auch 3 Zeichen Lang Warten
> bis er Antworten darf?

Ja und eigentlich sind es 3.5 Zeichen.

Die komplette Modbus Spezifikation findest du hier:

http://www.modbus.org/specs.php

[wolf (Gast)]

Christian M. schrieb:
> Ja und eigentlich sind es 3.5 Zeichen.
>
> Die komplette Modbus Spezifikation findest du hier:

Ok dann ist meine Idee einfach drei Zeichen vorher zu schicken ohne den 
Sender einzuschalten (485) hinfällig:-(

Wäre einfacher da ich bei verschiedenen Bautraten nicht neu den Timer 
einstellen muß

Danke schön

[Rufus Τ. F. (rufus)]

Das ist eine Mindestzeit. Der Slave darf selbstverständlich auch 
deutlich später mit seiner Antwort beginnen.

In RTU mode, message frames are separated by a silent interval of 
at least 3.5 character times. In the following sections, this time 
interval is called t3,5.

"at least" = "mindestens".

In unicast the Response time out must be set long enough for any slave 
to process the request and return the response, in broadcast the 
Turnaround delay must be long enough for any slave to process only 
the request and be able to receive a new one. 
Therefore the Turnaround delay should be shorter than the Response time-out. 
Typically the Response time-out is from 1s to several second at 9600 bps; 
and the Turnaround delay is from 100 ms to 200ms.

[wolf (Gast)]

Rufus Τ. F. schrieb:
> Das ist eine Mindestzeit. Der Slave darf selbstverständlich auch
> deutlich später mit seiner Antwort beginnen.
> In RTU mode, message frames are separated by a silent interval of
> at least 3.5 character times. In the following sections, this time
> interval is called t3,5.
>
> "at least" = "mindestens".


D.H. ich kann meine Idee mit den 4 Zeichen Senden ohne Sender ein zu 
schalten als intervall Timer nutzen?

[Rufus Τ. F. (rufus)]

Ja, das sollte funktionieren, aber das ist schon ziemlich hektisch.

Wenn Du Dir die Werte für "response time-out" und "turnaround delay" 
ansiehst, kannst Du aber auch viel entspannter an die Sache herangehen. 
Das im Beispiel genannte Timeout von einer Sekunde bei 9600 Baud 
entspricht immerhin fast 1000 Zeichen.

Wenn Du z.B. mit einem Timer 50 oder 100 msec lang wartest, bevor Du mit 
dem Senden anfängst, ist das auch noch vollkommen in Ordnung.

Ist denn Dein µC, mit dem Du das veranstalten willst, tatsächlich schon 
drei, vier Zeichenzeiten nach Empfang des passenden Telegramms in der 
Lage zu antworten? Bei 9600 Baud sind das etwa drei bis vier 
Millisekunden.

[Pier S. (bigpier)]

Rufus Τ. F. schrieb:
> Ist denn Dein µC, mit dem Du das veranstalten willst, tatsächlich schon
> drei, vier Zeichenzeiten nach Empfang des passenden Telegramms in der
> Lage zu antworten? Bei 9600 Baud sind das etwa drei bis vier
> Millisekunden.

Auf jeden Fall. Die Daten sind vorbereitet und müssen ja nur gesendet 
werden;-)

Möchte ja den Bus so schnell wie möglich nutzen! der Master wird 
hoffentlich nicht eine Sekunde auf die Antwort warten sondern den 
nächsten Slave abfragen!

Lg

[Rufus Τ. F. (rufus)]

Pier S. schrieb:
> der Master wird hoffentlich nicht eine Sekunde auf die Antwort warten

Doch, das tut er. Modbus wird auch mit winzigen Krümelprozessoren 
implementiert, die nicht sonderlich flott auf irgendwelche Anfragen 
reagieren können.

> Typically the Response time-out is from 1s to several second at 9600 bps;

Der Master kann also auch noch deutlich länger als eine Sekunde warten.

Du solltest keine Echtzeitfähigkeit erwarten. Dafür ist Modbus nicht 
konzipiert (auch wenn es von einem SPS-Hersteller entwickelt wurde), und 
mit der Spezifikation auch definitiv nicht geeignet. Das ist nichts 
hektisches.

Bedenke, wie uralt das Protokoll ist.

[Chr. Querhuber (Gast)]

Rufus Τ. F. schrieb:
>> der Master wird hoffentlich nicht eine Sekunde auf die Antwort warten
>
> Doch, das tut er. Modbus wird auch mit winzigen Krümelprozessoren
> implementiert, die nicht sonderlich flott auf irgendwelche Anfragen
> reagieren können.

Spitzfindig. Er wird warten bis Timeout (meist 1,5 sekunden), aber wenn 
er eine Antwort bekommen hat, wird er direkt den nächsten Slave 
anfragen, könnte man meinen. Letztlich hängt das davon ab was im Master 
so programmiert wurde.

Rufus Τ. F. schrieb:
> Du solltest keine Echtzeitfähigkeit erwarten. Dafür ist Modbus nicht
> konzipiert (auch wenn es von einem SPS-Hersteller entwickelt wurde), und
> mit der Spezifikation auch definitiv nicht geeignet. Das ist nichts
> hektisches.

Echtzeit ist eh so ein hartes Wort. Damals wurde es für die 
Kommunikation zwischen SPSen und davon abgesetztem I/O benutzt. Klar da 
hängt man am Ende nicht den Roboterarm dran. Aber es gab und gibt einen 
Haufen Dinge wo es nicht so darauf ankommt ob es ne halbe Sekunde später 
passiert.

Andererseits kann man das Ganze ohne weiteres bei mittleren Baudraten 
(36400 oder so) auf fast 100 Bustransaktionen pro Sekunde bringen. Ob 
das Echtzeit ist ist nur noch ne Frage der Definition.

CQ

[Rufus Τ. F. (rufus)]

Chr. Querhuber schrieb:
> Er wird warten bis Timeout (meist 1,5 sekunden), aber wenn er eine
> Antwort bekommen hat, wird er direkt den nächsten Slave anfragen, könnte
> man meinen.

Natürlich. Wobei die Zeit für "direkt" auch als Wert spezifiziert ist - 
das  ist das "turnaround delay".

Ist der Master zu hektisch, reagieren manche Modbus-Devices schlichtweg 
mit Timeouts, d.h. sie antworten nicht. Steht zwar so natürlich nicht in 
der Dokumentation (der jeweiligen Devices), aber die ist sowieso eher 
überschaubar.

> Aber es gab und gibt einen Haufen Dinge wo es nicht so darauf ankommt ob
> es ne halbe Sekunde später passiert.

Gebäudeleittechnik oder "Smart Home" sind Beispiele dafür - für eine 
Heizungssteuerung ist es wirklich völlig wurscht, ob der Raumfühler 
seinen Messwert der Zentrale innerhalb von 10 msec oder erst nach einer 
Minute überträgt, das gesteuerte System ist um Größenordnungen träger.