Step 7 S7 Timer Problem

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Simulationsdaten-FC:
UN M 77.0
SPBN nix
...

Ich persönlich finde diese doppelten Verneinungen einfach nur schrecklich. :shock:
Die beiden Negationen kann man doch auch gegeneinander wegkürzen und schon muss man beim Lesen des Codes nicht mehr dreimal um die Ecke denken.

Ja, das sieht auf den ersten Blick verwirrend aus. Doch da sollte man sich dran gewöhnen. Ich formuliere auch meist die Bedingung so, daß der bedingte Code bei Zutreffen der Bedingung ausgeführt wird, und wenn die Bedingung nicht zutrifft dann wird mit SPBN der Code übersprungen.

Außerdem entspricht die Formulierung der Bedingung so exakt der Formulierung wie sie bei IF angegeben würde:

IF T7 AND NOT M77.0 THEN
  tuwas()
END_IF

entspricht

     U    T7
     UN   M77.0
     SPBN nix

     CALL tuwas

nix: NOP 0

Aufwendiger und schlechter verstehbar wäre der Code, wenn man die Bedingung nach dem durchdenken noch extra negiert formulieren müßte, damit man mit SPB drüberweg springen kann (und hier im Beispiel ist noch nichtmal eine Klammer dabei):

     ON   T7
     O    M77.0
     SPB  nix

     CALL tuwas

nix: NOP 0

Also ich würde auch bei nur einzeiligen Bedingungen die beiden NOT nicht gegeneinander wegkürzen.

Harald

 

[jule]

Ich persönlich finde diese doppelten Verneinungen einfach nur schrecklich. :shock:
Die beiden Negationen kann man doch auch gegeneinander wegkürzen und schon muss man beim Lesen des Codes nicht mehr dreimal um die Ecke denken.

Also ich tu mich deutlich schwerer dabei, den Code zu lesen, wenn die Negationen weggestrichen werden würden...

So ich hab nun ein neues Problem. Habe gestern das Programm fertig gestellt und eine Weile durchlaufen lassen. Nach 30 Minuten ging die CPU in Stop mit folgendem Fehlercode:

