Step 7 ET200S 1 Count 24V Lädt Wert erst nach mehreren Versuchen

Mare232

Level-2
Beiträge
20
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
Ich habe bei einer bestehenden Anlage die CPU getauscht von einer 314C 2DP auf eine 314C 2PN/DP. Das Profibusnetz blieb so wie es war. Der Ablauf funktioniert soweit wieder. Nur eine Sache funktioniert jetz nicht mehr. Ich habe 2 Drehgeber die sich eigentlich auf 0 Setzen sollen, sobald die Lichtschranke ein Werkstück erkennt. Dies hat bei der alten SPS auch gut funktioniert, durch eine einfache Ladefunktion mit Ladewert 0. Seit dem ich die neue SPS habe funktioniert dies nun nicht mehr. Erst nach x (mind 3) versuchen wird der Ladewert in das Modul geschrieben. Aber selbst wenn ich ohne Flanke arbeite funktioniert es erst nach mehreren Versuchen. Überseh ich etwas? Wo könnte hier das Problem sein? Ist die neue SPS zu schnell? Ist vielleicht die Historisch gewachsene Adressbelegung schuld?
Vom Counter Modul bekomme ich sogar die Rückmeldung, dass ein Wert geladen wird.

Das Busnetz
Busnetz.PNG

Die Parameter

Counter Parameter.PNG


Hier der Entsprechende Reset befehl
Code:
   L     L#0
      T     #Reset_Pos_QF1
      T     #Reset_Pos_Qf2

      U     "E_ini_QF1"
      FP    #fm0
      S     #Reset_QF1



      U     "E_ini_QF2"
      FP    #fm1
      S     #Reset_QF2




      CALL  "CounterAuswertung"
       CounterAdressEingang:=302
       CounterAdressAusgang:=292
       DB_Num              :=15
       reset               :=#Reset_QF1
       Load_Pos            :=#Reset_Pos_QF1
       Load_Pos_enable     :=FALSE
       Offset_mm           :=0.000000e+000
       Faktor              :=1.000000e+000
       Pos_Absolut         :=#Abs_QF1
       Pos_mm              :="DB_Kappsaege".Is_Pos_QF1

      O     "QF1_Counter".Querfoerderer1.Input.ERR_LOAD
      O     "QF1_Counter".Querfoerderer1.Input.STS_LOAD
      R     #Reset_QF1


      CALL  "CounterAuswertung"
       CounterAdressEingang:=310
       CounterAdressAusgang:=310
       DB_Num              :=16
       reset               :=#Reset_QF2
       Load_Pos            :=#Reset_Pos_Qf2
       Load_Pos_enable     :=FALSE
       Offset_mm           :=0.000000e+000
       Faktor              :=1.000000e+000
       Pos_Absolut         :=#Abs_QF2
       Pos_mm              :="DB_Kappsaege".Is_Pos_QF2

      O     "QF2_Counter".Querfoerderer2.Input.ERR_LOAD
      O     "QF2_Counter".Querfoerderer2.Input.STS_LOAD
      R     #Reset_QF2



Hier noch der Baustein der die Counter Verwaltet:
Code:
FUNCTION "CounterAuswertung" : VOID
TITLE =
VERSION : 0.1


VAR_INPUT
  CounterAdressEingang : INT ;   
  CounterAdressAusgang : INT ;   
  DB_Num : INT ;   
  reset : BOOL ;   
  Load_Pos : DWORD ;   
  Load_Pos_enable : BOOL ;   
  Offset_mm : REAL ;   
  Faktor : REAL ;   
END_VAR
VAR_OUTPUT
  Pos_Absolut : DWORD ;   
  Pos_mm : REAL ;   
END_VAR
VAR_TEMP
  temp_DB_num : WORD ;   
  temp_E_berreich : DWORD ;   
  temp_A_berreich : DWORD ;   
END_VAR
BEGIN
NETWORK
TITLE =


//Pointer Vorbereiten

      L     #CounterAdressEingang;
      ITD   ;
      SLD   3;
      T     #temp_E_berreich;

      L     #CounterAdressAusgang;
      ITD   ;
      SLD   3;
      T     #temp_A_berreich;

      L     #DB_Num;
      T     #temp_DB_num;


