Modbus TCP

Antworten
abacom
Site Admin
Beiträge: 3917
Registriert: Dienstag 23. September 2008, 10:54
Kontaktdaten:

Modbus TCP

Beitrag von abacom » Montag 13. Oktober 2008, 11:57

ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 05.10.2007 17:03 Titel: Modbus TCP

--------------------------------------------------------------------------------

Hallo Abacom-Team,

die neuen Modbus-TCP-Komponenten sind so etwas wie "the best thing since the invention of sliced bread".

In der Kombination von
- einer PL-Applikation auf einem PC IRGENDWO auf der Welt
- einem Lantronix XPORT (oder einer Abart davon) IRGENDWO ANDERS auf der Welt, Port für serielles Tunneln auf 502 gedreht
- einem beliebigen Mikrocontroller, z.B. einem AVR Mega, der Modbus-Slave spielt werden Dinge möglich, von denen man bislang noch nicht mal geträumt hat.

Von der absoluten Perfektion ist man gegenwärtig nur noch EINEN winzigen Schritt entfernt: Wie schafft man es, dass die neuen Komponenten (die vorhandene TCP-Komponente ist vermutlich gleich betroffen) eine DNS-Namensauflösung hinbekommen und KEINE harte IP-Adresse benötigen? Das wäre aus meiner Sicht die ultima ratio!

Oder stelle ich mich wieder nur zu doof an und das geht schon ???

Mit freundlichen Grüßen
Ulrich Bangert

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 08.10.2007 09:34 Titel:

--------------------------------------------------------------------------------

Die Komponenten basieren auf den berühmten "INDY SOCKETS". Die HOST-Eigenschaft löst nach meinem Kenntnisstand auch DNS-Namen auf. Ein einfacher Test mit "MyComputer" statt lokaler IP war jedenfalls auch erfolgreich.

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 09.10.2007 06:21 Titel:

--------------------------------------------------------------------------------

Hallo Abacom-Team,

zunächst einmal danke für Ihr Bemühen und Ihre Antwort!

Eine genauere Analyse des Sachverhaltes zeigt folgendes auf:

1) Die Namensauflösung auf der Basis der Indy-Komponenten funktioniert tatsächlich! Das ist zunächst einmal sehr gut so!

2) Dass die Namensauflösung tatsächlich funktioniert, wurde bei meinen bisherigen Experimenten NICHT richtig erkannt, weil PL-Entwicklungsumgebung und AVR-Entwicklungsumgebung auf dem gleichen Rechner liefen. Sobald aber eine ModbusTCP-Komponente bei PL benutzt wird, steigt die Prozessorlast im Betrieb auf 100% (auch im SLOW-Modus) und bringt alle andere Programmaktivitäten fast komplett zum Erliegen. Deswegen funktionierten meine Breakpoints in der AVR-Entwicklungsumgebung nicht. Auch wenn man die Indy-Komponenten im Blocking-Modus benutzt, so kostet das nur Rechenzeit, wenn diese tatsächlich Netzwerkaktivität entwickeln und NICHT im Ruhezustand. Die hohe Prozessorlast muss man daher der Implementation zurechnen und meine Hoffnung geht dahin, dass sich da von Ihrer Seite noch etwas tut.

3) Ein Handanlegen an die ModbusTCP-Komponenten wird sich aus meiner Sicht auch deswegen nicht vermeiden lassen, weil auch inhaltlich noch alles richtig funktioniert. Ich habe nicht ALLES durchprobiert, weil ich schon bei meinen ersten Versuchen auf Fehler gestossen bin:

4) Die Write-Single-Coil-Funktion sollte nach dem MBAP-Header 3 Bytes senden, von denen das erste der Function-Code "5" und die restlichen beiden die Startadresse sind. Lässt man aber in den Eigenschaften der Komponente die Startadresse auf "1" und die Unit-Id auf "255" stehen (eigentlich vernünftige Werte), so passiert folgendes: Die Komponente sendet 8 Bytes, von denen alle bis auf das sechste den Wert "0" haben. Das sechste Byte hat den Wert "6". Das ist kompletter Mumpiz. Weder die Längenangabe stimmt, noch stimmt die tatsächliche Telegrammlänge, noch ist die Unit-Id richtig eingesetzt. Eigentlich ist der "Modbus-Protocol-Identifier" des Headers mit "0" das einzige richtige an dieser Stelle.

