Step 7 MODBUSPN - OB100 neu aufrufen

drng · 2 Juli 2013

Hallo,

ich habe ein Problem mit der Modbuskommunikation über den FB - MODBUSPN, also die Modbus Kommunikation über die Integrierte PN Schnittstelle der CPU (CPU315-2PNDP).
Die CPU arbeitet als Client und bekommt Daten von zwei Modbus Servern im Netzwerk. Das funktioniert soweit auch ganz gut.
Das Problem besteht nun darin, dass die Server (Prüftechnik - WEARSCAN) alle 24h einen Reboot durchführen. Dies lässt sich leider absolut nicht ändern.
Da die Modbus Kommunikation aber im OB100 aufgebaut wird kann die CPU keine neue Verbindung herstellen, sobald dieser Reboot durchgeführt wurde.
Dementsprechend werden natürlich nach 24h keinerlei Daten mehr übertragen.

Hat eventuell irgendjemand eine Idee wie man das ganze lösen könnte ohne die CPU alle 24 Stunden neu zu starten? Ist eventuell ein Neuaufruf des OB100 möglich?

Ich danke schonmal im Vorraus.

Gruß, drng

vollmi · 2 Juli 2013

Wie wird die Kommunikation im OB100 denn aufgebaut? Poste das Teil mal.
IMHO was man im OB100 macht, kann man auch im OB1 mit ner Freigabe machen.

mfG René

drng · 2 Juli 2013

Naja die Verbindung wird im OB100 initialisiert. Im OB1 (oder einem anderen Zyklischen OB wenn man möchte) wird diese dann weiter aufgebaut. Ich poste mal beide Programmteile.

OB100:

Code:

//adapt the initialisation parameters according to your configuration

      L     1
      T     "CONTROL_DAT".ID

      CALL  "MODBUSPN" , "IDB_MODBUS"
       ID              :="CONTROL_DAT".ID
       DB_PARAM        :="MODBUS_PARAM"
       RECV_TIME       :=
       CONN_TIME       :=
       KEEP_ALIVE      :=
       ENQ_ENR         :=
       DISCONNECT      :=
       REG_KEY         :=
       LICENSED        :=
       BUSY            :="CONTROL_DAT".BUSY
       CONN_ESTABLISHED:="CONTROL_DAT".CONN_ESTABLISHED
       DONE_NDR        :="CONTROL_DAT".DONE_NDR
       ERROR           :="CONTROL_DAT".ERROR
       STATUS_MODBUS   :="CONTROL_DAT".STATUS_MODBUS
       STATUS_CONN     :="CONTROL_DAT".STATUS_CONN
       STATUS_FUNC     :="CONTROL_DAT".STATUS_FUNC
       IDENT_CODE      :=
       UNIT            :=
       DATA_TYPE       :=
       START_ADDRESS   :=
       LENGTH          :=
       TI              :=
       WRITE_READ      :=

      L     500
      T     "CONTROL_DAT".RECV_TIME

      L     T#5S
      T     "CONTROL_DAT".CONN_TIME

//      UN    "CONTROL_DAT".ERROR
//    BEB   

      L     "CONTROL_DAT".STATUS_CONN
      T     "CONTROL_DAT".Save_STATUS_CONN    //for static display in VAT

      L     "CONTROL_DAT".STATUS_MODBUS
      T     "CONTROL_DAT".Save_STATUS_MODBUS    //for static display in VAT

// STATUS_FUNC => Save_STATUS_FUNC
      L     DB1.DBD   38
      T     DB1.DBD   92
      L     DB1.DBD   42
      T     DB1.DBD   96
      L     DB1.DBW   46
      T     DB1.DBW  100

OB1: Bei jeder Positiven Flanke auf "ENQ_ENR" werden werte übertragen.