STOP durch Zeitfehler (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden)
Unterbrechungstelle im Anwenderprogramm: Weckalarm-OB (OB 35)
Prioritätsklasse: 12
FC-Nummer: 1
Bausteinadresse: 36
Bisheriger Betriebszustand: RUN
Angeforderter Betriebszustand: STOP (intern)
interner Fehler, kommendes Ereignis
08:23:31.073 21.02.2014
(Kodierung: 16# 4568 FF84 8C70 0C23 0001 0024)

Dabei habe ich in meinem Programm gar kein OB35...
Habe dennoch mal geschaut welche Aufrufzeit für den OB35 definiert ist... sind standartmäßig 100ms... Sollte doch mehr als genug sein für mein sehr kleines Programm...

außerdem tritt der Fehler ja nicht sporadisch auf, sondern wirklich nur nach genau 30 min... das kommt ein wenig komsich vor...

Habt ihr irgendeine Idee, was dahinterstecken könnte?

Im Anhang mal mein Programm. Und ja, richtige Zufallszahlen sind das jetzt nun auch nicht, aber reicht für unsere Zwecke.

Anhang anzeigen Zufallsgen_Energiedaten.zip

EDIT:
einfach mal den OB35 eingefügt und nichts reingeschrieben... jetzt läuft das Programm ohne Fehler seit knapp 35 min...

Ich versteh das zwar alles nicht wirklich, aber hauptsache es funktioniert. Anscheinend muss ich mich nochmal mit den Weckalarmen auseinandersetzen. So ganz kapieren tu ich das gerade nicht, was da das Problem war!

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist Dein Programm in der CPU gleich dem Offline-Programm? Alle Bausteine gleich? Hardwarekonfig geladen und gleich?
Verwendet Dein Programm die SFC39..SFC42?

In der CPU ist/war ganz sicher kein OB35 vorhanden?
Dann könnte die Meldung eventuell ein Firmwarefehler sein, ich vermute daß eigentlich eine Zykluszeitüberschreitung gemeint ist, aber die Unterbrechungsstelle falsch angegeben ist.
Welche CPU mit welcher Firmware hast Du?

Hast Du mal auf die Zykluszeit-Statistik geschaut? Gibt es vor/nach dem zitierten Diagnosepuffereintrag weitere Einträge mit etwa dem selben Zeitpunkt?

Ich habe mal Dein Programm überflogen und kann keinen Zusammenhang zwischen dem Stop und OB35 finden.
Aber einige Kritikpunkte:
- FC1 Gefahr einer Endlosschleife und Zykluszeitüberschreitung: ungeprüft unbegrenzt viele Rücksprünge zur Marke "neu"
Falls bei der Zufallszahlenberechnung tatsächlich ein Fehler auftreten sollte, dann würde ich einfach t_Untergrenze als Ergebnis (Zufallszahl) zurückgeben
Irgendwo im Internet habe ich schonmal einen anderen Zufallsgenerator gesehen, weiß aber nicht mehr wo...
- FC10 verwendung von nichtinitialisierten TEMP-Variablen, z.B. das S von #sonntag, #samstag, #werktag müssen = sein. (der weit verbreitete Denkfehler "Setze einen Wert" führt häufig zu unvollständiger und/oder unnötig komplizierter Logik)
- M77.0 wird an undurchsichtig vielen Stellen beschrieben, für den freilaufenden Generator darf er aber nur noch am T7 beschrieben werden (U T7 | = M77.0)

Wenn der Aufruf des Zufallsgenerators von einem Timer gesteuert wird und der Zufallsgenerator den selben Zeitgenerator auswertet, dann ist der Zufallsgenerator nicht mehr "unabhängig". Es kann passieren, daß bestimmte "Zufälle" nie vorkommen bzw. nur noch bestimmte Zufälle.

Harald

 

[jule]

Ist Dein Programm in der CPU gleich dem Offline-Programm? Alle Bausteine gleich? Hardwarekonfig geladen und gleich? Verwendet Dein Programm die SFC39..SFC42? In der CPU ist/war ganz sicher kein OB35 vorhanden?

Ich hatte vorher ein ziemlich großes Programm eingespielt, dabei trat zuerst der Fehler auf. Da war der OB35 und die besagten SFCs enthalten. Da aber die SPS schon vorher immer mal vollkommen ausgelastet war, entschied ich mich, den Zufallsgenerator in ein einzelnes Programm zu schreiben.
Habe dann die CPU urgelöscht und das Programm samt HW-Konfig so geladen wie ich es hier hochgeladen habe. Da trat dann der Fehler erneut auf. Dann habe ich einfach einen leeren OB35 eingefügt, alle Bausteine auf die CPU geladen und dann funktionierte es...

Welche CPU mit welcher Firmware hast Du?

Siemens S7-400, CPU 416-3 DP V3.1, 6ES7 416-3XL00-0AB0

Hast Du mal auf die Zykluszeit-Statistik geschaut? Gibt es vor/nach dem zitierten Diagnosepuffereintrag weitere Einträge mit etwa dem selben Zeitpunkt?

Nein, da habe ich nun leider nicht nach geschaut!

Aber einige Kritikpunkte:

Danke für die Anmerkungen! Habe ich gleich einmal geändert.
Der Zufallsgenerator ist im übrigen eine stark abgespeckte Version, die ich hier im Forum gefunden habe.

Wenn der Aufruf des Zufallsgenerators von einem Timer gesteuert wird und der Zufallsgenerator den selben Zeitgenerator auswertet, dann ist der Zufallsgenerator nicht mehr "unabhängig". Es kann passieren, daß bestimmte "Zufälle" nie vorkommen bzw. nur noch bestimmte Zufälle.

Das ist mir durchaus bewusst. Deshalb meine Anmerkung, dass es keine wirklich zufälligen Zahlen sind. Für unsere Testzwecke sollte dies aber auch genügen.


Mittlerweile habe ich den OB35 wieder gelöscht und ließ das Programm noch einmal durchlaufen. Innerhalb von 35min kein Fehler aufgetreten. So langsam zweifle ich an mir selbst . Ich glaub, es wird Zeit, das Wochenende wird. :!: Werd das Programm mal bis zum Feierabend durchlaufen lassen und schauen ob es wirklich fehlerfrei läuft.