5) Ändert man in den Eigenschaften der Komponente die Unit-Id auf 254, so verändert sich die Situation folgendermaßen: Die Komponente sendet insgesamt 10 Bytes, von denen das sechste den Wert "6" hat, das siebte den Wert "254" und das achte den Wert "5". Alle anderen Bytes haben den Wert "0". Das sieht schon ein wenig freundlicher aus, weil zumindest die Unit-Id und der Function-Code richtig eingetragen sind. Wenn man nun noch in den Eigenschaften die Startadresse auf "2" stellt, erhält das zehnte Byte den Wert "1", so dass man davon ausgehen kann, dass die Adressierung richtig zählt. Allerdings scheint mir in beiden Fällen die Längenangabe "6" falsch zu sein, weil der Standard vorschreibt, dass die Längenangabe die Unit-Id und die nachfolgenden Bytes betrifft, hier also "4" richtig wäre (1 Byte Unit-Id, 1 Byte Function-Code, 2 Byte Adresse).

6) Der Transaction-Identifier des MBAP-Headers darf zwar durch den Client im Prinzip frei eingestellt werden, man sollte aber nicht vergessen, dass er seiner Funktion als TRANSAKTIONS-IDENTIFIZIERER nicht gerecht werden kann, wenn man seinen Wert einfach auf "0" stehen läßt. Im Prinzip sollte man diesen Wert um "1" bei jeder Transaktion inkrementieren, um jeder Transaktion eine eindeutige Id zuzuordnen. Wenn einem das nicht gelingt (z.B. weil mehrere ModbusTCP-Instanzen im gleichen Projekt verbaut sind), so ist der zweitbeste Weg, jeder Transaktion eine 16-Bit Zufallszahl zuzuordnen. Dies kann keine 100%ige Eindeutigkeit gewährleisten, ist aber besser als gar nichts.

Bitte verstehen Sie meine Beiträge nicht nur als Herumklagen&Meckern. Ich will ja gerne behilflich sein, wenn ich irgendwie kann. Diese Geschichte ist vom Ansatz her viel zu gut, als dass man sie fehlerbehaftet so stehen lassen dürfte.

Mit freundlichen Grüßen in die Runde
Ulrich Bangert

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 09.10.2007 06:36 Titel:

--------------------------------------------------------------------------------

Weil ich schon gerade am Testen war:

Die Komponente "Read-Holding-Register" funktioniert bei Unit-Id<>255 Ok, weil außer der Start-Adresse auch die Länge in 2-Bytes übertragen wird und deswegen die Längenangeabe "6" richtig ist.

Mit Unit-Id 255 kommt wieder Unsinn heraus.

Mit freundlichen Grüßen
Ulrich Bangert

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 09.10.2007 09:18 Titel:

--------------------------------------------------------------------------------

Sehr geehrter Her Bangert,
vielen Dank für das Feedback und die detailierte Fehlerbeschreibung.
Wir räumen gerne ein, das wir das kostenlose Update als erste Annäherung an die Modbus-Funktionalität verstehen und die Fehlerfreiheit noch nicht unbedingt gegeben ist. Die meisten Funktionen konnten wir mit Mustergeräten erfolgreich testen (Vgl. Beispiele für HWG und Sollae. Ich werde mir ihre Anmerkungen in den nächsten Tagen einmal näher anschauen.

Zuletzt bearbeitet von abacom am 09.10.2007 13:24, insgesamt einmal bearbeitet

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 09.10.2007 12:43 Titel:

--------------------------------------------------------------------------------

Zitat:
Allerdings scheint mir in beiden Fällen die Längenangabe "6" falsch zu sein, weil der Standard vorschreibt, dass die Längenangabe die Unit-Id und die nachfolgenden Bytes betrifft, hier also "4" richtig wäre (1 Byte Unit-Id, 1 Byte Function-Code, 2 Byte Adresse).



Da liegen Sie falsch. Sie haben die 2 Byte für den Coil-Status vergessen.
Dieser wird in 2 Byte übertragen FF00=EIN oder 0000=AUS. Byte-Länge sechs ist also richtig.

Zitat:
Die Komponente "Read-Holding-Register" funktioniert bei Unit-Id<>255 Ok, weil außer der Start-Adresse auch die Länge in 2-Bytes übertragen wird und deswegen die Längenangeabe "6" richtig ist.



Der eingestellte Wert der UnitID hat definitiv keinen Einfluss auf die Anzahl der übertragenen Bytes. Mir scheint auch hier ist bei der Analyse ein Fehler Ihrerseits passiert.

Darf man Fragen wie Sie zu den obigen Erkenntnissen gelangt sind?

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 10.10.2007 12:51 Titel:

--------------------------------------------------------------------------------

Hallo Abacom-Team,

nachdem durch Ihre Antwort ein NOCH genaueres Hinsehen notwendig wurde, hat sich nun folgende Erkenntnis ergeben:

1) Sie hatten mit Ihren Feststellungen Recht.