Code:

  U     "FL_Takt20"
      =     "CONTROL_DAT".ENQ_ENR





      CALL  "MODBUSPN" , "IDB_MODBUS"
       ID              :=W#16#1
       DB_PARAM        :="MODBUS_PARAM"
       RECV_TIME       :="CONTROL_DAT".RECV_TIME
       CONN_TIME       :="CONTROL_DAT".CONN_TIME
       KEEP_ALIVE      :=
       ENQ_ENR         :="CONTROL_DAT".ENQ_ENR
       DISCONNECT      :="CONTROL_DAT".DISCONNECT
       REG_KEY         :="LICENSE_DB".REG_KEY
       LICENSED        :="CONTROL_DAT".LICENSED
       BUSY            :="CONTROL_DAT".BUSY
       CONN_ESTABLISHED:="CONTROL_DAT".CONN_ESTABLISHED
       DONE_NDR        :="CONTROL_DAT".DONE_NDR
       ERROR           :="CONTROL_DAT".ERROR
       STATUS_MODBUS   :="CONTROL_DAT".STATUS_MODBUS
       STATUS_CONN     :="CONTROL_DAT".STATUS_CONN
       STATUS_FUNC     :="CONTROL_DAT".STATUS_FUNC
       IDENT_CODE      :="CONTROL_DAT".IDENT_CODE
       UNIT            :="CONTROL_DAT".UNIT
       DATA_TYPE       :="CONTROL_DAT".DATA_TYPE
       START_ADDRESS   :="CONTROL_DAT".START_ADDRESS
       LENGTH          :="CONTROL_DAT".LENGTH
       TI              :="CONTROL_DAT".TI
       WRITE_READ      :="CONTROL_DAT".WRITE_READ

      U     "CONTROL_DAT".ENQ_ENR
      R     "CONTROL_DAT".ENQ_ENR       //reset trigger after job has started

//for cyclic data exchange remove the comment keys
//    O     "CONTROL_DAT".DONE_NDR
//   O     "CONTROL_DAT".ERROR
//    S     "CONTROL_DAT".ENQ_ENR


      U     "CONTROL_DAT".DONE_NDR
      SPBN  err

//job finished without error

      L     "CONTROL_DAT".Count_Done    //for test purposes
      INC   1
      T     "CONTROL_DAT".Count_Done

      L     "CONTROL_DAT".TI            //TI should be incremented with each job
      INC   1
      T     "CONTROL_DAT".TI


// you can set the parameters for the next job here
// it is set in comments to give you the possibility to use the variable table 
// for changes during test

//      L     1
//      T     "CONTROL_DAT".UNIT

//      L     3
//      T     "CONTROL_DAT".DATA_TYPE

//      L    800
//      T     "CONTROL_DAT".START_ADDRESS

//      L     5
//      T     "CONTROL_DAT".LENGTH

//      SET   
//      =     "CONTROL_DAT".WRITE_READ

//      SET   
//      =     "CONTROL_DAT".ENQ_ENR       //job trigger


      BEA   


err:  U     "CONTROL_DAT".ERROR
      SPBN  end

//job finished with error

      L     "CONTROL_DAT".Count_Error   //for test purposes
      INC   1
      T     "CONTROL_DAT".Count_Error

      L     "CONTROL_DAT".STATUS_CONN
      T     "CONTROL_DAT".Save_STATUS_CONN    //for static display in VAT

      L     "CONTROL_DAT".STATUS_MODBUS
      T     "CONTROL_DAT".Save_STATUS_MODBUS    //for static display in VAT

// STATUS_FUNC => Save_STATUS_FUNC
      L     DB1.DBD   38
      T     DB1.DBD   92
      L     DB1.DBD   42
      T     DB1.DBD   96
      L     DB1.DBW   46
      T     DB1.DBW  100

end:  NOP   0

Lars Weiß · 2 Juli 2013

Klingt nach Parametrierfehler. Poste mal.

drng · 2 Juli 2013

Lars Weiß schrieb:
Klingt nach Parametrierfehler. Poste mal.

Kann mit Parametrierfehlern nichts zu tun haben. Ist einfach Siemens Vorgabe.

Auszug aus der Bedienungsanleitung ModbusPN:

Das heißt pro Verbindungwird benötigt:
• Ein Verbindungsparameterblock und die zugehörigen Modbusparameter im DB MODBUS_PARAM
• Aufruf von FB MODBUSPN in OB100
• Aufruf von FB MODBUSPN in OB1 oder einem Weckalarm-OB

Es funktioniert ja einwandfrei. Werte werden übertragen und können auch wunderbar verarbeitet werden.
Problem ist nur, dass die Initialisierung der Verbindung scheinbar nur über den OB100 machbar ist und ich suche jetzt nach einer Lösung DAS zu umgehen, bzw nach einem Reboot des Modbus Servers eine Verbindung neu aufzubauen.

