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

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aktuell läuft das Programm im OB1. Evtl. schieb ich das ganze in einen OB3x.

Aufruf im OB1 ist OK, das würde ich so lassen. Das macht ja quasi ein E/A-Prozessabbild der Zähler für das Programm im OB1. Die zum Zähler gehörenden FC "CounterAuswertung" werden nur einmal im OB1 aufgerufen?
In dem gezeigten Code des FC und des aufrufenden FB sehe ich keine Fehler.

Warum es trotz Handshake LOAD_VAL + STS_LOAD zu Fehlern beim Nullsetzen/Laden der Zählerstände kommt, kann ich in dem Programm nicht sehen. Und habe auch keine Erfahrungen, was dabei schiefgehen kann, weil ich meine Zähler immer ungestört laufen lasse und das Setzen der Nullpunkte rein im Anwenderprogramm mache.

Macht vielleicht der Rest des Programms ungewollte (evtl. indirekte?) Schreibzugriffe auf die Peripherieadressen der Zähler?
Gibt es evtl. Schreibzugriffe auf "DB_Kappsaege".Is_Pos_QF..?
Was hat es mit dem FC-Input "Load_Pos_enable"auf sich? Der wird anscheinend nicht verwendet?
Und behält der FC-Input "Load_Pos" seinen Wert, solange #Reset_QF1/#Reset_QF2 aktiv sind? Können das verschiedene Werte sein oder sind die immer 0?
Wird manchmal ERR_LOAD aktiv? Wird immer STS_LOAD aktiv bei LOAD_VAL?

 

[JoopB]

Ich habe etwas in einem Programm gefunden, bei dem Load_Val einen Zyklus später zurückgesetzt wird, als STS_LOAD hoch ist. Im Kommentar heißt es:
//einen Zyklus verzögert, sodass der Zählerwert definitiv geschrieben wird (niemand weiß warum)

/
//een cyclus vertraagd waardoor tellerwaarde zeker geschreven wordt (Niemand weet waarom)

      U     #Flank
      R     #StuurInterface.LOAD_VAL

      U     #TerugmeldInterface.STS_LOAD
      U     #StuurInterface.LOAD_VAL
      S     #Flank

      UN    #TerugmeldInterface.STS_LOAD
      UN    #StuurInterface.LOAD_VAL
      R     #Flank

 

[Lipperlandstern]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine Flankenmerker liegen nicht zufällig im Temp-Bereich ?

 

[JoopB]

Neen. Im STAT Bereich. Mit meiner FB geht das ohne Probleme in alle 300 CPUs
Auch met eine 319F.

 

[Mare232]

Deine Flankenmerker liegen nicht zufällig im Temp-Bereich ?

Nein, wie berreits erwähnt habe ich es auch ohne Flanke getestet, mit dem selben ergebnis.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du mal @JoopB seine Variante getestet?

 

[Mare232]

Ich habe etwas in einem Programm gefunden, bei dem Load_Val einen Zyklus später zurückgesetzt wird, als STS_LOAD hoch ist. Im Kommentar heißt es:
//einen Zyklus verzögert, sodass der Zählerwert definitiv geschrieben wird (niemand weiß warum)

/
//een cyclus vertraagd waardoor tellerwaarde zeker geschreven wordt (Niemand weet waarom)

      U     #Flank
      R     #StuurInterface.LOAD_VAL

      U     #TerugmeldInterface.STS_LOAD
      U     #StuurInterface.LOAD_VAL
      S     #Flank

      UN    #TerugmeldInterface.STS_LOAD
      UN    #StuurInterface.LOAD_VAL
      R     #Flank

Vielen Dank JoopB,
Ich habe das genau so getestet. Jetzt klappt es bei jedem Versuch. Ich habe auch getestet 2 Zyklen zu warten -> Hat nicht mehr funktioniert. Anscheinend gibt es wirklich ein Timing-Problem mit der Quitierung. Wie berreits erwähnt hatte ich es anfangs auch mal mit einer Auschaltverzögerung probiert, selbst da hat es nicht funktioniert. Man darf anscheinend werder zu schnell, noch zu langsam sein. Komisch ist nur, das es bei der alten CPU immer geklappt hat.

 

[DeltaMikeAir]

Das ist halt das schöne an dem Forum. Da hat irgendjemand ein ganz spezielles Problem und dann kommt jemand anderer der irgendwo anders in Deutschland, der EU oder noch weiter weg sitzt und kennt genau die Lösung für das Problem und man findet zusammen.

 

[Mare232]

Zuviel Werbung?
-> Hier kostenlos registrieren

//(Niemand weet waarom) kommt aufjedenfall mit in die Dokumentation.

 

[Onkel Dagobert]

Moin, vielleicht liegt es an dem nicht konsistentem Schreiben?...

@Mare,
könntest du bitte noch verraten, wie die Konsistenz der Datenblöcke konfiguriert ist?

 

[A3Q]

Vielen Dank JoopB,
Ich habe das genau so getestet. Jetzt klappt es bei jedem Versuch. Ich habe auch getestet 2 Zyklen zu warten -> Hat nicht mehr funktioniert. Anscheinend gibt es wirklich ein Timing-Problem mit der Quitierung. Wie berreits erwähnt hatte ich es anfangs auch mal mit einer Auschaltverzögerung probiert, selbst da hat es nicht funktioniert. Man darf anscheinend werder zu schnell, noch zu langsam sein. Komisch ist nur, das es bei der alten CPU immer geklappt hat.