//Aufschlagen des DBs

      AUF   DB [#temp_DB_num];

//Steuerbits löschen
      L     0;
      T     DBD    0;
      T     DBD    4;

//SW-TOR öffnen
      SET   ;
      S     DBX    4.0;


NETWORK
TITLE =Set Val

      U     #reset;
      =     DBX    5.0;
      SPBN  m00;
      L     #Load_Pos;
      T     DBD    0;
m00:  NOP   0;




NETWORK
TITLE =Schreiben in Countermodul

      L     #temp_A_berreich;
      LAR1  ;

      L     DBD    0;
      T     PAD [AR1,P#0.0];

      L     DBW    4;
      T     PAW [AR1,P#4.0];



NETWORK
TITLE =Lesen Aus Countermodul

      L     #temp_E_berreich;
      LAR2  ;

      L     PED [AR2,P#0.0];
      T     DBD    8;

      L     PED [AR2,P#4.0];
      T     DBD   12;

      L     DBD    8;
      T     #Pos_Absolut;
      DTR   ;
      L     #Faktor;
      *R    ;
      L     #Offset_mm;
      +R    ;
      T     #Pos_mm;




END_FUNCTION
 
Moin, vielleicht liegt es an dem nicht konsistentem Schreiben?
Code:
NETWORK
TITLE =Schreiben in Countermodul

      L     #temp_A_berreich;
      LAR1  ;

      L     DBD    0;
      T     PAD [AR1,P#0.0];

      L     DBW    4;
      T     PAW [AR1,P#4.0];

Versuche es doch mal mit dem SFC15 DPWR_DAT
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin, vielleicht liegt es an dem nicht konsistentem Schreiben?
Code:
NETWORK
TITLE =Schreiben in Countermodul

      L     #temp_A_berreich;
      LAR1  ;

      L     DBD    0;
      T     PAD [AR1,P#0.0];

      L     DBW    4;
      T     PAW [AR1,P#4.0];

Versuche es doch mal mit dem SFC15 DPWR_DAT
Ich habe mich hierbei an die Empfehlung von Simens gehlaten. Hier nochmal ein Screenshot. Werde es Testhalber aber mal mit DPWR_Dat probieren1755693072304.png
 
Halten die Drehgeber extra an zum Nullen oder drehen die sich weiter? Ist Nullpunkt-setzen während Bewegung genau genug?

Ich lasse meine Drehgeber immer unbegrenzt endlos frei zählen und mache das Nullpunkt-setzen immer nur im Anwenderprogramm, indem ich den aktuellen Zählerstand als Referenzwert merke und von da an als Relativ-Position die Differenz verarbeite.
 
Halten die Drehgeber extra an zum Nullen oder drehen die sich weiter? Ist Nullpunkt-setzen während Bewegung genau genug?

Ich lasse meine Drehgeber immer unbegrenzt endlos frei zählen und mache das Nullpunkt-setzen immer nur im Anwenderprogramm, indem ich den aktuellen Zählerstand als Referenzwert merke und von da an als Relativ-Position die Differenz verarbeite.
Ich habe schon beides ohne Erfolg probiert. Die präzision passt sehr gut, wenn es denn Funktioniert. Die idee mit dem Referenzwert ist eine gute Lösung. Werde ich dann auch entsprechend so umsetzen, falls nicht doch noch jemand eine Lösung findet. Wundert mich aber warum das andere auf einmal nicht mehr funktioniert. Wie gesagt, vorher hat es einwandfrei geklappt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mich hierbei an die Empfehlung von Simens gehlaten...

Ist das jetzt das Originalprogramm, welches auf der alten CPU lief oder nicht?

Du hattest eingangs vermutet, dass die neue CPU zu schnell ist. Hast du mal testweise versucht, die Zykluszeit zu verlängern (z.Bsp. Schleife mit WAIT)? Ist der Handshake beim Reset vielleicht unzureichend, was bei einer größeren Zykluszeit nie aufgefallen war?
 
Ist das jetzt das Originalprogramm, welches auf der alten CPU lief oder nicht?

Du hattest eingangs vermutet, dass die neue CPU zu schnell ist. Hast du mal testweise versucht, die Zykluszeit zu verlängern (z.Bsp. Schleife mit WAIT)? Ist der Handshake beim Reset vielleicht unzureichend, was bei einer größeren Zykluszeit nie aufgefallen war?
Das ist das Originalprogramm. Inhaltlich wurde nichts verändert. Ich habe schon versucht das Resetsignal mithilfe einer Auschaltverzögerung zu verlängern, leider ohne erfolg.
 
Wo wird denn "Load_Pos" eigentlich in den DB geschrieben? DBD0 sind doch vermutlich Steuerbits? Kannst du einen der beiden DBs mal zeigen? Und "Load_Pos_enable" wird gar nicht verwendet? Ich würde sagen, da hat einer mitten im ... lustlos abgebrochen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also, der Kommentar von "STS_LOAD" und "ERR_LOAD", die beiden Statusbits mit denen der Resetbefehl zurückgesetzt wird, ist doch recht aufschlussreich. Ich würde jetzt mal den Resetbefehl nur mit der negativen Flanke von "STS_LOAD" zurücksetzen. Dann vielleicht noch ein TIME_OUT generieren, für den Fall dass gar keine Antwort kommt. Wenn es dann funktioniert, lag es an der Zykluszeit, dass der Fehler auf der alten CPU nicht zum Vorschein kam. Dagegen spricht allerdings, dass du den Resetbefehl schon verlängert hattest. Mal testweise die Zykluszeit verlängern hast du aber noch nicht probiert?

Aus "ERR_LOAD" würde ich erst einmal nur eine Fehlermeldung generieren und diese, falls sie denn auftritt, für weitere Tests auch zählen.
 
Vom Counter Modul bekomme ich sogar die Rückmeldung, dass ein Wert geladen wird.
Dieses Statusbit STS_LOAD wird auch für den Handshake gebraucht, weil der Profibus asynchron zum OB1 läuft. In welchem OB wird die "CounterAuswertung" aufgerufen?
Das Steuerbit LOAD_VAL (DBX5.0) (bzw. #Reset_QF1/#Reset_QF2) muss solange anstehen, bis das Statusbit STS_LOAD aktiv wird und darf erst dann wieder rückgesetzt werden.
siehe Handbuch ET 200S Technologische Funktionen Seite 79

Die Variablen #Reset_QF1, #Reset_QF2, #fm0, #fm1 sind nicht zufällig TEMP-Variablen? Die müssen in Speicher liegen, der sich was merken kann, z.B. STAT.

Ich würde die Größe der Prozessabbilder auf je 128 Bytes einstellen, so wie es in der Vorgänger CPU 314C-2DP war. Nicht dass womöglich das schreiben des PAA auf den Profibus irgendwie stört.
 
Also, der Kommentar von "STS_LOAD" und "ERR_LOAD", die beiden Statusbits mit denen der Resetbefehl zurückgesetzt wird, ist doch recht aufschlussreich. Ich würde jetzt mal den Resetbefehl nur mit der negativen Flanke von "STS_LOAD" zurücksetzen. Dann vielleicht noch ein TIME_OUT generieren, für den Fall dass gar keine Antwort kommt. Wenn es dann funktioniert, lag es an der Zykluszeit, dass der Fehler auf der alten CPU nicht zum Vorschein kam. Dagegen spricht allerdings, dass du den Resetbefehl schon verlängert hattest. Mal testweise die Zykluszeit verlängern hast du aber noch nicht probiert?

Aus "ERR_LOAD" würde ich erst einmal nur eine Fehlermeldung generieren und diese, falls sie denn auftritt, für weitere Tests auch zählen.
STS_LOAD bleibt bei mir aktiv, solange bei LOAD_VAL ein Signal anliegt. Ob das so seine richtigkeit hat, weiß ich nicht. Somit scheidet die negative Flanke leider schonmal aus. ERR_LOAD werde ich in Zukunft seperat erfassen. Zu einem Fehler kam es bis jetzt nicht, weil das mein HMI Protokoliert (Das konntet ihr natürlich nicht wissen). Ich werde jetz mal übergansweise PN/DPs vorschlag umsetzen und einfach einen Offset abspeichern. Damit sollte die Maschine wenigstens wieder laufen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dieses Statusbit STS_LOAD wird auch für den Handshake gebraucht, weil der Profibus asynchron zum OB1 läuft. In welchem OB wird die "CounterAuswertung" aufgerufen?
Das Steuerbit LOAD_VAL (DBX5.0) (bzw. #Reset_QF1/#Reset_QF2) muss solange anstehen, bis das Statusbit STS_LOAD aktiv wird und darf erst dann wieder rückgesetzt werden.

Die Variablen #Reset_QF1, #Reset_QF2, #fm0, #fm1 sind nicht zufällig TEMP-Variablen? Die müssen in Speicher liegen, der sich was merken kann, z.B. STAT.

Ich würde die Größe der Prozessabbilder auf je 128 Bytes einstellen, so wie es in der Vorgänger CPU 314C-2DP war. Nicht dass womöglich das schreiben des PAA auf den Profibus irgendwie stört.
Ein enstprechender Handshake wird von mir auch durchgeführt. Aktuell läuft das Programm im OB1. Evtl. schieb ich das ganze in einen OB3x. Die Variablen sind STAT. Ich kann den Entsprechenden FB gerne hier hochladen. Ist leider nur sehr groß und unübersichtlich. Ich habe auch noch Counter an anderer stelle(Andere ET200S) hier ist das Problem das selbe. Ich werde mal Testweise das PA ändern.
 
Kann es evtl. sein, dass noch Code in einem ZeitOB verarbeitet wird ( z.b. OB35 ). Da du die CPU getauscht ( direkter Tausch in der HW Konfig geht ja in der Konstellation vermutlich nicht ) hast stehen die Aufrufzeiten der Zeit OBs wieder auf Werkseinstellung ( in den CPU Eigenschaften ).
 
Kann es evtl. sein, dass noch Code in einem ZeitOB verarbeitet wird ( z.b. OB35 ). Da du die CPU getauscht ( direkter Tausch in der HW Konfig geht ja in der Konstellation vermutlich nicht ) hast stehen die Aufrufzeiten der Zeit OBs wieder auf Werkseinstellung ( in den CPU Eigenschaften ).
Ich habe den entsprechenden OB35 direkt beim Umbau angepasst. Dieser übernimmt aktuell die Regelung von 6 Servoachsen, hat aber mit den Drehgeber nichts zu tun. Die Achsregelung funktioniert. Hier werden 6 SSI Geber angesprochen, ohne Probleme.
 
Zurück
Oben