Modbus-TCP-Komponenten

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

Modbus-TCP-Komponenten

Beitrag von abacom » Montag 13. Oktober 2008, 13:41

hogu



Anmeldungsdatum: 08.11.2007
Beiträge: 16
Wohnort: Salzburg
Verfasst am: 08.11.2007 20:40 Titel: Modbus-TCP-Komponenten

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

Hallo Abacom Team,

zuerst einmal Danke für die Modbus-Komponenten in der Version vom 17.10.2007. Das ist fast genau dass, was ich brauche. Das Ganze noch auf der Seriellen Schnittstelle anstatt TCP und meine Arbeit wäre um Vieles leichter. Aber vielleicht ist das ja eh schon geplant.

Meine Schaltung besteht einem 1 Sekunden Taktgeber und 2x "Read Input Registers", die auf die selbe Unit-ID gehen, aber unterschiedliche Startadressen haben. Der Ausgang BSY des 1. führt zum CLK des 2., so wie es auch im Beispiel verwendet wird. Die REGn Ausgänge selbst werden passend formatiert und dann angezeigt.

Jetzt tritt in unregelmäßigen Abständen (mehrere Minuten) ein Dialogfenster mit "Fehler bei Bereichsprüfung" auf. Leider meldet es keine weiteren Hinweise auf das Bauelement. Nach dem Quittieren des Fehlers frieren alle Anzeigen ein, die Modbus-Register werden nicht mehr abgefragt aber die hohe Last bleibt. Dabei gibt es Unterschiede zwischen den Betriebsarten Fast und Slow.

Modus Fast: Während die Schaltung arbeitet, wird auf einem 2,4 GHz Win XP System bei 100% Prozessorlast gerade mal 700 Hz Simulationsfrequenz erreicht, aber das ist ein anderes Thema. Bei Auftreten des Fehlers geht die Last auf ca 50% zurück, auch nach dem Quittieren. Die Anzeigen frieren ein und Modbus-Abfragen erfolgen nicht mehr. Die Simualtionsfrequenzanzeige im PLE steht auf 0 Hz. Eine der Anzeigen auf der Frontplatte ist die Simualtionsfrequenz, die aber am alten Wert hängen bleibt, was ja auch plausibel ist bei 0 Hz. Nach einem Neustart der Simulation läuft wieder alles.

Modus Slow: Die Simulation läuft mit ca. 350 Hz bei 50% Prozessorlast. Bei Auftreten des Fehlers bleibt die Last etwa gleich und auch nach dem Quittieren läuft, wie zuvor im Modus Fast, nichts mehr. Wenn man jetzt die Simulation neu startet, dann ist zwar die Prozessorlast wieder bei 50%, aber die Schaltung wird offenbar nicht mehr bearbeitet. Die Simualtionsfrequenzanzeige im PLE bleibt auf 0 Hz stehen. Erst nach einem Neustart des PLE arbeitet die Simulation im Modus Slow wieder.

Dieser Fehler tritt offenbar innerhalb der Modbus-TCP-Komponenten auf, weil auch, wenn man alle REGn-Ausgänge von der Weiterverarbeitung abhängt, erscheint der Fehler. Auch das Einfügen einer Verzögerung in die BSY1-CLK2 Leitung bringt keine Besserung. Ebenso beide Modbus-Komponenten vom selben Taktgenerator zu versorgen, fallende bzw. steigende Flanke, hilft nicht. Ist nur eine Modbus-Komponente angeschlossen, so erscheint der Fehler auch nach stundenlanger Laufzeit nicht mehr und zwar unabhängig davon, welches der beiden "Read Input Registers" angeschlossen ist. Eines läuft, zwei liefern den Fehler.

Möglicherweise tritt dieses Problem in Verbindung mit Kommunikationsfehlern auf, wobei die Fehler in der Kommunikation die gleichen sind, unabhängig davon, ob ein oder zwei Modbus-Komponenten zum Einsatz kommen.

Dieses Verhalten mit 0 Hz Simulationsfrequenz tritt auch auf mit der Fehlermeldung "Socket Error # 10054 Connection reset by peer.", erzeugt im laufenden Betrieb durch Ziehen des Netzwerksteckers beim Modbus-Device.

