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

Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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

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!)
 
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
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
 
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
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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" :confused:
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
 
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
 
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!).





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" :confused:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
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 ?
Code:
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 ?
 
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
 
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 ?
Code:
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 ?

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

Code:
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ß
 
Zuletzt bearbeitet:
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 )
:ROFLMAO:
Meine grundlegenden Gedanken waren schon ganz falsch. Ich hätte erst "geladen" (wie z.B. ):
Code:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :cool: :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
 
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" :confused:

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
 
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
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 :ROFLMAO: )
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 :rolleyes:

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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ??? :confused:)
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
 
Zuletzt bearbeitet:
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 ?
 
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.
:)
 
Zurück
Oben