TIA S7-300 ET200sp Modbus CM

vollmi

Level-3
Beiträge
5.433
Reaktionspunkte
1.409
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi zusammen

Ich versuche mich das erste mal an den ET200sp CM für Freeport und R3964.
Erstmal wollte ich es mit ET200sp und Modbus RTU probieren.

Ich hab mal ein kleines Beispielprogramm zusammengestiefelt. Aber laufen tut es leider noch überhaupt nicht.
https://www.dropbox.com/sh/cvgv46rnp71k1x0/AAA7SThEDro2aajZcybGrfnha?dl=0

Code:
FUNCTION_BLOCK "Modbus_Serial"{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
   VAR_INPUT 
      ID : Word;
      Port : Int;
   END_VAR


   VAR 
      Req : Bool;
      Disconnect : Bool;
      Reset { S7_HMI_Accessible := 'False'; S7_HMI_Visible := 'False'} : Bool;
      ResetTimer {OriginalPartName := 'TON'; LibVersion := '1.0'} : TON;   // Resettimer wenn Req zu lange ansteht, wird dieser Resetiert
      Zaehler : Int;
      R_TRIG_error : "Trigger";
      R_TRIG_Done : "Trigger";
      AktuellerLDB : Int;
      Status_Save : Word;
      ReqTrigger : "Trigger";
      Daten : Array[0..50] of Int;
      ErrTimer {OriginalPartName := 'TON'; LibVersion := '1.0'} : TON;   // Wenn Error länger als 3s ansteht werden Werte auf 0 gesetzt.
      Modbus_Master {OriginalPartName := 'Modbus_Master'; LibVersion := '2.3'} : Modbus_Master;
      Modbus_Comm_Load_Instance {OriginalPartName := 'Modbus_Comm_Load'; LibVersion := '3.0'} : Modbus_Comm_Load;
      Requestcount : Int;
   END_VAR


   VAR_TEMP 
      index : Int;
      RET_val : Int;
   END_VAR


   VAR CONSTANT 
      Datenlaenge : Int := 20;
   END_VAR




BEGIN
	        #Modbus_Comm_Load_Instance.RETRIES := 4;
	        #Modbus_Comm_Load_Instance.MODE := 4; // 4 für Halbduplex RS485 Zweidraht
	        #Modbus_Comm_Load_Instance.BAUD := 9; // 9 für 57600
	        #Modbus_Comm_Load_Instance.LINE_PRE := 0; // Keine Vorbelegung
	        #Modbus_Comm_Load_Instance.PARITY := 2; // Gerade
	        #Modbus_Comm_Load_Instance.FLOW_CTRL := 0; // keine
	        #Modbus_Comm_Load_Instance.STOP_BITS := 1; // 1 Stopbit
	        #Modbus_Comm_Load_Instance.RTS_OFF_DLY := 10; // 10ms
	        #Modbus_Comm_Load_Instance.RTS_ON_DLY := 10; // 10ms
	        #Modbus_Comm_Load_Instance.RESP_TO := 3000; // 3s auf Antwort warten
	        #Modbus_Comm_Load_Instance."PORT" := INT_TO_WORD(#Port); // Port w#16#100 im Test
	        
	        "Tag_2" := NOT #Modbus_Comm_Load_Instance.COM_RST;
	        
	        #Modbus_Comm_Load_Instance(REQ:="Tag_2",
	                                   MB_DB:=#Modbus_Master.MB_DB);
	        
	        #Modbus_Master(REQ:="Tag_3", // Hier #Req anschliessen wenn nicht im Test
	           MB_ADDR:=#ID,
	                        MODE:=0,
	                        DATA_ADDR:=40001,
	                        DATA_LEN:=5,
	           DATA_PTR:=#Daten);
	
	
	#ErrTimer(IN:=#Modbus_Master.ERROR,
	          PT:=t#3s);
	
	
	#Req := (#Modbus_Master.ERROR OR #Modbus_Master.DONE) AND NOT (#Modbus_Master.BUSY OR #Reset);
	
	#ResetTimer(IN:=#Req,
	            PT:=t#10s,
	            Q=>#Reset);
	
	IF #Modbus_Master.ERROR THEN
	    #Status_Save := #Modbus_Master.STATUS;
	    
	END_IF;
END_FUNCTION_BLOCK

Ich Initialisiere den Load im OB100. Und sobald dieser den COM_RST zurücksetzt wird der Req des Load aktiviert und bleibt gesetzt.
Soweit alles okay.

Wenn ich jetzt aber den Req des Modbus Masters setze. Geht die CPU in Stop und zwar mit einer nicht wirklich nachvollziehbaren begründung.

4 von 10; Ereignis-ID: 16# 4562
STOP durch Programmierfehler (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden )
FB-Nummer: 613
Bausteinadresse: 210
Bisheriger Betriebszustand: RUN
Angeforderter Betriebszustand: STOP (intern)
02.05.2016 14:04:05.664




5 von 10;
Ereignis-ID: 16# 2522
Bereichslängenfehler beim Lesen
P-Bereich , Doppelwortzugriff, Zugriffsadresse: 65535
Angeforderter OB: Programmierfehler-OB (OB 121)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
02.05.2016 14:04:05.660

Jemand ne Idee was das sein kann? Ich wüsste gerne woher dieser Zugriff auf 65535 kommen kann? übergebe ich da irgendeinen Scheiss?
FB613 ist der Send_P2P den die Siemensbibliothek einbindet wenn man die Modbus Bildbibliothek nutzt.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Doch das Dokument kenn ich. Nach dem Arbeite ich auch. Nur wiederspricht das Dokument schon in der s7-1500 der TIA-Hilfe die man im TIA beim Auswählen des Bausteins geliefert bekommt. z.B. Baudrate. In der Hilfe steht
Baudrate zulässige Werte: s7-1200/1500 int := 300,600,1200 etc.
Baudrate zulässige Werte: s7-300/400 Word := 300,600,1200 etc.
Handbuch s7300/400 Word := 1,2,3,4 für 300,600,1200etc.

mfG René
 
Jemand ne Idee was das sein kann? Ich wüsste gerne woher dieser Zugriff auf 65535 kommen kann? übergebe ich da irgendeinen Scheiss?
FB613 ist der Send_P2P den die Siemensbibliothek einbindet wenn man die Modbus Bildbibliothek nutzt
Eine Variante wäre sowas....
Code:
      L     0
      +     -1
      SLD   3
      LAR1
      L PEW [ AR1 , P#0.0 ]
65535 ist auch W#16#FFFF.
Wenn ich dein Beispiel in den Simulator lade, die CPU starte und den "Tag_3" auf True setze, dann steht in folgenden Variablen...
  • "Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.MB_DB.S_PORT
  • "Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.Send_P2P."PORT"
  • "Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.Send_P2P.OldPORT
  • "Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.Send_P2P.WRREC.ID
... der Wert W#16#FFFF.

Grad beim WRREC-Baustein kann FFFF sicher nicht stimmen, auch der PORT am P2P-Eingang mit FFFF passt auch vermutlich nicht.
Du könntest eventuell mal in diese Richtung suchen.
 
Das Problem scheint irgendwo bei der Initialisierung zu liegen.
Wenn ich den deinen Code in den Simulator spiele und die CPU auf RUN schalte bleibt
"Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.MB_DB.S_PORT = W#16#FFFF.
Das ist nämlich lustigerweise der Startwert im IDB.

Wenn ich einfach so ne Zeile bei der ModBus_Comm_Load hinten dran hänge...
Code:
#Modbus_Comm_Load_Instance(REQ:="Tag_2",
                                   MB_DB:=#Modbus_Master.MB_DB
        );
        "Modbus_holen_DB".Modbus_Serial_Instance.Modbus_Master.MB_DB.S_PORT :=  #Modbus_Comm_Load_Instance."PORT";
... also den Port selbst noch lade, dann kann ich den "Tag_3" (Modbus_Master.REQ) auf high setzen und ich hab keine Diagnosereignisse am Simulator mehr.
Das müsstest du halt mal mit der Hardware nachprüfen.

Das Problem scheint also beim Modbus_Comm_Load zu sein
Code:
#Modbus_Comm_Load_Instance(REQ:="Tag_6",
                                   MB_DB:=#Modbus_Master.MB_DB
        );
        IF #Modbus_Comm_Load_Instance.DONE THEN "Tag_4" := True; END_IF;
        IF #Modbus_Comm_Load_Instance.ERROR THEN "Tag_5" := True; END_IF;
        IF #Modbus_Comm_Load_Instance.ERROR  THEN
            "Tag_7" := #Modbus_Comm_Load_Instance.STATUS;
        END_IF;
