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

mega_ohm

Level-2
Beiträge
676
Reaktionspunkte
47
Zuviel Werbung?
-> Hier kostenlos registrieren
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.:
Code:
[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
 
Zuletzt bearbeitet:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Code:
L PEW 2 // aktualisieren Eingänge
T EW2
....
L AW  14 // Zählerausgang
T PAW 14
 
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
 
Hi,
aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:
Code:
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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).
:D 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
 
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.

______________________________________________________________
Code:
L PEW 2 // aktualisieren Eingänge
T EW2
....
L AW 14 // Zählerausgang
T PAW 14
Für dig. Eingänge lädst Du ein PEW ?
Ich dachte bisher.... (PEW,PAW =analog :confused: )
Ich setze mich morgen nochmal auf die "Schulbank"

Mfg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
Diese Idee hatte ich auch. Deshalb habe ich die Aufrufzeit auf 50ms erhöht.
 
Hi,
aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:
Code:
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.
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
 
Zuletzt bearbeitet:
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.:D
... 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
:D 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.
 
... 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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... 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
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebe Gemeinde,


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)


Mfg



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.
 
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
 
Zuletzt bearbeitet:
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
 
Zurück
Oben