S5 135U - Bit gekippt?

[Borsti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus.
Ich hab mal ne Frage:

Heute morgen bekam ich einen Anruf, daß bei einer Transportanlage nichts gehen würde. Vorort war dann das AG auf Stop.
Die Stacks durchgegangen und festgestellt, daß die CPU eine ungültige Anweisung in einem Baustein zu beanstanden hatte.
Ich hab dann die Offline und Online Bausteine verglichen und festgestellt, daß sich eine Anweisung von einem Timer verändert hatte. Es sollte folgendes in dem Baustein stehen:

U E 96.2
L KT 10.0
SE T 75

Statt dessen stand in dem Online Baustein:

U E 96.2
NOP 1
NOP 1
SE T 75


NOP 1 ist ja eigentlich nur ein Bildaufbau Befehl, für die S5 Software, oder?
Kann es sein, daß die CPU ihre Programmierung selbstständig verändert hat, oder ist dies ehr ein Zeichen dafür, daß die CPU bald einen Abgang macht?

Ich weiss auch nicht, ob vorher der Hauptschalter aus war. Fest steht nur, es war niemand an dem AG und hat die Programmierung verändert.
Bei uns konnte es mir niemand erklären, vielleicht hat ja hier jemand eine Idee...

MfG
Borsti

 

[Unregistrierter gast]

Bei uns konnte es mir niemand erklären, vielleicht hat ja hier jemand eine Idee...

MfG
Borsti

Ich kipp auch schonmal ein Bit, warum nicht die 135U ?

3 Möglichkeiten:

- falscher Stand auf Eprom, das bei Spannungsausfall geladen wurde
- Speicher geht langsam kaputt oder Zufallstreffer eines "Teilchens"
- Indirekter Zugriff auf den Speicherbereich, kleiner Programmfehler kann oftmals große Wirkung haben... (Dann sollte das Problem aber regelmässig auftreten)

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bit oder Veltins gekippt ?

Hallo,

NOP 1 ist ja eigentlich nur ein Bildaufbau Befehl, für die S5 Software, oder?

Nein, es ist kein Bildaufbaubefehl im eigentlichen Sinne wie BLD 255 (Segmentende) oder BLD 130 (Umschaltung auf AWL-Darstellung oder so). Der Befehl heisst "Nulloperation, alle 16 Bit des Wortes werden mit log "1" aufgefüllt.
Hat keine sinnvolle Verwendung.
"NOP 0" wird verwendet, um in AWL nicht benutzte Parameter an z.B. Timern oder Zählern zu besetzen. Damit ist dann die Darstellung in FUP oder KOP (Schüttel) möglich, sofern dem nicht andere Hindernisse wie Klammerebenen, Schachtelungstiefe o.ä. im Wege stehen.
Noch eine Frage : War das Programm auf einem EPROM oder im RAM gespeichert ???
Ich habe es noch nie erlebt, dass sich der Inhalt eines RAM's verändert. Der geht kaputt und das AG in Stop. Begegnet sind mir schon manipulierte Befehlsregister (z.B. durch Induktionsspannung auf HF-Monitorkabel über einen CP), aber die AG's sind dann immer sauber in Stop gegangen. Obwohl, das Befehlregister liegt auch im RAM-Bereich der Speicherbaugruppe, oder ?? Sag ich mal so aus dem Gedächtnis, muss ich aber nochmal verifizieren.
Dagegen habe ich schon EPROM's erlebt, die Ihren Inhalt verändert haben. Ist ja eigentlich nur eine popelige Diodenstrecke, die halt auch mal kaputt gehen kann.

Gruss

Question_mark

 

[volker]

also ich kann dazu sagen, das ich es in zwei 115u schon mal hatte (2 verschiedenen ag's).
dort stand irgend ein blödsinn im ag den es als befehl gar nicht gibt. weiss nicht mehr genau was da stand.

die cpu'en waren dann wegen 'nicht interpretierbarem befehl' im stop.

 

[Question_mark]

Wer hat das Bit gekippt ???

Hallo Volker,

die cpu'en waren dann wegen 'nicht interpretierbarem befehl' im stop.

Hatte ich ja oben schon geschrieben, die sind dann jeweils sauber in Stop gegangen (jedenfalls solange der Fehler im RAM aufgetreten ist).

Siehe hier :

manipulierte Befehlsregister (z.B. durch Induktionsspannung auf HF-Monitorkabel über einen CP), aber die AG's sind dann immer sauber in Stop gegangen.

Gruss

Question_mark

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

ja, ok. wollte nur erwähnen, dass sowas passieren kann.
bei mir steckte kein eprom im ag.

nach urlöschen und neu übertragen war alles wieder ok.

 

[Borsti]

Danke erstmal.

Also, die CPU hat kein EPROM, müsste somit alles im RAM liegen.
Ausserdem, ist sie ja sauber in Stop gegangen, wie ich bereits erwähnte.
Indirekte Adressierung kann ich auch ausschließen, da die CPU nur Schütze, Lichtschranken, ein paar Zylinder und ein paar Überschaltung bearbeitet.
Das einzige was sein könnte ist, daß die IM, die mit einer 314 kommuniziert, was verbockt hat, aber auch das halte ich ehr für unwahrscheinlich.
Aber, es ist gut zu hören, daß es bei anderen auch schoneinmal vorkam, mal sehen obs nochmal passiert...

 

[eNDe]

Hallo,
ich möchte mit meinem bescheidenen Hintergrundwissen auch etwas beisteuern. Vielleicht hilft es weiter:
Die Befehlsfolge sah im Original so aus:
L KT 10.0. Dieser Befehl hinterlegt folgenden Maschinencode im RAM (Zweiwort-Anweisung):
30 02
00 08
Die beiden NOP1-Anweisungen belegen im RAM (jeweils Einwort-Anweisung):
FF
FF
Wie diese F's dahin gekommen sind, weiss ich natürlich auch nicht. NOP1 ist aber ein "offizieller" Befehl in S5, also interpretierbar!
Dass das AG in STOP gegangen ist, liegt wahrscheinlich an der nunmehr falschen Prüfsumme des RAM.
(Ist nur mal so ein Gedanke)

 

[Borsti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ah gut, jetzt weiß ich wenigstens wie der MC5 (ist das doch, oder) Code bei den beiden Befehlen aussieht. Daher kam ich auf die Idee, daß ein Bit sich entschieden hat den Zustand zu wechseln, oder sowas, was aber wohl nicht der Fall war...
Nun, die CPU ging ja auch in Stop, weil der SE Timer keinen gültigen Zeitwert geladen hatte...

 

[eNDe]

Hallo nochmal,
Der Befehl SE T 75 lädt als Zeitwert das, was er im Moment der Befehlsabarbeitung im Akku1 als Wert vorfindet und interpretiert das als Zeitwert. Da im Original ein Ladebefehl stand (mit einem gültigen Zeitwert) war auch alles i.O. Die NOP1-Anweisungen verändern den Akku-Inhalt nicht. Es kann also auch sein, dass im Moment der Abarbeitung des SE-Befehls etwas im Akku1 stand, was als Zeitwert nicht interpretierbar war. Ergo: Das AG ist nicht wegen der NOP1-Befehle in STOP gegangen sondern wegen des nicht ausführbaren SE-Befehls, weil dessen Zeitwert ungültig war. (Oder eben wegen der falschen Prüfsumme).
Aber noch etwas: Stell dir mal vor, im Akku stünde zufällig eine Codierung, die als Zeitwert interpretierbar ist (sagen wir mal KT 999.3). Dann würdest du den Fehler erst bei Eintritt der Katastrophe bemerken. Das Siemens an so etwas nicht gedacht haben soll, kann ich mir nicht vorstellen. Für mich bleibt deshalb die Variante Prüfsumme die wahrscheinlichere Ursache!

 

[Question_mark]

Neee, nicht schon wieder .....

Hallo,

Die beiden NOP1-Anweisungen belegen im RAM (jeweils Einwort-Anweisung):
FF
FF

Lasst euch durch eNDe nicht verwirren, richtig ist :

FF FF
FF FF

jedenfalls für die beiden obenstehend zitierten zwei Einwort-Anweisungen NOP 1.

Gruss

Question_mark

 

[Question_mark]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal eine kurze Frage erlaubt ???

Hallo,

30 02
00 08

Das ist also L KT 10.0 im MC5-Code ???

Bist Du da ganz sicher ???

Gruss

Question_mark

 

[kpeter]

Guten Morgen

Hast du mal an eine ganz einfachere Lösung gedacht !

1.) Hat das Programm einer vieleicht mit absicht geändert soll immer mal vorkommen !!!!


2) hab ihr in letzter zeit änderungen gemacht die vieleicht denn AKKU inhalt vor demm TIMER geändert hat und somit der Fehler aufgetreten ist

-----------------------------------------------------------------------

Ich hatte vor einigen Wochen so ein ähnliches Problem und bin nach langer zeit draufgekommen das das Programm immer schon falsch war nur ist der Fehler nie aufgetreten weil meine FU nicht richtig Positioniert haben damit bin ich zum Fehler nie gekommen und alles ging. Wie aber meine FU's gewartet wurden und der Fehler entfernt wurde ging auf einmal nichts mehr. Hab natürlich auch gleich geschrien das sich das programm geändert hat aber war nicht so

 

[eNDe]

Hallo nochmal,
nur damit Question_mark ruhig schlafen kann:
Original / MC5-Code:
U E 96.2 / C2 60
L KT 10.0 / 30 02 00 10
SE T 75 / 24 4B

Und nun mit Fehler:
U E 96.2 / C2 60
NOP 1 / FF FF
NOP 1 / FF FF
SE T 75 / 24 4B

Quelle MC5-Code:
1. WinSPS-S5
2. Berger/Automatisieren mit S5, Seite 404 ff

Der Aufwand trägt zwar nicht zur Klarstellung des Problems bei, aber Question_mark ist nun hoffentlich beruhigt.

Zur unerklärlichen Umprogrammierung:
In meiner Schulpraxis hatte ich es immer mit Erwachsenen zu tun (Seminare und Weiterbildung). Ich könnte mindestens 10 Fälle aufzählen, in denen mir Beispiele gezeigt wurden, wie herumgetrickst wurde nur, um sich beim Anwender "unentbehrlich" zu machen. Genügend viel kriminelle Energie vorausgesetzt, ist vieles machbar (und wird offenbar auch gemacht!)

 

[Werner54]

Zuviel Werbung?
-> Hier kostenlos registrieren

Codeverstümmelung

Ich kipp auch schonmal ein Bit, warum nicht die 135U ?

3 Möglichkeiten:

- falscher Stand auf Eprom, das bei Spannungsausfall geladen wurde
- Speicher geht langsam kaputt oder Zufallstreffer eines "Teilchens"
- Indirekter Zugriff auf den Speicherbereich, kleiner Programmfehler kann oftmals große Wirkung haben... (Dann sollte das Problem aber regelmässig auftreten)

Es gibt noch eine Möglichkeit, die zwar selten, dann aber wiederkehrend ist:

Grobe Fehler auf dem Rückwandbus (Bursts etc.) können in den Speicher "eindringen" und den Code verändern. Sowas passiert durch defekte Ausgangskarten, Kurzschlüsse der Aktoren, ungeeignete Verschaltungen, Spannungsverschleppung etc.
Ich hatte das mal bei einer S5-115U circa einmal monatlich, bis zum Austausch der falschen Magnetventile.

 

[Unregistrierter gast]

Es gibt noch eine Möglichkeit, die zwar selten, dann aber wiederkehrend ist:

Grobe Fehler auf dem Rückwandbus (Bursts etc.) können in den Speicher "eindringen" und den Code verändern. Sowas passiert durch defekte Ausgangskarten, Kurzschlüsse der Aktoren, ungeeignete Verschaltungen, Spannungsverschleppung etc.

Stimme dir zu, das hatte ich unter "Zufallstreffer eines "Teilchens" "
verbucht...

 

[RonOro]

Hallo,

ist an der CPU vielleicht ein OP angeschlossen, über AS511 ?
Es kann nämlich sein das beim Komprimieren des Speichers der CPU mit angeschlossenem OP Bausteine verändert werden, wenn im OP nicht
das zyklische Aktualisieren der DB-Listen (o.ä.) angewählt ist.

 

[Borsti]

Zuviel Werbung?
-> Hier kostenlos registrieren

@ kpeter: Ja, daran haben wir auch gedacht, aber ich bezweifle, daß jemand sich die Arbeit macht, 5 Paletten, vor dem Schaltschrank weg zu fahren, dann mit nem PG einen KT Befehl in 2 NOP 1 wandelt, dann die Paletten wieder davor stellt und einfach so verschwindet (wobei er ja sehen müsste, daß die CPU auf Stop ist). Dazu kommt noch, daß die Anlage bis den Abend davor um 23.00 Uhr lief und morgens um 5.00 Uhr nichtmehr. Die Kollegen von der Nachtschicht hatten genug zu tun, daher kann ich die reinen Gewissens ausschließen.
Die einzige Änderung die in letzter Zeit gemacht wurde, war die IM, die gesteckt wurde. Aber seitdem ist die Anlage etwa 4 Wochen gelaufen und die Anweisung wird zyklisch bearbeitet, also kein bedingter Aufruf.

@Werner54: Also, wenn es mit dem Rückwandbus zu tun hätte (so wie du es beschrieben hast) wäre es also möglich, das dies beim einschalten des Hauptschalters auftritt, Spannungseinbruch im 24V Kreis, o.ä... Auch ne Idee, aber denke ich nicht, da dies ja sonst öfters vorkommen würde.

@RonOro: Nein, es ist kein OP angeschlossen. Zur Visu haben wir nur eine alte Lauer Textanzeige, welche über Ausgangskarte angesteuert wird.


Ich muss mal sehen, ob ich morgen dran denke, dann bringe ich mal die Screenshots der Stacks, etc. mit...

 

[Question_mark]

Mit den Azubis darf ich mich dann rumärgern ???

Hallo,

Der Aufwand trägt zwar nicht zur Klarstellung des Problems bei,

Du selber hast den MC5-Code hier eingebracht. Von 5 Codezeilen sind zwei absolut falsch, da darf ich dann bitte mal etwas korrigieren. Diese Freiheit nehme ich mir eben raus...
Manche Forumsteilnehmer suchen bei Problemen Lösungen in der "Suchfunktion" z.B. unter MC5-Code und wenden diese Erkenntnisse dann in der Praxis an. So nach dem Motto : Stand ja im sps-forum oder der Ausbilder hat gesagt ...
Auch so Feststellungen wie "die kürzest mögliche Impulsdauer ist ein Zyklus" stimmt im Zusammenhang zur Impulsbildung nur bedingt. Jeder Volltrottel kann den Impulsmerker danach zurücksetzen. Aber diese Feststellungen bleiben den Azubis im Kopf haften, der Zusammenhang mit dem Impulsmerker ist am nächsten Tag einfach weg. Im Gedächtnis bleibt den Azubis nur nur der Kernsatz "die kürzest mögliche Impulsdauer ist ein Zyklus". Solltest Du aber als Ausbilder eigentlich wissen !
So noch eins : Du fühlst Dich durch meine Kritik wahrscheinlich persönlich angegriffen, das ist aber nur verletzte Eitelkeit. Leider hast Du nur nicht genug Rückgrat, um zu schreiben : ich habe mich geirrt, ich habe mich vertippt, ich habe falsch abgeschrieben oder sonstwas ...
Es hilft einfach nicht, Deine korrigierten MC5-Anweisungen hier nun hereinzustellen und so zu tun, als wenn Du diesen MC5-Code von Anfang heran richtig reingestellt hast und ich nur der Erbsenzähler bin (Ist das Ok, Onkel Dagobert, Du hast Dich ja auch gemeldet ?).
Der Unterschied zwischen unseren Interpretationen des MC5-Codes sind halt nur ein paar Bits. In der Theorie passiert da nicht viel, in der Praxis geht der Blechcoil durch das Hallendach und Du hast Personenschäden auf dem Gewissen und ein ernstes Gespräch mit dem Staatsanwalt vor Dir.
Insofern, bleibe besser Ausbilder, ist besser für die Menschheit und für Dich
Also in diesem Sinne

Gruss

Question_mark

 

[Hubbl-e]

Hallo Borsti,
habt Ihr Ratten in der Anlage?
Ich hatte mal eine Ratte ueber der SPS "wohnen", die hat mir mein gesamtes Programm weggepisst.