Danke schonmal!

Koslovski · 2 Juli 2013

Hallo,

du kannst den Aufbau der Modbus-Kommunikation doch in einem separaten FC unterbringen. Diesen rufst Du dann sowohl vom OB100 als auch jeweils kurz nach dem Neustart der Server auf. Fertig.

Gruß

Koslovski

drng · 2 Juli 2013

Koslovski schrieb:
Hallo,

du kannst den Aufbau der Modbus-Kommunikation doch in einem separaten FC unterbringen. Diesen rufst Du dann sowohl vom OB100 als auch jeweils kurz nach dem Neustart der Server auf. Fertig.

Gruß

Koslovski

Genau soetwas habe ich mir auch gedacht, aber funktioniert das?
Ich habe momentan so eingerichtet, dass ich vom OB100 zwei FC's aufrufe (Für jeden Server einen, da diese sich natürlich zu unterschiedlichen Zeiten rebooten können)
Und im OB1 versuche die Verbindung herzustellen nachdem diese zuvor abgebrochen ist. Bislang komme ich da aber nicht auf die richtige Variante.

Danke schonmal für die Hilfe und entschuldigt die langen Antwortzeiten, als Neuling werden wohl alle Posts erst überprüft

Gruß

rostiger Nagel · 2 Juli 2013

drng schrieb:
Danke schonmal für die Hilfe und entschuldigt die langen Antwortzeiten, als Neuling werden wohl alle Posts erst überprüft

Ja bei dir schlägt die Spamabwehr erbarmungslos zu

drng · 2 Juli 2013

rostiger Nagel schrieb:
Ja bei dir schlägt die Spamabwehr erbarmungslos zu

Und ich dachte ich kann sinnvolle Beiträge leisten :-(

:-D ;-)

rostiger Nagel · 2 Juli 2013

Leiste mal, dein letzter Beitrag ist ja durchgekommen.

Snape · 3 Juli 2013

Hallo,
also dass der Verbindungsaufbau nur im OB100 funktioniert, stimmt nicht. Man kann den Baustein so parametrieren, dass er im OB100 schon die Verbindung aufbaut, aber man muss nicht.
Wenn mit ENQ_ENR = TRUE ein Telegramm gestartet wird und die Verbindung noch nicht aufgebaut ist, dann wird intern erst ein TCON initiiert und danach dann der TSEND/TRCV.
Wenn der Partner also alle 24 Stunden einen Reboot macht und somit die Verbindung abbaut, bekommt die PN-CPU das erstmal nicht mit. Erst wenn wieder ein Telegramm gestartet wird und der TSEND einen Verbindungsfehler meldet, bekommt die PN-CPU mit, dass der Partner die Verbindung abgebaut hat. Wenn das nächste Telegramm gestartet wird, wird dann aber wieder von der PN-CPU automatisch die Verbindung neu aufgebaut und die Daten gesendet. Das muss funktionieren.

Snape

drng · 3 Juli 2013

Naja, laut OpenModbus "Bedienungsanleitung" MUSS die Verbindung im OB100 Initialisiert werden. Wenn ich nun einen FC erstelle, in diesem den Verbindungsaufbau Initialisiere und ihn vom OB100 aufrufe klappt das ganze auch. Natürlich nur bei einem Neustart, nicht aber wenn die Verbindung abbricht und neu aufgebaut werden muss. Ich müsste eigentlich nur eine Bedingung für den erneuten Aufruf dieses FC's im OB1 haben. Ein abfallendes "CONN_ESTABLISHED" Signal scheint da nicht zu reichen.

Snape · 3 Juli 2013

Der Baustein muss natürlich in OB100 initialisiert werden. Da werden die Modbusparameter überprüft und die T-Bausteine mit 0 durchlaufen, damit der Verbindungsaufbau überhaupt funktioniert. Das ist aber nur die Initialisierung. In dem Parameter-DB wird mit connect_at_startup festgelegt, ob die Verbindung schon im OB100-Durchlauf aufgebaut werden soll oder nicht. Wenn der Parameter FALSE gesetzt ist, wird nur alles initialisiert und erstmal keine Verbindung aufgebaut. Die wird dann beim 1. Telegramm aufgebaut.
Aber nach einem Abbruch der Verbindung ist auch ein neuer Verbindungsaufbau möglich ohne das der OB100 aufgerufen werden muss.