Wenn ich den Status auswerte wird nachdem ich "Tag_6" einmal auf low/high setze auch das Error-Bit ("Tag_5") high und in "Tag_7" landet DW#16#8181.
Prüf mal bei dir nach ob du zum selber Ergebnis kommst, wenn ja, dann sollte der Fehlercode Aufschluss darüber geben warum Modbus_Comm_Load nicht richtig tut.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen

Danke Ronin. Ich wär ja heut nach fast nochmal ins Büro gefahren um das mit Hardware auszutesten.

Es schein mindestens zwei Probleme zu geben. Die Init geht offenbar nicht durch die ganze instanz inkl. Modbus_Master.
Also deinen Tip hinzugefügt und den Port nochmal im programm bei der Instanz von Modbus_Master eingetragen. (eigentlich ja übler Pfusch)
Hat aber noch nicht ganz hingehauen. Das zweite hat bei mir auch Fehler W#16#8181. Welcher falsche Baudrate bedeutet.
Also Baudrate entgegen dem Handbuch als 57600 direkt eingetragen.

Jetzt geht
#Modbus_Comm_Load_Instance.COM_RST ohne fehler
#Modbus_Comm_Load_Instance.Req ohne Fehler
#Modbus_Master.Req ebenfalls ohne fehler.

Es trägt also keiner mehr einen Status mit Error ein. Aber trotzdem wird kein Telegramm abgesetzt wenn ich einen Req an Modbus_Master setze.