Wenn ich mir das Timing-Diagramm anschaue (S.62 im Handbuch), sieht es schon danach aus, dass LOAD_VAL und STS_LOAD einen Zyklus zusammen HIGH sind, bevor LOAD_VAL zurückgenommen wird. Quasi genau so wie @JoopB das mit seinem Code macht.




Hier nochmal das Handbuch:
https://cache.industry.siemens.com/...functions_operating_instructions_de_de-DE.pdf


-chris

 

[Mare232]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich mir das Timing-Diagramm anschaue (S.62 im Handbuch), sieht es schon danach aus, dass LOAD_VAL und STS_LOAD einen Zyklus zusammen HIGH sind, bevor LOAD_VAL zurückgenommen wird. Quasi genau so wie @JoopB das mit seinem Code macht.

Anhang anzeigen 90198


Hier nochmal das Handbuch:
https://cache.industry.siemens.com/...functions_operating_instructions_de_de-DE.pdf


-chris

Das stimmt, aber im Diagram sind keine Zyklen abgebildet, desshalb macht es für mich keinen Sinn das nur der 1. Zyklus nach STS_Load als Quitierung funktioniert.

 

[Mare232]

@Mare,
könntest du bitte noch verraten, wie die Konsistenz der Datenblöcke konfiguriert ist?

Ich weiß leider nicht genau was du meinst. Das schreiben erfolgt in 2 Schritten. 1. Ladewert wird über PED geschrieben. 2. Steuerbefehl werden mit PEW übertragen. Die Quelle sind DBs (für jeden Counter ein eigener DB) die vom FB beschrieben werden. Die DBs werden nur an einer stelle Zyklus angepasst. Ich schreibe nicht mithilfe von DPWR_DAT, weil bei https://support.industry.siemens.com/cs/mdm/45977588?c=18760023691&lc=de-DE steht das 3xxc CPUs auch ohne SFC 15/14, aus den Coutnermodul, lesen und schreiben können(Fußnote).

 

[A3Q]

Das stimmt, aber im Diagram sind keine Zyklen abgebildet, desshalb macht es für mich keinen Sinn das nur der 1. Zyklus nach STS_Load als Quitierung funktioniert.

Ja die Zyklen sind nicht wirklich (gut) abgebildet, da gebe ich dir recht.
Vergleicht man das aber mit dem Diagramm auf der Seite davor, kann man aber erahnen was im gleichen, oder im Zyklus danach passiert.



Diese Auffällig große Lücke im Diagramm der Ladefunktion kann schon als 1 zusätzlicher Zyklus interpretiert werden meiner Meinung nach. Am Ende auch egal, Hauptsache es funktioniert nun

-chris

 

[Mare232]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wollte noch eine Entdeckung ergänzen:
Taktsynchronität ist bei mir deaktiviert. Dennoch errinert diese Quittierungschema sehr stark an die Aktuelle Lösung.
Ob hier ein zusammenhang besteht?

 

[Onkel Dagobert]

Ich weiß leider nicht genau was du meinst...

Ah ok, wenn man aus dem Siemens-Katalog projektiert, dann hat man gar nicht die Konsistenz-Wahl. Diese Unterscheidung gibt es wohl nur über eine GSD-Datei. Dann passt das.

 

[PN/DP]

macht es für mich keinen Sinn das nur der 1. Zyklus nach STS_Load als Quitierung funktioniert.

Für mich auch nicht.
Das ist eher ein typisches Zeichen dafür, dass der Rest des Anwenderprogramms nicht gut und vollständig(!) Multitasking/Handshake-gerecht programmiert ist (*). Oder Signale in einer "ungünstigen" Programmreihenfolge ausgewertet und verändert werden und man deshalb extra sicherstellen muss, dass Signalzustände garantiert (mindestens) 1 kompletten Programm-Zyklus lang sind, damit jeder Programmteil alle Signaländerungen mitbekommt, egal ob er vor oder nach dem Signaländerungs-Programmteil ausgeführt wird.

Hier im Programm (und vermutlich auch bei der "Niemand weiß warum"-Lösung) wird beim Handshake mit dem 1Count24V-Modul nicht ausgewertet/gewartet, dass das Statussignal Input.STS_LOAD = 0 ist, bevor das Steuersignal Output.LOAD_VAL gesetzt wird. Dadurch kann es passieren, dass das 1Count24V-Modul die Aktivierung des Output.LOAD_VAL nicht als neue Aktivierung mitbekommt oder das Output.LOAD_VAL gar nicht erst über Profibus gesendet wird, wenn es vor dem nächsten Buszyklus schon wieder rückgesetzt wird. Wer weiß, was sonst noch ungenau programmiert ist, was nicht auffällt wenn der Programmzyklus länger dauert als der Profibus-Zyklus.

Wie war die OB1-Zykluszeit mit der alten CPU? Wie war da bei den Profibus-Busparametern die "Ttr typisch" (ms)?
Wie ist die OB1-Zykluszeit mit der neuen CPU? Wie ist bei den Profibus-Busparametern die "Ttr typisch" (ms)?


(*) Wie z.B. bei Schrittketten: wenn man da innerhalb eines Zyklus Schritte aktiviert und gleich wieder deaktiviert, dann bekommt das Programm außerhalb dieses Programmteil nicht mit, dass der Schritt kurz aktiviert war. Oder der Klassiker: wenn S7-Timer ohne Merk-Hilfsvariable sich direkt selbst rücksetzen/neu starten und das Restprogamm das Reset/Neustart des Timers daher nicht mitbekommt.