2) Meine Beobachtungen und Messungen waren richtig.

3) Das Problem hat seine Ursache an einer GANZ anderen Stelle, die bislang als Fehlerursache nicht bedacht wurde.

Insgesamt bin ich aber schon froh, auf diese Sache gestossen und ihr nachgegangen zu sein, weil sie für andere Anwender der gleichen Technologie vielleicht ein K.O.-Kriterium sein könnte.

Also: Mein ModbusTCP-Endgerät wird von einem AVR-Mega32 Microcontroller gesteuert. Statt von einer der zahlreichen Lösungen Gebrauch zu machen, die einen TCP/IP-Stack in den Controller selber reinpflanzen, habe ich mich dazu entschlossen, die komplette Netzwerkanbindiung von einem LANTRONIX XPORT übernehmen zu lassen. Das ist ein kleiner Klotz, nur wenig größer als eine RJ-45-Buchse, mit einem kompletten Webserver drin und noch etlichem mehr.

Dieser Klotz behauptet von sich, dass er, wenn er über einen bestimmten (einstellbaren) IP-Port angesprochen wird, einen transparenten Tunnel bildet, über den ALLES, was in einem TCP/IP-Paket verpackt ist, über eine serielle (TTL) Schnittstelle an einen Mikrocontroller weitergeben kann und umgekehrt ALLES, was der MC über Schnittstelle schickt, in ein TCP/IP-Paket packt und dem Client schickt. Im Prinzip also ein Tunneln serieller Informationen durch ein LAN/WAN. Auf der Client-Seite kann dabei entweder ein virtueller Com-Port zum Einsatz kommen oder eben eine PL-Komponente, die etwas Byteorientiert in TCP/IP einpackt, wie die ModbusTCP-Komponenten.

Mit dieser "Transparenz" hat es allerdings die folgende wichtige Bewandnis: Ist in der Konfiguration für den seriellen Tunnel unter "Channel 1", "Connection" unter "Common Options" für "Telnet Mode" die Option "Enabled" eingeschaltet (=Default !!!), so wird beim Öffnen der TCP/IP-Verbindung eine sog. Telnet-Verbinding geöffnet.

Diese wiederum ist nicht GANZ transparent, sondern bedient sich einiger Sonderzeichen um die nachfolgenden Zeichen als Befehle zu interpretieren. Sogenannter IAC (Interprete As Command) Mechanismus. So wird ein <Cr> <Lf> einer Sonderbahandlung unterzogen und die Bytefolge 0xFF 0xXX als Befehl interpretiert, der NICHT transparent durchgereicht wird. Dadurch gingen in meinem Fall immer 2-Byte-Blöcke verloren, wenn das Telegramm ein 0xFF enthielt. Das ist die ganze Erklärung! Wenn die entsprechende Option disabled wird, wird wirklich ALLES transparent durchgereicht und die Sache funktioniert astrein.

Danke nochmals für Ihre Fehlersuche auf IHRER Seite der Software! Ohne diesen Dialog wäre man der Lösung ferngeblieben! Nachdem sich auch die Namensauflösung als problemlos gerausgestellt hat, hoffe ich, die Diskussion stößt andere Forums-Mitglieder an, mal darüber nachzudenken, welches Power-Wekzeug uns hier in die Hand gegeben wurde.

Mit freundlichen Grüßen
Ulrich Bangert

P.S.
Mit der 100% Prozessorlast und der noch nicht so guten Implementation des Transakions-Identifiers schaut Ihr aber nochmal, oder ?

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 13.10.2007 13:38 Titel:

--------------------------------------------------------------------------------

Alle bisherigen Feedbacks bestätigen zunächst einmal, dass die Komponenten funktionieren. So auch unsere Erfahrung.
ABACOM support

Antworten

Zurück zu „Thema Modbus“