Kann natürlich sein das ich einen Verdrahtungsfehler habe. Aber zumindest müsste doch ne negative Quittierung zurückkommen.

Ich habe Das Programm auf der Dropbox aktualisiert.

mfG René
 
Zuletzt bearbeitet:
Ich kämpfe grad mit dem gleichen Problem; allerdings bin ich schon einen Schritt weiter, Telegramme gehen raus, aber ich bekomme keine Antwort vom Slave.
Erst habe ich auch kein Telegramm raus bekommen, das lag bei mir an einer falschen Base-Unit, die muss mit A0 enden.
 
Jetzt kriege ich auf einmal negative Quittierungen vom Modul (Fehler 0x8280) wenn ich den Req des Modbus_Master auslöse.

Die Base-Unit habe ich eine A0 also mit Einspeisung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weil ich den Status 8280 bekomme werte ich den RDREC aus wie im Handbuch beschrieben.
Allerdings schmeisst dieser keine Statusänderung. Ich komme langsam zum schluss, dass das wieder so ne halbgare Sache ist was die da gebastelt haben.

mfG René
 
So, ich kontaktiere jetzt mal den Support - die Einstellungen der Schnittstelle passen nicht. Die Karte ist in der HW-Konfig auf RS485 eingestellt, senden tut der Sauhund aber auf der RS232. In der Instanz vom Modbus_Comm_Load steht in MODE auch eine 0 und keine 4, das bestätigt meine Vermutung. Vielleicht passen die Bausteine für die 1500, aber nicht für die ET200SP...
 
So der Fehler kommt offenbar vom Receive_P2P.WRREC.status Der erhält einen 16#DE80_B100. Das bedeutet ja eigentlich das die Länge des zu übertragenden Datensatzes zu gross ist.
Aber das kann ja nun wirklich nicht aus meinen übergabeparametern resultieren oder?

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In der Instanz vom Modbus_Comm_Load steht in MODE auch eine 0 und keine 4, das bestätigt meine Vermutung.

Die HW konfig wird ignoriert. Du musst das alles über die Instanz des Load machen. DU bist dafür verantwortlich was in der Instanz steht. Zumindest in der obersten Ebene von IN/INOUT/STAT.