Hast Du mal mit Wireshark geprüft, was bei und nach dem Reboot über das Netz gesendet wird? Da müsste ja der Abbau und Wiederaufbau der Verbindung aufgezeichnet werden.

drng · 3 Juli 2013

Der Verbindungsaufbau startet komischerweise bei mir unabhängig davon, ob ich CONNECT_AT_STARTUP setze oder nicht. Bedingung dafür ist aber weiterhin das ich die CPU neu starte.
Wenn ich nun einen der Partner in rebooten lasse will dieser sich aber beim besten willen nicht wieder verbinden.
Wireshark meldet in dem moment das die S7 als Broadcast fragt WHO IS "192.168.2.21" TELL "192.168.2.180"
Zwischendurch fragt dann währrend, bzw nach, dem Reboot der Partner als Broadcast "192.168.2.22" TELL "192.168.2.21"
Dazu sollte ich sagen, dass die CPU die IP 192.168.2.180 und der Partner die IP 192.168.2.21 hat.
Die 192.168.2.22 kommt im Netz eigentlich garnicht vor und ich kann mir nicht erklären was er von dieser IP will.

Snape · 3 Juli 2013

Die S7 ist Client und wenn Du ENQ_ENR = TRUE setzt, wird ein Auftrag losgeschickt. Wenn die Verbindung nicht aufgebaut ist, dann wird sie aufgebaut und das Telegramm gesendet. Was wird denn am STATUS-Ausgang angezeigt, wenn Du ein Telegramm losschickst?

drng · 3 Juli 2013

Genau so sollte es aussehen. Aber wenn die Verbindung nicht aufgebaut ist baut er sie auf ein ENQ_ENR hin einfach nicht auf. Ich bekomme auch garkeine 1 mehr am CONN_ESTABLISHED und die sollte vorraussetzung dafür sein Daten zu Senden. Wenn CONN_ESTABLISHED eine 1 führt und ich eine 1 auf ENQ_ENR lege bekomme ich das Telegramm übertragen und somit Daten zurück. Wenn CONN_ESTABLISHED aber garnicht 1 ist scheint er garnicht erst zu versuchen das Telegram zu starten.

Der MODBUS_STATUS sagt:

S7 ist Client: Es ist ein Auftrag angestoßen worden,
während der vorherige Auftrag noch läuft. Der Auftrag wird
nicht ausgeführt.

Kann es sein das er versucht einen Auftrag auszuführen, obwohl er noch garkeine Verbindung aufgebaut hat?

Snape · 3 Juli 2013

Diese Fehlermeldung kommt, wenn der Baustein denkt, dass er noch was tut, was aber nicht der Fall ist.
Welche Version hast Du denn? Aktuell ist die V2.4. Wenn Du eine ältere hast, dann lad Dir die V2.4 runter (www.siemens.de/s7modbus, Tab "Downloads"). Es gab mal eine Version, die blieb in einer bestimmten Fehlerkonstellation hängen.

drng · 3 Juli 2013

Momentan werden die Daten über einen 2 Sekunden takt abgefragt, also wird ENQ_ENR alle 2 Sekunden "1" gleichzeitig ist aber "BUSY" auch noch True und somit wird er versuchen eine neue verbindung herzustellen, wäre das möglich? Dann ist das aber denke ich nicht das Hauptproblem

//EDIT:

Version ist bereits V2.4

Snape · 3 Juli 2013

Also ENQ_ENR darf definitiv nicht gesetzt werden, wenn BUSY noch ansteht. Dann ist klar warum der Fehler kommt. Das musst Du abfangen.

Welche Version hast Du denn nun?

Lars Weiß · 3 Juli 2013

2 Sekunden für einen Response ist viel zu lange. Wie viele Daten fragst du denn ab ?

Step 7 MODBUSPN - OB100 neu aufrufen

Level-2

Level-3

Level-2

Level-3

Level-2

Level-2

Level-2

Forums-Knochenbrecher

Level-2

Forums-Knochenbrecher

Level-1

Level-2

Level-1

Level-2

Level-1

Level-2

Level-1

Level-2

Level-1

Level-3

Similar threads

Wir schützen deine Privatsphäre