# OB35, s7-CPU314: Einstellung 10ms funzt nicht, 50ms geht sehr gut



## mega_ohm (19 Oktober 2008)

*Liebe Gemeinde,*

anlehnend an das von mir beschriebene Problem http://www.sps-forum.de/showthread.php?t=22786

(die CPU- Einstellungen in der HW-Konfig.... das hat super funktioniert >>)
Danke an vierlagig 

habe ich noch folgende Fragen:

- Ich habe das Progi noch einmal 'umgefrickelt'....
NEU: => Meine DB- Aufrufe wollte ich im 10ms- Bereich über den OB35 realisieren. (dafür benötige ich keine IDB's mehr... das Progi wird einfacher lesbar). 
Bsp.:

```
[SIZE=1]// Referenzzähler setzen KD1 [/SIZE]
[SIZE=1]U E 3.5 // und KD "Ini oben" (Zähler Reset)[/SIZE]
[SIZE=1]R M 20.3 // wenn Ini_oben, dann Software-Endschalter rücksetzen[/SIZE]
 
[SIZE=1]U A 15.0 // SR-Merker "KD ab"[/SIZE]
[SIZE=1]U E 3.5 // und KD "Ini oben" (Zähler Reset)[/SIZE]
 
[SIZE=1]SPBN ZS_1 // Z-ähler S-etzen 1[/SIZE]
[SIZE=1]L 0 // Referenzzähler Reset[/SIZE]
[SIZE=1]T DB 1.DBW8 // Zähler schreiben[/SIZE]
[SIZE=1]SPA RzE1 // und Sprung zu R-echne z-ähl En-de1[/SIZE]
 
[SIZE=1]ZS_1: U A 15.0 // SR-Merker "KD ab"[/SIZE]
[SIZE=1]UN E 3.5 // und NICHT "Ini oben" (Zähler Reset)[/SIZE]
[SIZE=1]SPBN RzE1[/SIZE]
 
[SIZE=1]L DB 1.DBW8 // Lade Zähler[/SIZE]
[SIZE=1]L DB 1.DBW26 // obere Zählergrenze laden, um Zählerüberlauf zu vermeiden[/SIZE]
[SIZE=1]>=I[/SIZE]
[SIZE=1]= M 20.3 // Endschalter setzen, max. Ende ist erreicht[/SIZE]
[SIZE=1]U M 20.3[/SIZE]
[SIZE=1]SPB RzE1 // wenn Zähler >= Zähler_Max., dann nix mehr inkrementieren [/SIZE]
 
[SIZE=1]L DB 1.DBW8 // Lade Zähler[/SIZE]
[SIZE=1]L 1 // inkrementieren[/SIZE]
[SIZE=1]+I [/SIZE]
[SIZE=1]T DB 1.DBW8 // Referenzzähler schreiben[/SIZE]
 
[SIZE=1]// Zähler lernen [/SIZE]
[SIZE=1]U E 2.6 // Bedingungen für Start "Ref_Zähler übernehmen"[/SIZE]
[SIZE=1]U E 2.0[/SIZE]
[SIZE=1]UN E 3.5[/SIZE]
[SIZE=1]UN M 20.3[/SIZE]
[SIZE=1]SPBN RzE1[/SIZE]
[SIZE=1]L DB 1.DBW8 // Ref_Zähler laden[/SIZE]
[SIZE=1]T DB 1.DBW0 // Rückgabewert schreiben[/SIZE]
[SIZE=1]SRW 1 // WORD nach rechts schieben => Division / 2[/SIZE]
[SIZE=1]T DB 1.DBW18 // und Ergebnis schreiben[/SIZE]
 
[SIZE=1]RzE1: NOP 0[/SIZE]
```
Das steht in 4 NW's für 4 KD's in OB35 => und fertig ! 

Die min. Zykluszeit war lt. Diagnose: 5 ms
Die max. Zykluszeit war lt. Diagnose: 23 ms
Die mittlere Zykluszeit war lt. Diagnose: 9 ms ???
(Mittelwert lt. meiner Rechnung: 14ms)

Ich dachte, der OB35 würde unabhängig der Zykluszeit aufgerufen.
(vergleichbar mit Interupt- Routinen, wie ich sie von Assembler kenne)

Das Ergebnis nach dem Aufruf von OB35 mit 10ms: (ich verstehe es einfach nur noch nicht)
Das Progi funzte mal 1h... 2h... mal nur 30sec lang.... Irgendwann
war die CPU gestoppt.

Seitdem ich den Weckalarm (OB35) auf 50ms eingestellt habe(Zwischenlösungen habe ich nicht getestet !), läuft die Sache stabil.

Meine Fragen:
- Hat die Zykluszeit doch etwas mit den WeckAlarm- OB's zu tun ?( vor allem die Zeit des OB- Aufrufs mit dem 'normalen' Progi- Ablauf )
- Muß man die Zykluszeit beachten?
  Wenn JA...  Was ist für eine sichere Funktion des Progis die richtige Einstellung für den OB35 ?

 Mfg


----------



## Rainer Hönle (19 Oktober 2008)

Die mittlere Zykluszeit ist nicht der Mittelwert aus minimaler und maximaler Zykluszeit sondern eher der Ducrhschnitt aller Zyklsuzeiten (wie dies Siemens in der SPS berechnet, weiss ich nicht).
Was ist die genaue Stopursache? Was steht im Diagnosepuffer? Was in den Stacks? 
Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist und durch den mehrfachen Aufruf des OB35 imnnerhalb eines Zykluses dann zuschlägt? Steht aber dann im Diagnosepuffer.


----------



## jabba (19 Oktober 2008)

Schon mal unabhängig welcher Fehler enststanden ist (Diagnosepuffer), bekommst Du ein Problem, weil dein OB eventuell zweimal aufgerufen wird in einem OB1 Zyklus. Dadurch greift du aber zweimal auf das gleiche Prozessabbild zu, welches sich natürlich nicht geändert hat.

Wenn Du wirklich so eine kurze Rate haben willst, solltest Du im Code das Prozessabbild aktualisieren.


```
L PEW 2 // aktualisieren Eingänge
T EW2
....
L AW  14 // Zählerausgang
T PAW 14
```


----------



## Matthias_aus_AT (19 Oktober 2008)

*Laufzeit des OB 35*

Hallo,

bin nicht sicher ob es so sein kann aber:
Was passiert wenn die Laufzeit des OB 35 selbst mehr als 10sec in Anspruch nimmt - vielleicht immer dann wenn umfangreichere Aktionen/ Berechnunge notwendig werden oder viele Werte in die DB's geschrieben werden.
Hierfür würde sprechen das das Problem sporadisch auftritt.
Die Abarbeitung müsste dann innerhalb des OB 35- Durchlauf unterbrochen werden um Ihn neu zu starten - das wird nicht gehen !!!

Gruß MMM


----------



## mst (19 Oktober 2008)

Hi,
aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:

```
Hinweis
Sie müssen dafür sorgen, dass die Laufzeit jedes Weckalarm-OB deutlich
kleiner ist als sein Zeittakt. Falls ein Weckalarm-OB noch nicht beendet ist,
aber wegen des abgelaufenen Zeittakts erneut zur Bearbeitung ansteht,
wird der Zeitfehler-OB (OB 80) gestartet. Anschließend wird der Fehler
verursachende Weckalarm nachgeholt.
```


----------



## Larry Laffer (19 Oktober 2008)

Hallo,
um dein Programm "sauber" zu bekommen würde ich auf jeden Fall jeden der gemachten Vorschläge beachten. In der Reihenfolge :
Vorschlag *Jabba*, Vorschlag *Matthias* / *MST*.

Das gezeigte Netzwerk (auch wenn es 4mal da ist) sollte eigentlich nicht einen zweiten Einsprung in den OB35 ermöglichen (geschätzt) während der erste noch läuft (so was Schlimmes ist da nun auch nicht drin programmiert).

Wie schon von Rainer beschrieben wird der OB35 vollkommen unabhängig vom OB1-Zyklus ausgerufen - bei der Berechnung der Gesamt-Zykluszeit des Programms schlägt er natürlich mit zu Buche.

Aber eine andere Frage:
Muß das gezeigt Programmteil überhaupt im Zeit-OB laufen ? Reicht es nicht aus, wenn du es im OB1 (oder in einem von dort gestarteten FC) hinterlegt hast ?

Ach ja:
Zu deiner letzten Frage (alle anderen sind m.E. schon beantwortet) :
Das richtige Intervall für den OB35 legst du mit deiner Anwendung fest. Beispiel :
Ich nutze den OB35 um Messwerte für eine Kurve aufzuzeichnen. Hier möchte ich z.B. alle 5ms einen neuen Messwert speichern. Das ist dann meine Anwendung und somit das von mir benötigte Intervall ...

Gruß
LL


----------



## mega_ohm (20 Oktober 2008)

Rainer Hönle schrieb:


> Die mittlere Zykluszeit ist nicht der Mittelwert aus minimaler und maximaler Zykluszeit sondern eher der Ducrhschnitt aller Zyklsuzeiten (wie dies Siemens in der SPS berechnet, weiss ich nicht).


 Rein rechnerisch ist die "mittlere Zykluszeit" nicht nachvollziehbar.
Zumindest nicht mit einer 'normalen' Durchschnitts- Berechnung


> Was ist die genaue Stopursache? Was steht im Diagnosepuffer? Was in den Stacks?
> Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist
> und durch den mehrfachen Aufruf des OB35 imnnerhalb eines Zykluses dann zuschlägt? Steht aber dann im Diagnosepuffer.


Das kann ich alles erst heute ab 14.00 Uhr herausfinden (wenn ich neben der Großreparatur an dieser Anlage noch Zeit dafür habe).
Ich hatte am "lebenden Objekt mit offener Wunde" gearbeitet. Danach kamen noch 2 andere "Baustellen" und dann der Feierabend.
Auf Grund dessen, das die Anlage am Mo und Di noch (wg. Reparatur) steht, habe ich mich mit der Diagnose dann nicht mehr beschäftigt... das muß ich nachholen.



> Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist...


Finde ich die Einstellungen für die Zykluszeit- Überwachung auch in der HW- Konfig ? 

Bis spätestens Ende dieser Woche werde ich die Fragen beantworten können.

mfg


----------



## mega_ohm (20 Oktober 2008)

jabba schrieb:


> Schon mal unabhängig welcher Fehler enststanden ist (Diagnosepuffer), bekommst Du ein Problem, weil dein OB eventuell zweimal aufgerufen wird in einem OB1 Zyklus.


Wieso wird der OB35 eventl. 2x aufgerufen ?
Ich war bisher, nach vielen Suchen und Recherchen, der Meinung, daß der OB35 unabhängig von der Zykluszeit zeitgesteuert (CPU- Takt / Taktteiler) ist ?
Ist mein Verständnis für diese Sache falsch ? Dann bitte ich um Links...
mehr Input.


> Wenn Du wirklich so eine kurze Rate haben willst, solltest Du im Code das Prozessabbild aktualisieren.


Theoretisch würde für diese Aufgabe ein Takt= 50ms auch ausreichen.
Praktisch ist es natürlich so, daß umso mehr Zähldurchgänge (10ms statt 50ms) durchlaufen werden, umso genauer positioniert werden kann.

Ich habe (mit 50ms) bei 30 Arbeitszyklen eine Fehlerqoute von 3mm gemessen. Das ist eigentlich für diese Sache mehr als ausreichend, zumal dieser Fehler auch noch durch hydraulische (es wird ein Hydraulikventil gesteuert) Probleme (Konsistenz bei Temp.-Änderungen) verursacht werden könnte.

Aber unabhängig von diesem jetzigen Problem steht ja für mich das *Verständnis* um den Aufruf dieses OB35. Beim Suchen im www oder auch hier im Forum findet man viel VIEL zu diesem Thema, aber nix Konkretes.

______________________________________________________________


> ```
> L PEW 2 // aktualisieren Eingänge
> T EW2
> ....
> ...


Für dig. Eingänge lädst Du ein PEW ?
Ich dachte bisher....  (PEW,PAW =analog  )
Ich setze mich morgen nochmal auf die "Schulbank"

Mfg


----------



## mega_ohm (20 Oktober 2008)

Matthias_aus_AT schrieb:


> Hallo,
> 
> bin nicht sicher ob es so sein kann aber:
> Was passiert wenn die Laufzeit des OB 35 selbst mehr als 10sec in Anspruch nimmt - vielleicht immer dann wenn umfangreichere Aktionen/ Berechnunge notwendig werden oder viele Werte in die DB's geschrieben werden.
> ...


Diese Idee hatte ich auch. Deshalb habe ich die Aufrufzeit auf 50ms erhöht.


----------



## mega_ohm (20 Oktober 2008)

mst schrieb:


> Hi,
> aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:
> 
> ```
> ...


Ich glaube, daß diese Aussage für mich einkomplettes Umdenken bedeutet.

In Assembler sichert man die Register, manipuliert danach, ruft einen Interrupt auf und schreibt die gesicherten Register danach zurück.
Ich war bisher der Meinung, daß der Aufruf eines zeitgesteuerten OB's mir alle anderen Sorgen (Sichern, Zurückschreiben) abnehmen würde.
Das scheint wohl ein Irrtum zu sein.

Wie finde ich denn heraus, wie groß der benötigte Zeittakt für den Weckalarm ist ?
Steht das dann im OB80 ?
Und um das Ganze noch weiter auszudehnen...
Reicht es aus, den OB121 einfach nur aufzurufen ( mit nix drinnen ), um das leidige CPU-Stop zu maskieren ?

mfg


----------



## mega_ohm (20 Oktober 2008)

Larry Laffer schrieb:


> Hallo,
> um dein Programm "sauber" zu bekommen würde ich auf jeden Fall jeden der gemachten Vorschläge beachten. In der Reihenfolge :
> Vorschlag *Jabba*, Vorschlag *Matthias* / *MST*.
> 
> Das gezeigte Netzwerk (auch wenn es 4mal da ist) sollte eigentlich nicht einen zweiten Einsprung in den OB35 ermöglichen (geschätzt) während der erste noch läuft (so was Schlimmes ist da nun auch nicht drin programmiert).


Der Meinung bin ich auch



> Wie schon von Rainer beschrieben wird der OB35 vollkommen unabhängig vom OB1-Zyklus ausgerufen - bei der Berechnung der Gesamt-Zykluszeit des Programms schlägt er natürlich mit zu Buche.
> 
> Aber eine andere Frage:
> Muß das gezeigt Programmteil überhaupt im Zeit-OB laufen ? Reicht es nicht aus, wenn du es im OB1 (oder in einem von dort gestarteten FC) hinterlegt hast ?


Ich sage mal einfach JA (es muß im Zeit-OB laufen), weil ich schon einige andere Sachen ausprobiert habe (u.a. Deinen Vorschlag)  und mir nix Anderes mehr einfällt.
... alle anderen Maßnahmen waren nicht genau genug.
Abweichungen von bis zu 45cm waren das Ergebnis...
Und vor allen Dingen:  Jeder neue Arbeitsgang brachte scheinbar zufällig andere Positionen.
Mit dieser Methode ist das nicht so.

Ich werde mich diese Woche nochmal ans "Gerät" hängen, die Diagnosedaten sichern, nebenbei noch ein paar Bücher lesen...  und hier fragen

mfg


----------



## Rainer Hönle (20 Oktober 2008)

mega_ohm schrieb:


> Rein rechnerisch ist die "mittlere Zykluszeit" nicht nachvollziehbar.
> Zumindest nicht mit einer 'normalen' Durchschnitts- Berechnung


Doch. Zwei Werte merken: Die Summe der Zykluszeiten und die Anzahl der Zyklen. Ersten mit jedem Zyklus aufsummieren und zweiten inkrmentieren. Die mittlere Zykluszeit ist dann nur Wert1 / Wert2. Es sind dabei natürlich die entsprechenden Maximalwerte zu beachten.



> Finde ich die Einstellungen für die Zykluszeit- Überwachung auch in der HW- Konfig ?


Ja.



> Wieso wird der OB35 eventl. 2x aufgerufen ?


Wenn ein Zyklus mehr als 10 ms dauert und der OB 35 alle 10 ms aufgerufen wird, dann wird unter Umständen in einem Zyklus der OB35 zweimal aufgerufen. Bei mehr als 20 ms Zykluszeit dann mindestens zweimal.



> Ich war bisher, nach vielen Suchen und Recherchen, der Meinung, daß der OB35 unabhängig von der Zykluszeit zeitgesteuert


Er wird unabhängig von der Zykluszeit aufgerufen. Deshalb kann es ja sein, dass er mehrfach im Zyklus aufgerufen wird.



> Ich dachte bisher.... (PEW,PAW =analog  )


PEW = Peripherieeingangswort
PAW = Peripherieausgangswort
Wird immer dann verwendet, wenn direkt auf Peripherie zugegriffen werden soll oder die gewünschte Adresse nicht mehr im Prozessabbild liegt. Früher (= S5) waren dies in der Regel die Analogwerte.

Grundsätzlich gilt: Analyse und Behebung der Ursache (Stoppgrund) und nicht nur Behebung der Symptome. Sonst bleibt unklar, ob und wann der Fehler wieder zuschlägt.


----------



## Larry Laffer (20 Oktober 2008)

... noch mal zu dem Vorschlag von *Jabba* (alles andere hat Rainer ja schon beantwortet ) :

Wie von Rainer schon gesagt lädt der OB1 für die Standard-E/A das Prozess-Abbild. Der OB35 partizipiert in deinem Fall nur davon. Willst du dein Programm "sauber" bekommen, dann solltest du (um dem Fall eines möglichen längeren OB1-Zyklus vorzubeugen) dir im OB35 ggf. die Perepherie selbst laden und auf die benötigten Eingänge transferieren bzw. die verwendeten Ausgänge aus Perepherie schreiben. Achtung hierbei : das erhöht die Bearbeitungszeit deines OB35-Durchlaufs nicht unerheblich ... du kannst aber möglicherweise deine Reaktionszeiten minimieren.

Das Ganze erklärt den Stop deines Programms aber in keiner Weise - es sei denn die Zyklus-Überwachungszeit ist sehr knapp eingestellt. Umzustellen ist das unter HW-Konfig-CPU-Zyklus/Taktmerker und dann die genannte Position. Hier sollte in deinem Fall m.E. kein Wert unter 50 ms drin stehen (Default ist 150 ms).

Gruß
LL


----------



## mega_ohm (22 Oktober 2008)

Rainer Hönle schrieb:


> Wenn ein Zyklus mehr als 10 ms dauert und der OB 35 alle 10 ms aufgerufen wird, dann wird unter Umständen in einem Zyklus der OB35 zweimal aufgerufen. Bei mehr als 20 ms Zykluszeit dann mindestens zweimal.
> 
> Er wird unabhängig von der Zykluszeit aufgerufen. Deshalb kann es ja sein, dass er mehrfach im Zyklus aufgerufen wird.


Das leuchtet mir ein.
Würde ein doppelter Aufruf des OB35 in einem Zyklus den CPU- Stopp begründen oder "nur" meine Zähler verfälschen ?

Ich habe heute noch mal in die Diagnose geschaut... leider steht nix Brauchbares mehr drin. Die Stopps und Wiederanläufe, die da vermerkt sind, sind durch das Speichern auf ROM und MMC zurückzuführen. Leider werden bloß max. 10 Einträge gelistet. (Es war eingestellt: Vorgabe durch CPU). Kann ich den Diagnosepuffer (so wie angezeigt ) einfach auf 100 erhöhen ? Der Speicher ist zu 22% belegt.



> PEW = Peripherieeingangswort
> PAW = Peripherieausgangswort
> Wird immer dann verwendet, wenn direkt auf Peripherie zugegriffen werden soll oder die gewünschte Adresse nicht mehr im Prozessabbild liegt. Früher (= S5) waren dies in der Regel die Analogwerte.


Also muß ich mich da doch genauer reinlesen.



> Grundsätzlich gilt: Analyse und Behebung der Ursache (Stoppgrund) und nicht nur Behebung der Symptome. Sonst bleibt unklar, ob und wann der Fehler wieder zuschlägt.


Der Meinung bin ich auch. Vor Allem hat man, solange die Anlage läuft, Zeit, sich zu informieren, zu suchen/ prüfen. Dann findet man meist auch eine Lösung, den Fehler (der ja meist irgendwann wieder zuschlägt ) vorher auszumerzen.


----------



## mega_ohm (22 Oktober 2008)

Larry Laffer schrieb:


> ... noch mal zu dem Vorschlag von *Jabba* (alles andere hat Rainer ja schon beantwortet ) :
> 
> Wie von Rainer schon gesagt lädt der OB1 für die Standard-E/A das Prozess-Abbild. Der OB35 partizipiert in deinem Fall nur davon. Willst du dein Programm "sauber" bekommen, dann solltest du (um dem Fall eines möglichen längeren OB1-Zyklus vorzubeugen) dir im OB35 ggf. die Perepherie selbst laden und auf die benötigten Eingänge transferieren bzw. die verwendeten Ausgänge aus Perepherie schreiben. Achtung hierbei : das erhöht die Bearbeitungszeit deines OB35-Durchlaufs nicht unerheblich ... du kannst aber möglicherweise deine Reaktionszeiten minimieren.
> 
> ...


Ich habe den OB35 auf 50ms eingestellt. Das reicht für diese Anwendung vollkommen.
Die Zyklus- Überwachungszeit müßte ich morgen noch kontrollieren. Ich habe sie aber nicht geändert, also müßte sie noch auf dem Default- Wert stehen.


----------



## Rainer Hönle (22 Oktober 2008)

mega_ohm schrieb:


> Das leuchtet mir ein.
> Würde ein doppelter Aufruf des OB35 in einem Zyklus den CPU- Stopp begründen oder "nur" meine Zähler verfälschen ?


Einen CPU-Stopp nur, wenn durch die Bearbeitung des OB35 die Zyklsuzeit des OB1 überschritten wird. Dieser wurde ja unterbrochen aber seine Zeit läuft weiter.


----------



## rostiger Nagel (22 Oktober 2008)

Hallo mega_ohm,
schon einmal daran gedacht eine CPU einzusetzen die ein wenig mehr Leistung hat....?
So das du auf den OB35 verzichten kannst.

gruss Helmut


----------



## Longbow (22 Oktober 2008)

mega_ohm schrieb:


> *Liebe Gemeinde,*
> 
> 
> Die min. Zykluszeit war lt. Diagnose: 5 ms
> ...





Die S7-SPS gibt keinen Mittelwert, sondern den Wert des letzten Durchgangs + min + max an.

Der Stop-Grund wäre schon sehr interessant, wobei ich hier auch empfehlen würde, eine leistungsfähigere CPU einzusetzen.
Die 314C gehört zu den ganz langsamen! Da kriegt man auch ganz andere Compact-CPUs.


----------



## mega_ohm (24 Oktober 2008)

Longbow schrieb:


> Der Stop-Grund wäre schon sehr interessant,...


Ich habe ( aus Produktionsgründen ) gehofft, es 1-2 Tage später nachvollziehen zu können... und ich hatte Pech.
Ich habe mir mit meiner 'Daten-Sicherheits'- Wut meine eigenen Fehler (in der History) gelöscht. (Sichern auf ROM, MMC mit allen Start / Stopps)

Ob man den Diagnosepuffer beliebig erweitern kann ??? : 
Ich hatte gefragt und keine Antwort bekommen. ( Dann hätte ich wenigstens für die Zukunft die Möglichkeit, Fehler innerhalb einer Woche, auszulesen und in der E- Werkstatt zu analysieren... 


> .... wobei ich hier auch empfehlen würde, eine leistungsfähigere CPU einzusetzen.
> Die 314C gehört zu den ganz langsamen! Da kriegt man auch ganz andere Compact-CPUs.


*Diese CPU *hat seit 4 Jahren ihren Dienst getan.
An sich macht dieser Teil einer kompletten Fertigungslinie heute eigentlich nichts anderes, als vor 4 Jahren.
Das Problem ist, daß die Produktionslinie immer mehr auf Geschwindigkeit getrimmt wurde... in der Testphase der Anlage waren 120 Takte/min schon richtig gut... heute produziert diese Anlage knapp vor 300 Takten/min.
Das bedeutet, daß ein Arbeiter früher ca. 7,5 min Zeit für einen Produktionsstrang ( es sind immer schon 2 Stränge gewesen, die eine Person bewerkstelligen mußte ) hatte, heute hat er nicht einmal die Hälfte der Zeit mehr... da kommt es tatsächlich (auch ich habe das nie geglaubt) auf jede Sekunde an.
Nur dafür habe ich mich mit dem Progi nochmal beschäftigt... und _*automatische*_ Produktions-teilabläufe, die ich vor 1 jahr noch für äußerst bedenklich hielt, revidiert. Die Gefahrenanalyse unserer Sicherheits- Ing(e) erfahre ich demnächst.

Danach werde ich sicher nochmal hier und da 'rumwerkeln' müssen.

Eine neue CPU halte ich für diese Aufgabe: Mit Kanonen auf Spatzen geschossen.

Ich glaube auch niemals daran, das man sich für jede kleine Änderung einer Anlage einen Kopf um die Hardware machen muß. Meine Lieblings- Masch.Bau- Firma hat 1994 eine Anlage mit einer s5 verkauft. Irgendwie haben 'wir' (also die Firma, in der ich angestellt bin) diese Anlage erstanden. Zum Jahreswechsel erfolgt eine 'Anpassung' dieser Anlage... und die s5 bleibt vorerst drinn !

Wenn ich mir was für diese Anlage wünschen dürfte... es wäre keine andere CPU sondern eine HMI.
Ein klitzekleines OP3 oder ähnliches würde schon reichen, um Fehlermeldungen in Klartext anzuzeigen und verschiedene Eingaben zu tätigen. Das würde mir etliche 'Handstände' ersparen und die Anlage für mehrere Benutzer 'persönlich' anpassen.

mfg


----------



## mega_ohm (24 Oktober 2008)

Rainer Hönle schrieb:


> Einen CPU-Stopp nur, wenn durch die Bearbeitung des OB35 die Zyklsuzeit des OB1 überschritten wird. Dieser wurde ja unterbrochen aber seine Zeit läuft weiter.


Seit ich ( das ist für diese EINE!! spezielle Anwendung völlig ausreichend ) den OB35 auf 50ms gesetzt habe, funktioniert alles perfekt.

Ich hatte ja geschrieben, daß ich mein Progi- Bsp. *4x *im OB35 mit anderen Eingängen und anderen DB's bearbeite.
Bisher gibt es keine Stopps, keine Fehler, kein Nix... mehr. ( nur pure Freude bei den Bedienern ).

Ich möchte mich für die Teilnahme, Überlegungen, Denkanstösse etc. noch einmal bedanken.

Mfg


----------



## rostiger Nagel (24 Oktober 2008)

Hallo Mega_ohm,
schön wie du schreibst das du die Anlage immer weiter optimiert hast.

...es kommt auf jede Sekunde an, das kann heißen das es bei deiner CPU auf jeder ms. ankommt. Da kann eine solche CPU schnell an grenzen kommen...oder....?

gruss Helmut


----------



## Larry Laffer (24 Oktober 2008)

Hallo,
ich würde mich hier auch der Meinung von Helmut anschliessen. Es könnte u.U. sein, dass du durch den Einsatz der nächst-stärkeren CPU (in dem Fall wäre das eine 317) nicht nur mehr Performannce für den OB35 gewinnst ...
Da kannst du ja mal drüber nachdenken ...

Gruß
LL


----------



## Longbow (24 Oktober 2008)

Larry Laffer schrieb:


> Hallo,
> ich würde mich hier auch der Meinung von Helmut anschliessen. Es könnte u.U. sein, dass du durch den Einsatz der nächst-stärkeren CPU (in dem Fall wäre das eine 317) nicht nur mehr Performannce für den OB35 gewinnst ...
> Da kannst du ja mal drüber nachdenken ...
> 
> ...



Genau an dieser Stelle zwingt einem Siemens auf, den kompletten Aufbau zu ändern! In der Anlage steckt ja eine 314C!

An dieser Stelle wäre es von Vorteil, wenn man diese CPU rausnehmen könnte, eine Neue rein, die Konfiguration und die Stecker beibehalten und die Performance auf 319 level haben. Wäre schön, oder?

(Ab jetzt ganz klein geschrieben:
Wenn man nicht zuviele FMs einsetzt gibt es schon sowas!)


----------



## mega_ohm (26 Oktober 2008)

Reparatur schrieb:


> Hallo Mega_ohm,
> schön wie du schreibst das du die Anlage immer weiter optimiert hast.
> 
> ...es kommt auf jede Sekunde an, das kann heißen das es bei deiner CPU auf jeder ms. ankommt. Da kann eine solche CPU schnell an grenzen kommen...oder....?
> ...


Das Progi funzt jetzt perfekt....

Ich glaube nicht, (Glauben ist nicht = Wissen !!! ) daß die CPU jemals für diese Anwendung ein Problem sein wird.

Eines Tages könnte es sein, daß mein Progi im ms- Bereich angesiedelt werden muß.
Ich bin aber überzeugt davon, daß ich diese Forderung nicht mehr erleben werde.
_______________________________________________________________

Zusammenfassend möchte ich schreiben, daß mir hier sehr viel geholfen wurde. 

*Danke an ALLE *

Ich bin aber auch der Meinung, daß mein Problemchen jetzt "gegessen" ist.
Es wurde alles geschrieben, ich habe reagieren können, meine Wissenslücken entdeckt.... Jetzt muß ich mich hinhocken und lernen !

Ich weiß nicht, ob es üblich ist, daß jemand (außer dem Admin ) ein Thema schließt.... ich möchte es heute mal versuchen.

Mfg


----------



## mega_ohm (26 Oktober 2008)

Larry Laffer schrieb:


> Hallo,
> ich würde mich hier auch der Meinung von Helmut anschliessen. Es könnte u.U. sein, dass du durch den Einsatz der nächst-stärkeren CPU (in dem Fall wäre das eine 317) nicht nur mehr Performannce für den OB35 gewinnst ...
> Da kannst du ja mal drüber nachdenken ...
> 
> ...


Hmmm... ich hatte ( vorhergehend, in diesem Strang) gefragt, ob der OB35_ *richtig*_ zeitgesteuert oder zyklusgesteuert ist.
Dann wäre es m.M. nämlich unerheblich, welche CPU mit welcher Zykluszeit werkelt.
Millisekunden sind = Millisekunden ! << Egal, welche CPU dahinter hängt.
_____________________________________________________________

Bei der nächsten Hardware- Planung, bei der meine Erkenntnise und Meinung gefragt sein könnten... werde ich all die Erkenntnisse, die ich aus diesem Strang erworben habe, mitnehmen.
Leider werde ich nicht gefragt, sondern mit "Tatsachen betraut" ... Jeder Elt- Instandhalter wird mir da sicher zustimmen.

Mfg


----------



## mega_ohm (2 Dezember 2008)

Das Progi hat bis vergangene Woche Donnerstag so funktioniert, wie ich es mir gewünscht hatte.
Dann trat wieder das Problem "CPU in Stop" auf. ( Aufruf des OB35 alle 50ms, Zykluszeit min: 3 ms, max.: 8 ms )
Aus Zeitgründen wurde die CPU von einem Kollegen "nur" neu gestartet... 4h später wieder das Gleiche.
Ich habe mich dann in der Nachtschicht mal dafür interessiert, was denn in der Diagnose so geschrieben steht und staunte nicht schlecht:
"Zugriff auf OB35 verweigert, OB35 nicht vorhanden" 
In die Stacks konnte ich nicht reinschauen, weil die Anlage schnellstmöglich ( ich hatte die SPS dann mal urgelöscht und von der MMC laden lassen) wieder laufen mußte. Die Stacks kann man aber nur während des CPU-Stopps anschauen.
Die genaue Fehlermeldung versuche ich diese Woche noch hier 'hochzuladen', weil ich diesen Fehler nun gar nicht erwartet hätte.
Wie schon geschrieben, lief das Progi wochenlang fehlerfrei... und seit dem Urlöschen bis heute auch wieder. ( Die Anlage läuft im 3-Schicht- Betrieb) 

Was kann das für ein Problem sein ? (ich versteh's nicht )

Mfg


----------



## Larry Laffer (2 Dezember 2008)

Hallo,
deine Frage läßt sich m.E. nicht so einfach beantworten ...
Hat sich (hast du) am Aufbau des OB35 etwas geändert ?
Pauschal sieht es so aus, als wenn mit deinen Pointern irgendetwas schief läuft. Vielleicht rettest du am Anfang des OB35 mal das AR1 und das AR2 und schreibst es am Ende desselben wieder zurück. Auch würde mich dein OB35 nochmal interessieren ...

Gruß
LL


----------



## Longbow (2 Dezember 2008)

Hallo,

ich würde es in dem Fall auch mal mit einem Firmwareupdate der CPU probieren!
Da gab es im letzten Jahr einige Änderungen bei SIEMENS
(Die Beschreibung der Änderungen ist da sehr aufschlussreich!).







mega_ohm schrieb:


> Das Progi hat bis vergangene Woche Donnerstag so funktioniert, wie ich es mir gewünscht hatte.
> Dann trat wieder das Problem "CPU in Stop" auf. ( Aufruf des OB35 alle 50ms, Zykluszeit min: 3 ms, max.: 8 ms )
> Aus Zeitgründen wurde die CPU von einem Kollegen "nur" neu gestartet... 4h später wieder das Gleiche.
> Ich habe mich dann in der Nachtschicht mal dafür interessiert, was denn in der Diagnose so geschrieben steht und staunte nicht schlecht:
> ...


----------



## mega_ohm (3 Dezember 2008)

Larry Laffer schrieb:


> Hallo,
> deine Frage läßt sich m.E. nicht so einfach beantworten ...
> Hat sich (hast du) am Aufbau des OB35 etwas geändert ?
> Pauschal sieht es so aus, als wenn mit deinen Pointern irgendetwas schief läuft. Vielleicht rettest du am Anfang des OB35 mal das AR1 und das AR2 und schreibst es am Ende desselben wieder zurück. Auch würde mich dein OB35 nochmal interessieren ...
> ...


So, wie ich den OB35 zu Beginn dieses Themas hier eingestellt habe, ist er geblieben.

Das Retten von AR1 u. AR2 würde so aussehen ?

```
LAR 1 // Mit dieser Operation ... Adressregister1 oder 2 beschicken. Sie
            kann auch ohne Operand verwendet werden. 
LAR 2
.. Programmcode
TAR 1
TAR 2 // Adressregister wird in den angegeben Operanden transferiert.
            Wenn keiner angegeben ist, in den Akku 1.
```
 
Oder geht das anders ?


----------



## mega_ohm (3 Dezember 2008)

Longbow schrieb:


> Hallo,
> 
> ich würde es in dem Fall auch mal mit einem Firmwareupdate der CPU probieren!
> Da gab es im letzten Jahr einige Änderungen bei SIEMENS
> (Die Beschreibung der Änderungen ist da sehr aufschlussreich!).


Ein Firmware- Update an einer CPU habe ich bisher noch nie gemacht. Wie groß ist die Möglichkeit, daß die CPU nach dem Update gar nichts mehr tut ?
Benötigt man dafür spezielle Kabelage oder muß, wie bei der CUVC (Siemens FU's ), irgendwelche Pins brücken ?

Mfg


----------



## Dotzi (3 Dezember 2008)

mega_ohm schrieb:


> So, wie ich den OB35 zu Beginn dieses Themas hier eingestellt habe, ist er geblieben.
> 
> Das Retten von AR1 u. AR2 würde so aussehen ?
> 
> ...


 
Also nach meiner Meinung funktioniert das Sichern von Adresssregistern nach folgendem Prinzip:


```
ORGANIZATION_BLOCK "CYC_INT5"
TITLE = "Cyclic Interrupt"
VERSION : 0.1
 
VAR_TEMP
  OB35_EV_CLASS : BYTE ; //Bits 0-3 = 1 (Coming event), Bits 4-7 = 1 (Event class 1)
  OB35_STRT_INF : BYTE ; //16#36 (OB 35 has started)
  OB35_PRIORITY : BYTE ; //Priority of OB Execution
  OB35_OB_NUMBR : BYTE ; //35 (Organization block 35, OB35)
  OB35_RESERVED_1 : BYTE ; //Reserved for system
  OB35_RESERVED_2 : BYTE ; //Reserved for system
  OB35_PHASE_OFFSET : WORD ; //Phase offset (msec)
  OB35_RESERVED_3 : INT ; //Reserved for system
  OB35_EXC_FREQ : INT ; //Frequency of execution (msec)
  OB35_DATE_TIME : DATE_AND_TIME ; //Date and time OB35 started
  AdressRegister1 : DWORD ; 
  AdressRegister2 : DWORD ; 
END_VAR
BEGIN
NETWORK
TITLE =Adressregister retten
      TAR1  ; 
      T     #AdressRegister1; 
      TAR2  ; 
      T     #AdressRegister2; 
NETWORK
TITLE =
//Code
NETWORK
TITLE =Adressregister zurückschreiben
      L     #AdressRegister1; 
      LAR1  ; 
      L     #AdressRegister2; 
      LAR2  ; 
END_ORGANIZATION_BLOCK
```
 
Gruß


----------



## Larry Laffer (3 Dezember 2008)

... so wie von Dotzi beschrieben habe ich es gemeint ... Ich würde lediglich die Aressregister in ein DWORD und nicht in ein WORD sichern ...

Gruß
LL


----------



## mega_ohm (4 Dezember 2008)

Dotzi schrieb:


> Also nach meiner Meinung funktioniert das Sichern von Adresssregistern nach folgendem Prinzip:
> 
> > Beispiel < (gekürzt )
> 
> Gruß


Ganz, ganz vielen Dank für das Beispiel.
Ich hatte geschrieben, wie *ich* mir das Sichern vorstellen würde und ein Frägezeichen dahintergesetzt. (Ich hatte gar keinen Plan, wie man Adressregister behandelt )

Meine grundlegenden Gedanken waren schon ganz falsch. Ich hätte erst "geladen" (wie z.B. ):

```
L db1.dbw0
L <irgendwas>
...
T db1.dbw0
```
( so wie es sonst eigentlich üblich ist ) und zum Schluß "geschrieben".

Nun kann ich aber nachvollziehen, wie das Sichern aussieht.
( Erst Register auf ein DWord schreiben, dann Progi ausführen, dann DWord zurück'laden')
In Pascal war das eigenlich auch so, wenn man ASM- Code ausführen wollte.
 Mir fiel das in dem Moment wieder ein, als ich die Struktur Deines Beispiels gelesen habe.

:s12:

Mfg


----------



## mega_ohm (4 Dezember 2008)

Larry Laffer schrieb:


> Hallo,
> deine Frage läßt sich m.E. nicht so einfach beantworten ...
> 
> Pauschal sieht es so aus, als wenn mit deinen Pointern...
> ...


Hallo Larry,
wie meinst Du das mit den "Pointern" ?
Ich habe ( zumindest bewußt) keine Pointer benutzt, weil ich davon noch gar keine Ahnung habe.

Mfg


----------



## mega_ohm (4 Dezember 2008)

Bis JETZT !!! (heute ) gab es wieder keine Probleme mehr mit meinem Progi.
Deswegen verstehe ich ja auch nicht so ganz, warum dieses Progi nicht funzt. ( Ein Progi, welches die CPU irgendwann zum "Stopp" zwingt, funktioniert nicht )

Das Programm läuft etliche Wochen ( die 'Mimik' im OB35 wird produktionsbedingt innerhalb von 10 Minuten mind. 4x aufgerufen, in 3 Schichten an 5 Tagen pro Woche) und irgendwann (nach fast einem Monat) stoppt das System mit einem nicht nachvollziehbaren Fehler ???
Das raffe ich nicht. 

Ich werde aber das Sichern der Adressregister schonmal vorbereiten (Dank an Alle, die mir Das erklärt haben :s12: ).
Beim nächsten CPU- Stopp 'spiele' ich dann diese Version auf die SPS.
( Bis dahin muß ich warten, sonst schmeißt mich mein Chef durch die Halle  )

Ich melde mich also mit diesem Thema wieder, wenn ich weiß, ob diese Maßnahme von ERFOLG  :s11:

oder Mißerfolg :sm17: :sb15: gekrönt wurde. 
(Dann hätte ich aber weitere Fragen.
Die Diagnosemeldungen des letzten Absturzes lade ich aber diese Wioche noch hoch)

Mfg


----------



## Larry Laffer (4 Dezember 2008)

mega_ohm schrieb:


> Ich habe mich dann in der Nachtschicht mal dafür interessiert, was denn in der Diagnose so geschrieben steht und staunte nicht schlecht:
> "Zugriff auf OB35 verweigert, OB35 nicht vorhanden"


 
Hallo MegaOhm,
die Idee mit den Pointern stammt bei mir aus der obigen Information von dir. Das deutet für mich darauf hin, dass irgendwo die Adressregister so "verbogen" worden sein könnten, dass die SPS den Einsprungpunkt für den OB35 nicht mehr "findet". Da der OB35 das laufende zyklische Programm irgendwo unterbricht, seine Arbeit verrichtet und dann das zyklische Programm wieder fortsetzt, war das "Register-retten" mein erster Ansatz (stammt bei mir übrigens auch aus der guten alten Assembler-Zeit).

Ich kann mir allerdings auch immer noch vorstellen, dass es besser wäre, eine "stärkere" CPU einzubauen - aber das hatten wiur ja schon mal ...

Gruß
LL


----------



## mega_ohm (5 Dezember 2008)

Larry Laffer schrieb:


> Hallo MegaOhm,
> die Idee mit den Pointern stammt bei mir aus der obigen Information von dir. Das deutet für mich darauf hin, dass irgendwo die Adressregister so "verbogen" worden sein könnten, dass die SPS den Einsprungpunkt für den OB35 nicht mehr "findet". Da der OB35 das laufende zyklische Programm irgendwo unterbricht, seine Arbeit verrichtet und dann das zyklische Programm wieder fortsetzt, war das "Register-retten" mein erster Ansatz (stammt bei mir übrigens auch aus der guten alten Assembler-Zeit).
> 
> Ich kann mir allerdings auch immer noch vorstellen, dass es besser wäre, eine "stärkere" CPU einzubauen - aber das hatten wiur ja schon mal ...
> ...


Neenee... mit Pointern hab' ich in s7 noch gar nix am Hut. ( noch keine Ahnung, wie das funktioniert.... aber ich werde bestimmt auch in Zukunft noch viele Fragen haben  )
Trotzdem finde ich die Idee mit dem "Register sichern" richtig gut... (aus der ASM- Zeit kenne ich das auch ) und werde es auf jeden Fall auch so machen. Den Bericht über Erfolg oder eben nicht bleibe ich bestimmt nicht schuldig ( das verspreche ich ). Es dauert eben nur bis zum nächsten "CPU- Stopp". Erst dann kann ich die Änderung auf das AG übertragen.
Wenn ich mich mit dem PG vorher ransetze und irgend ein Fehler (Schlingenbildung, Drahtbruch etc. ) auftritt, kommt man als allererstes mal zu mir und fragt, was ich da "rumklimpere". Das muß ich nicht haben.
>>> Qualität braucht Zeit *ROFL* Daran halte ich mich.

Eine neue CPU... ich hätte noch nicht einmal eine Grundidee, wie ich das dem Controller- Menschen erklären könnte. Schließlich funktioniert das Ganze ja mehr oder weniger 

Ich danke Dir für die guten Tipps...
Wenn ich mal nachfrage, heißt das nicht, das ich es besser kann, sondern...  Ich bin im "Lern- Modus", mich interessiert das Thema.
>>> Wer *nicht* fragt, hat kein Interesse!

Viele Grüße und ein schönes WE

Mfg


----------



## mega_ohm (14 Dezember 2008)

Bevor ich die hier im Forum erwähnten Lösungsvorschläge ( Sichern des Adressregisters ) angewendet hatte, kam mir ein Maschinist zuvor.

Für ein erneutes "Ansteckseln" des PG's war die Grundvoraussetzung, daß die CPU wieder stoppt --- Ich hätte die hier im Forum vorgeschlagene Änderung sowieso gemacht, weil mir dieser Tipp aus meiner TASM- Zeit für richtig und sehr sinnvoll erschien.

Ich hatte selbst versucht, die CPU zu 'kippen', was mir natürlich nicht gelang.
( nur EIN Maschinenbediener brachte dieses Ergebnis überhaupt zu Stande.. in einem 3-Schicht-Betrieb)
Ich habe analysiert und mir vorführen lassen, wie es zu diesem Effekt kommt.
In Eigenversuchen ( obwohl ich alle Tasten, die vorhanden sind, wahllos und sinnfrei betätigte) war dieser Effekt in keiner Weise nachvollziehbar.
Mir wurde in dem Moment klar, daß ich nie!! meine eigenen Progis auf Fehler testen kann.

Der Sinn dieses Prog.-Moduls war, ein Anlagenteil auf eine Position zu fahren ( ohne irgendwelche Endschalter, Abschaltsignale).
=> Da es für dieses Anlagenteil keine HMI gibt (dann wäre ja z.B. ein Timer die 1. Wahl), hatte ich mich für eine Tastenkombi [Lernen] entschieden, um das Ganze irgendwie individuell gestaltbar zu halten.

Der Maschinist 'lernte' der SPS erst die Position, schaltete danach auf "Automatik" und wollte während der "Auto- Positionierung" korrigieren. (Warum man sowas macht ???  )
Auf diese Idee kam eigentlich noch kein Anderer.

Ich habe die Adressregister, wie hier im Forum empfohlen, ge-handle-t.

Ich habe diesen Kollegen dannach nochmal gebeten, alles zu tun, um die CPU zu stoppen ( Alle Lichter auf dem Bedientableau gehen aus => viel Freizeit).
Es gelang ihm nicht mehr...

Seit jetzt fast 1,5 Wochen scheint es so ( ich gehe mit dem Wort "Fertig- Lösung" immer sehr vorsichtig um ), als wäre das Problem tatsächlich abgefrühstückt.
____________________________________________________________
Sollten sich neue Probleme oder Erkenntnisse bilden, würde ich diese hier sofort vermelden... ich erwarte aber nix mehr in diese Richtung.


:s1: Danke an Alle
:s12: die Tipps waren sehr hochwertig

:sm24: Darauf ein gutes Bier *Prost


----------



## mega_ohm (1 Februar 2009)

*Fragen zu s7- Zeit (ms... s) ... und raum*

Ich möchte kein neues Thema öffnen, weil es immer noch diese CPU betrifft.


Alle *bisherigen *Fragen zu diesem Thema sind geklärt und die Probleme gelöst.

_*_______ Das sind die nächsten Fragen zur gleichen CPU ____________* _

Bei dieser Anlage , die schon mehr als 5 Jahre produziert, ... das Programm immer nur erweitert/angepaßt wurde, ist mir nach diesem Umbau aufgefallen, daß es gravierende Probleme in der Sicherheit gab /gibt.

*Anlagen- FernStart* (war immer möglich), 
... auch wenn die Roh-Material-Zufuhr auf dem PC- Screen des Haupt- Tableaus "abgewählt" war. (bisher ist diese Sicherheitslücke nie aufgefallen)

Das geht zukünftig auf Grund der Entfernung und der fehlenden Kommunikatonsmöglichkeit nicht mehr.
____________________________________________________________

*Um dieses Problem zu lösen,* habe ich mein Progi anpassen wollen:
Dabei habe ich bei oben genannter CPU einen fast außergalaktischen effekt gesehen!
- Einen Timer ( z.B. T32) hatte ich in Sekunden parametriert.
>>> T32 = SEverz => s5t#3S
Im Test des neuen Progis kam mir dieser Timer (s5t#3s) unglaublich lang vor.... 
Ich stoppte das Ganze mal erneut und es waren mehr als 6sec. ( mit einer Armbanduhr gestoppt).
Nun dachte ich, daß bei s7 für die gleiche Zeit eben Millisekunden genauer wären: 
..... also parametrierte jetzt die 3sec auf 300ms 
Das Ergebnis im s7- Progi:
>>> zisch_und_weg
- Noch nie habe ich 300ms so schnell gesehen
>>> Mit meiner Armbanduhr konnte ich diese Zeit gar nicht stoppen, weil diese Zeit schon abgelaufen war, bevor ich meine Armbanduhr mit der "Stop-function" überhaupt starten konnte....
>>> "! Gefühlte 1/2 Sekunde" (das ist natürlich keine Zeitangabe)

*Meine Frage ist:*
*- wie kann eine s7-Zeit so unglaublich gravierend unterschiedlich sein ?*


----------



## argv_user (1 Februar 2009)

Guten Morgen:

Wenn Du nachrechnest wirst Du wahrscheinlich selber drauf
kommen dass 300ms nur 0,3 Sekunden sind. War aber ja auch schon spät so kurz nach drei.


----------



## mega_ohm (12 Februar 2009)

*Ich trau' mich schon fast nicht mehr, dieses Thema noch einmal aufzugreifen...*

aber nach einem fast 10- tägigen Umbau und damit verbundener Spannungsfreiheit in dem Schaltschrank, in dem mein "Problemkind" sitzt, ( die in der Strangeröffnung erwähnte CPU ) trat das Problem des CPU- Stopp heute wieder auf.
Wieder die Meldung im Diagnosepuffer: "Zugriff auf OB35 verweigert, OB35 nicht vorhanden"

- Die Adressregister habe ich, wie mir hier erklärt wurde, in NW1 des OB35 auf 2 DW (ein DW für AR1 und 1DW für AR2) gesichert. Danach führe ich meine paar Sprünge und Transfer-/ Lade- Befehle aus. Danach schreibe ich die AR zurück.
- Die Zyklusüberwachungszeit ist auf 150ms eingestellt.
Lt. s7-Hilfe ist das die Zeit, nach der das Prog. und alle Aufrufe mind. einen Zyklus durchlaufen haben müssen.
- Die kleinste Zykluszeit beträgt lt. Diagnose = 3ms ( lt. Hilfe die kürzeste Zeit eines Zyklusses seit dem letzten Start der CPU)
- die größte Zykluszeit = 6ms ( lt. Hilfe die max. Zeit eines Zyklusses seit dem letzten Start der CPU ) *... so habe ich zumindest die Hilfe verstanden *
- der OB 35 wird alle 50 ms aufgerufen (die paar Befehle können doch nicht 50ms überschreiten, so daß der eine OB35 Aufruf noch nicht fertig ist, während der 2. Aufruf schon folgt ???? )
- bei der Diagnose der Stacks kam die Meldung " Inkosistenz, ... " und irgendwas mit gelöscht.
Die CPU war zu diesem Zeitpunkt gestoppt. Ich hatte nichts gelöscht, vor dem CPU- Stopp im Programm nur in FC 5,7, 20 und DB 20 geändert.
All diese Änderungen haben mit dem OB35 und dem DB1 (in den schreibt der OB35 ) meiner Meinung nach erstmal nichts zu tun.
Vor dem CPU- Stopp habe ich das komplette Anwenderprog. auf die Speicherkarte geschrieben.


Ich verstehe nicht, wieso dieses Problem so sporadisch auftritt.
Wie kann man an die Lösung herangehen ?
- den OB35 nur alle 100ms aufrufen ? (Das wäre für meine Anwendung schon etwas grenzwertig, da ich ja dann den Zähler in einer Sekunde nur 10x aktualisieren würde. Das wäre mir schon fast etwas zu ungenau für meine Anwendung)
- die Zyklusüberwachungszeit erhöhen ?? (wobei ich schon 150ms aus oben geschriebenen (min-, max.Zykl.-) Zeiten für mich für ausreichend befinden würde)

Ist ein Firmware-Update (wie hier schon vorgeschlagen wurde) eventl. eine Lösung für das nervige Problem ? Wenn ja, kann mir eventl. jemand einen Link oder eine Anleitung senden ? Ich habe das für s7-CPU's bisher noch nie gemacht.

Ich hätte in der Zwischenzeit gern auf den OB35 verzichtet und den Spaß Taktmerker- gesteuert aufgerufen. Dabei habe ich aber das Problem, daß jeder Zähl"impuls" zyklusabhängig ist und die Abweichung der vorherigen Position von der nächsten bis zu 45cm unterschiedlich wird.

PS.: "Zugriff auf OB35 verweigert, OB35 nicht vorhanden" <= diese Fehlermeldung ist noch verwirrender als gar keine Fehlermeldung. Der OB35 ist definitiv online beobachtbar. Ich gehe also davon aus, daß er dann auch in der CPU aufgerufen wird.


----------



## Ralle (12 Februar 2009)

Hier ein Link zu den Updates:

http://support.automation.siemens.com/WW/view/de/16749674

Du mußt die Bestellnummer deiner CPU nehmen und das neuste dazu passende Update heraussuchen. Wie es geht ist im Link beschreiben. Es lohnt sich, die behobenen Fehler mal nachzulesen, u.U. findet man auch eine Erklärung für das Fehlverhalten der CPU.


----------



## Onkel Dagobert (12 Februar 2009)

*Bausteinkonsistenz prüfen ???*

Ich hätte das Teil schon längst verschrottet!

Als letzten Versuch hätte ich jedoch noch einmal das Programm komplett übersetzt (Bearbeiten - Bausteinkonsistenz prüfen - alles übersetzen). Nach vielen Programmänderungen hat man, wenn auch selten, unerklärliche Fehler.

Welche Step7-Version wird denn verwendet?
V5.4 SP4 vielleicht?


Gruß, Onkel


----------



## mega_ohm (12 Februar 2009)

Ralle schrieb:


> Hier ein Link zu den Updates:
> 
> http://support.automation.siemens.com/WW/view/de/16749674
> 
> Du mußt die Bestellnummer deiner CPU nehmen und das neuste dazu passende Update heraussuchen. Wie es geht ist im Link beschreiben. Es lohnt sich, die behobenen Fehler mal nachzulesen, u.U. findet man auch eine Erklärung für das Fehlverhalten der CPU.


Danke für den Link...

Mir ist ja bald das Gefieder weggeflogen... seit 2005 wird diese CPU nicht mehr verkauft, nur noch Ersatzteilgarantie.
Seit 2004 warnt Siemens die Produkteinstellung an... und unser Einkauf hat 2004 genau diese CPU erworben. ( Wahrscheinlich gabs für dieses 'Schnäppchen' noch einen Laster voll Kalender und Kugelschreiber gratis dazu ).

Ich werde morgen mal schauen, ob ich irgendwas an diesem Problem lösen kann.
Erstmal werde ich aber noch den Tipp von Onkel Dagobert
(Bausteinkonsistenz prüfen ) probieren, weil das für mich erstmal noch ein Weg ist, den ich kenne (Firmware-Update habe ich nocht nicht gemacht),
eventl. noch mal reorganisieren... prüfen, ob ich die Stacks doch noch irgendwie auslesen kann.

Die Diagnosedaten, Stacks, Zugriffszeiten und die Parametrierung des OB35 werde ich mal versuchen, hier einzustellen.

Mfg


----------



## mega_ohm (12 Februar 2009)

Onkel Dagobert schrieb:


> Ich hätte das Teil schon längst verschrottet!
> 
> Als letzten Versuch hätte ich jedoch noch einmal das Programm komplett übersetzt (Bearbeiten - Bausteinkonsistenz prüfen - alles übersetzen). Nach vielen Programmänderungen hat man, wenn auch selten, unerklärliche Fehler.
> 
> ...


Vielen Dank für den Tipp "Bausteinkonsistenz prüfen". Das werde ich morgen mal als 1. angreifen.

Die Step7- Version muß ich erst auf dem PG prüfen... kann ich jetzt nicht so aus dem Hut sagen.

Mfg


----------



## mega_ohm (13 Februar 2009)

*FW- Update lohnt sich nicht, weil die vorhandene FW dem letzten Update entspricht ?*

http://support.automation.siemens.c...tandard&viewreg=WW&objid=33516848&treeLang=de

Verdammt... (ich hab' grad mal nach den Updates gesucht....)
Die verbaute CPU ist eine 314-1AE04-0AB0 und am AG steht, wenn man den Deckel hochklappt, (wo unter anderem die Batterie eingelegt wird )
... V 1.2.1

Dementsprechend müßte das die letzte Firmware- Update- Version sein, die Siemens auch anbietet.
Also lohnt sich das FW- Update nach meiner Meinung nicht, weil diese Version ja in dem schwarzen Kasten "drinn" ist ?

Mfg


----------



## mega_ohm (13 Februar 2009)

*Ich habe den Fehler gefunden*

Ich hatte das Netzwerk doch 4 mal kopiert und dann bloß die jeweiligen Eingänge, DB's und Sprunkmarken angepaßt.
Und eben eine Sprungmarke vergessen zu ändern... so daß unter bestimmten Bedingungen -zig mal in dem OB35 rumgesprungen wurde. (fast eine Endlos- Schleife)
Dann ist natürlich klar, daß die Zyklusüberwachungszeit nicht reicht und die CPU stoppt und es erklärt auch die sporadischen Ausfälle.

Ich denke mal, jetzt sollte es funktionieren.

Vielen Dank für die vielen Tipps.
Meine Erkenntnis des Fehlers kam zwar spät, aber so mußte ich mich eben auch mal intensiver mit der Diagnose befassen ... und daß, was ich dabei gelernt habe, ist auch viel wert.


----------