Das ist eben das was mich schon zum kotzen brachte. HW wird komplett ignoriert. Aber man konfiguriert nicht über IN oder INOUT des Load sondern sowohl an IN wie auch an STAT der Instanz. Auf so einen Blödsinn muss man erstmal kommen.

mfG René
 
Zuletzt bearbeitet:
Die HW konfig wird ignoriert. Du musst das alles über die Instanz des Load machen. DU bist dafür verantwortlich was in der Instanz steht. Zumindest in der obersten Ebene von IN/INOUT/STAT.

Das ist eben das was mich schon zum kotzen brachte. HW wird komplett ignoriert. Aber man konfiguriert nicht über IN oder INOUT des Load sondern sowohl an IN wie auch an STAT der Instanz. Auf so einen Blödsinn muss man erstmal kommen.

mfG René

Funktioniert nicht. Haben wir probiert. Bin mal gespannt was S dazu sagt.
 
Da bin ich aber gespannt. Hab Siemens bis jetzt nicht angesprochen weil ich sie noch verwirrt hab stehen lassen mit meiner Anfrage für 400H und ET200sp und modbusmodule ;)
Lassen wir den Tread offen. Ich probier mal weiter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab jetzt auch mal die Hardware so konfiguriert wie die Physik aufgebaut ist. Leider kriege ich immer noch keinerlei Telegramm geworfen.
Ich bekomme auch vom #Modbus_Master.Receive_P2P.RDREC.STATUS den DE 80 B1 00 zurück.

  • bei Datensatz lesen: B#16#DE
  • B#16#80 DPV1 Fehler nach IEC 61158-6 (DPV1 bei Profinet?)
  • B1
write length error Die Längenangabe im Parameter RECORD ist falsch;
bei "RALRM": Längenfehler in AINFO,
bei "RDREC" und "WRREC": Längenfehler in MLEN

Lars versuchst du es auch per Profinet ET200sp oder hast du eine Profibusanschaltung?

mfG René
 
Nein, ich habe eine 1512SP-1PN. Funktioniert auch mittlerweile. Lag an einem falschen Wert in den statischen Parametern.
 
Achso. Ja auf der 1500er hab ich auch schon erste erfolge gehabt. Aber auf der 300er scheint es gröbere Fehler in den Bausteinen zu haben.
Ich mach mir etwas sorgen. Denn ich will den Baustein ja nachher in ne 400H portieren, also zurück nach Step7 welches ja grundsätzlich dieselbe Bibliothek benutzt. Aber vermutlich wieder 400er Typische Stolperstellen hat welche von den Siemensproggern nicht beachtet wurden.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab jetzt noch etwas bei der 1500er weitergemacht. Leider hänge ich da auch grad. Bzw. mein ModbusMaster Baustein hängt.
Busy ist gesetzt und bleibt gesetzt. weder ein erneuter Req löst was aus, noch ein neuer Modbus_Load.

Irgendwann müsste doch irgendein Timeout zuschlagen und das Busy entfernen und meinetwegen einen Error setzen. So hat man ja keine Chance eine neue Anforderung zu erstellen.

mfG René
 
Guten Abend zusammen, hat denn jemand die Lösung zum Problem gefunden?
Bei mit bleibt beim Modbus_Master FB641 auch das Bit BUSY stehen mit dem Status W#16#7002 wenn ich das Bit REQ setze und es blinkt kurz Tx auf dem Modul. Was mache ich falsch?

Hab ez mal noch den Status ausgewertet, da ich bemerkt habe, dass das Error Bit wenn ich COM_RST setze um aus dem Teufelskreis heraus zu kommen, für einen Zyklus lang ansteht und dabei der Fehlercode 81E2 ausgespuckt wird.
Dieser laut Handbuch ja sagt, dass an den Hardwareeinstellungen was nicht stimmen soll... Habe jetzt noch mal Baudrate 19200 mit den Slave's und die Parität Gerade abgeglichen... Sollte passen, aber warum gibts keine Einstellungsmöglichkeit für das Stoppbit?
 
Zuletzt bearbeitet:
Zurück
Oben