Generell ist es sicher nicht ganz unproblematisch während der Anzeige einer Fehlermeldung die Schaltung nicht mehr weiter zu simulieren, aber vielleicht ist das ja auch nur eine Folgeerscheinung der "0 Hz Simulation."

Ich oute mich auch gleich als PLE-Anfänger und vielleicht mache ich deswegen auch nur irgendwas falsch. Für jegliche Hilfen bin ich dankbar.

Günter

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 09.11.2007 09:30 Titel:

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

Werden einmal versuchen der Sache nachzugehen. Interessant wäre zu wissen, welche Server-Hadware (oder Software) abgefragt wird.

Nach oben


hogu



Anmeldungsdatum: 08.11.2007
Beiträge: 16
Wohnort: Salzburg
Verfasst am: 09.11.2007 10:03 Titel:

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

Derzeit ist der ModBus-TCP-Slave die unregistrierte Version von MNetSvr ( http://www.win-tech.com/html/mnetsvr.htm ) auf 127.0.0.1. Das ist eine Modbus-TCP/COM bridge. Daran hängt dann über eine Virtuelle Seriellen Schnittstelle (USB-FTDI) eigene Hardware, die wiederum einen Seriellen Modbus-Slave darstellt, gemäß http://www.modbus-ida.org/docs/Modbus_o ... _V1_02.pdf

Dieser MNetSvr unterbricht in der unregistrierten Variante alle paar Minuten für ca. 30 Sekunden die TCP-Verbindung, was den PLE-Komponenten auch auffällt, und sie melden es an der ERR-Leitung. Normalerweise funktioniert das Reconnect auch problemlos, aber vermutlich nicht immer.

Ich könnte auch das ganze Projekt zur Verfügung stellen.

Nach oben


hogu



Anmeldungsdatum: 08.11.2007
Beiträge: 16
Wohnort: Salzburg
Verfasst am: 13.11.2007 20:12 Titel:

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

Hallo Abacom,

in der Doku zum Update ist zwar nichts erwähnt, aber mit der PLE-Version vom 13.11.2007 tritt der "Fehler bei Bereichsprüfung" nicht mehr auf. Das Problem scheint mir eine Übertaktung des CLK-Einganges gewesen zu sein. Ich hab in der letzten Version versuchsweise mal einen Takt von 10 Hz angelegt und dann ist der Fehler sofort aufgetreten. Dies ist jetzt weg.

Allerdings tritt jetzt der Effekt auf, dass zeitweise die Register zwischen den ReadInputRegister-Komponenten vertauscht werden. Die erste Komponente liest 2, die 2.Komponente 6 Register. Treten keine Probleme auf, so wird eine Zyklusfrequenz von ca. 3 Hz erreicht und alles passt. Taktet man die erste Komponente jetzt mit 10 Hz, so springen die Werte von REG1 und REG2 zwischen den Komponenten hin und her. Die Werte der 2.Komponente erscheinen an der 1. und umgekehrt. Die Werte der REG3-6 an der 2.Komponente kommen aber trotzdem richtig an.

Kann es sein, dass der CLK einer Modbus-TCP-Komponente nicht ausgelöst werden darf, solange BSY einer anderen noch aktiv ist? Eine Übertaktung an einer Komponente ist, wie ich festgestellt habe, kein Problem.

Die Anforderungen an den Modbus-Server kommen jedenfalls richtig an und auch die Antworten werden passend zurückgesendet. Kann diese Vertauschung vielleicht mit dem Transaction-Identifier des MBAP-Headers zusammenhängen? In einem anderen Artikel viewtopic.php?t=559 wurde mal erwähnt, dass der einen konstanten Wert enthält.

Günter

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 13.11.2007 21:05 Titel:

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

Schön. dass der Bereichsfehler sich erledigt hat. Eine kleine Nachbearbeitung hat zwar stattgefunden, war aber eigentlich nicht erwähnenswert.

Die Busy-Ausgänge sind keinesfalls nur Schnickschnack, sondern sollten schon genutzt werden um Requests der Reihe nach auszuführen. Gleichzeitiges oder "wildes" Triggern kann zu den von Ihnen beschriebenen Effekten führen. Die Transaction-Identifier sind zwar gut gedacht, helfen aber aufgrund der PL-Programmstruktur nicht wirklich weiter. Die Auswertung von Busy ist auch deshalb empfehlenswert, weil auch eine ganze Reihe von Servern keine Requests entgegen nehmen, bevor der vorhergehende abgearbeitet ist, auch wenn das in Ihrem Fall vielleicht nicht der Fall sein mag.

Mit einem Demoserver der ein regelmässiges Re-Connect erzwingt, eine 'runde' PL-Applikation bauen zu wollen, scheint mir ohnehin nicht der beste Ansatz zu sein. Jedes Re-Connect braucht Aufmerksamkeit des Rechners und die Sache ist auch so schon komplex genug.

Nach oben


hogu



Anmeldungsdatum: 08.11.2007
Beiträge: 16
Wohnort: Salzburg
Verfasst am: 14.11.2007 11:32 Titel:

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

Meine Schaltung benutzt ja auch die Busy-Ausgänge und verkettet damit die Requests. Meine Sorge ist nur, dass sich diese Anordnung irgendwann tot läuft. Kann man sich denn darauf verlassen, dass der Busy-Ausgang High und wieder Low wird bei jeder Flanke am Clock-Eingang, auch, wenn irgendwelche Fehler auftreten?

Ich habe deswegen die Schaltung so erweitert, dass beim Ausbleiben der Busy-Flanke am letzten Bauteil nach 10 Sekunden die Kette neu getriggert wird. Jetzt passiert diese Vertauschung der Register zwar nicht mehr sehr oft, aber wenn doch, dann bleibt sie lange erhalten. Ich räume allerdings ein, dass die Schaltung vielleicht noch nicht ganz fehlerfrei ist.

Die Benutzung des Demoservers ist ja auch nur vorübergehend. Wenn die Modbus-TCP-Komponenten zufriedenstellend laufen, dann wird der ohnehin ersetzt. Allerdings kann man in einem Netzwerk nie vom 100% Verfügbarkeit ausgehen und deswegen ist das Verhalten dieses Demoservers ein willkommener Test um die Schaltung stabil hinzubekommen. Wenn's mit dem läuft, dann wirft sie so schnell nichts aus der Bahn.

Vom einwandfreien Funktionieren aller beteiligten Komponenten abhängige Hard- und Software gibt es schon genug auf dieser Welt. Darauf aufzubauen, dass immer alles astrein funktioniert ist blauäugig. Reale Bedingungen sind anders.

Günter

Nach oben


hogu



Anmeldungsdatum: 08.11.2007
Beiträge: 16
Wohnort: Salzburg
Verfasst am: 14.11.2007 21:11 Titel:

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

Hallo Abacom,

ich hab mir jetzt noch mal die 3 mitgelieferten Modbus-TCP Beispiele angesehen. Dort werden zwar die Busy-Leitungen zum Triggern der jeweils nächsten Modbus-TCP-Komponente benutzt, aber die Timeouts sind bei allen Komponenten auf 1 sec gesetzt. Bei einer Triggerung des ersten Bausteins mit 200 ms kommt es aber bei einem etwas langsameren Netzwerk bzw. bei Ablaufen des Timeouts genau zu so einem gleichzeitigem Triggern mehrerer Modbus-TCP-Komponenten.

Kann es sein, dass diese Beispiele nur unter idealen Bedingungen laufen und es vielleicht auch zu solchen Vertauschungen kommt, wenn im Netzwerk etwas mehr Verkehr ist?


Günter

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 16.11.2007 14:22 Titel:

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

Sie haben recht, ein Übertakten der Komponenten ist nicht ausgeschlossen. Für nächste Woche ist ein Update geplant, das die Übertaktung konsequent ausschliesst. Neben mehr Sicherheit, die man dadurch erlangt, wird dadurch auch die Ablaufsteuerung in vielen Fällen einfacher. Schönes WE.
ABACOM support

Antworten

Zurück zu „Thema Modbus“