Datenbausteinbereiche defekt?

[Forumaner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ist es möglich, dass Bereiche in einem DB defekt sein können?

Es ändern sich nämlich von selbst in einem DB die Bits in einem bestimmten Byte.
Obwohl keine Bits true gesetzt sind, steht mindestens ein Bit in dem Byte als true an und es kommen auch andere Bits, die true und auch wieder false werden, ohne dass sich VKE's ändern.
Wenn ich nun das Byte in einen anderen Bereich des selben DB's schiebe, gibt es keine Probleme.
Eine doppelte Zuweisung von Merkern kann ich 100%-ig ausschließen.

Beispiel:

U M0.0          // Merker 0.0 ist false
= DB10.DBX0.0   // DBX0.0 ist true
-----
U M0.0          // Merker 0.0 ist false
= DB10.DBX2.0   // DBX2.0 ist false
-----
Info: Standard-Werte sind im DB für dieses Byte auf false gesetzt.

Ich kann es mir zwar schwer vorstellen, aber kann es sein, dass ein Byte defekt ist (so blöd es sich auch anhört )?

MfG,
Forumaner

 

[Kai]

Hast Du das Programm selber geschrieben oder ist das ein bereits bestehendes Programm von jemand anderem?

Bist Du Dir wirklich sicher, dass auf das DBB0 im DB10 nicht noch an einer anderen Stelle im Programm zugegriffen wird, z. B. mit indirekter Adressierung?

Gruß Kai

 

[marlob]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
Eine doppelte Zuweisung von Merkern kann ich 100%-ig ausschließen.
...

Du bist Dir echt sicher? Du benutzt nirgendwo Pointer oder schreibst auf
DB10.DBB0, DB10.DBW0 oder DB10.DBD0
Hast du schon mal einen Haken bei Überlappender Zugriff auf Speicherbereiche gemacht, wenn du auf Gehe zur Verwendungstelle anwählst. Siehe Bild

 

[volker]

wo beobachtest du das?
in einer vat oder im status?

 

[Forumaner]

Hui, hallo!

Hast Du das Programm selber geschrieben oder ist das ein bereits bestehendes Programm von jemand anderem?

Ja, das Programm habe ich selber geschrieben.

Bist Du Dir wirklich sicher, dass auf das DBB0 im DB10 nicht noch an einer anderen Stelle im Programm zugegriffen wird, z. B. mit indirekter Adressierung?

Einen "Doppelzugriff" kann ich ausschließen. Es gibt im Programm keine indirekte Adressierung.

Du benutzt nirgendwo Pointer oder schreibst auf
DB10.DBB0, DB10.DBW0 oder DB10.DBD0?

Es gibt keine Pointer, der "defekte" Bereich im DB ist jungfräulich und wird nur von einem FC beschrieben bzw. ausgelesen.

Hast du schon mal einen Haken bei Überlappender Zugriff auf Speicherbereiche gemacht, wenn du auf Gehe zur Verwendungstelle anwählst?

Ja, aber dort ist auch alles im grünen Bereich!

wo beobachtest du das?
in einer vat oder im status?

In beiden.
Ich habe erst den DB begutachtet und fragte mich, warum einige Bits true sind und toggeln. Dann habe ich eine VAT angelegt... Das selbe Ergebnis.
Zu guter letzt habe ich die Bits aus dem DB auf Merker gelegt.
Die Merker sind true, obwohl die Durchschalt-Bedingung false ist!

Es geht aber noch kurioser:
Wenn ich z.B. mit einer Visu das DBB0 beschreibe, so klappt das in diesem "defekten" Bereich nicht richtig.
Es stand nämlich keine Anwahl von der Visu an, aber im DB wurde das Bit auf true gesetzt.
Wie aber schon erwähnt, verschiebe ich das Byte, so klappt es wunderbar mit der Visu und die Bits werden wie erwartet geschrieben und ausgelesen.

MfG,
Forumaner

 

[marlob]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du schreibst, das du eine Visu da dran hängen hast. Wird das Bit vielleicht von dort beschrieben. Welche Visu ist das und tritt das Problem auch auf, wenn die Visu abgekoppelt ist.
Wenn das Projekt nicht zu gross ist, dann setze es doch mal online

 

[Forumaner]

Hallo marlob.

Du schreibst, das du eine Visu da dran hängen hast. Wird das Bit vielleicht von dort beschrieben. Welche Visu ist das und tritt das Problem auch auf, wenn die Visu abgekoppelt ist. Wenn das Projekt nicht zu gross ist, dann setze es doch mal online

Es werden auch Bits von der Visu (InTouch) gesetzt, ja, aber das Problem tritt nur in einem bestimmten Byte im DB auf.
Jedes andere Byte im DB hat nicht dieses fehlerhafte Verhalten.
Es ändert nichts, wenn die Visu abgekoppelt wird. Die Bits im bestimmten Byte werden willkürlich true/false.
Das Programm brauche ich nicht hochladen, denn 1. bin ich nicht mehr auf der Arbeit und 2. handelt es sich quasi nur um Lade-Transferiere-Befehle (vereinfacht gesagt) wie im Beispiel meines ersten Beitrags.

Jedenfalls läuft das Programm, wenn ich den "fehlerhaften" Bytebereich meide.
Ich habe das Byte im DB kommentiert, damit es kein anderer mehr verwendet.
Mir reichts so. Aber so wie es aussieht, bin ich der einzige, der damit ein Problem hat...

MfG,
Forumaner

 

[Kai]

Hast Du mal versucht, dass Programm stückweise in Betrieb zu nehmen? Also im OB1 in der ersten Programmzeile die Anweisung BEA schreiben, so dass der nachfolgende Programmcode nicht bearbeitet wird. Werden im DB10.DBB0 die Bits immer noch willkürlich gesetzt? Wenn nein, dann die Anweisung BEA ein paar Netzwerke nach hinten verschieben, also einen Teil des Programmcodes in Betrieb nehmen. Werden die Bits jetzt willkürlich gesetzt? Wenn nein, die Anweisung BEA weiter nach hinten verschieben usw.

Gruß Kai

 

[mad_max]

Zuviel Werbung?
-> Hier kostenlos registrieren

Datenbaustein defekt??

Hallo,

ich würde versuchen den Datenbaustein zu initialisieren.Hatte ein ähnliches Problem und konnte dies durch initialisieren beseitigen.


MfG

max

 

[hovonlo]

Der Nachweis des Nicht-Fehlers der Hardware lässt sich sehr leicht führen:
Die Bausteine in einer anderen Reihenfolge in die CPU laden.

- Ist dann weiterhin das besagte wacklige Byte betroffen ist es nicht die Hardware, sondern entweder das Programm, oder die Visu oder ein umkopierter Taktmerker oder ..

- Hört das Gezappel dann auf, dann sollte die CPU zur Reparatur geschickt werden.

 

[Forumaner]

Hallo.

Hast Du mal versucht, dass Programm stückweise in Betrieb zu nehmen?

Ich habe für jeden Funktionsteil einzelne Bausteine, um das Programm übersichtlich zu halten.
Für die Kopplung benutze ich nur einen FC, der Daten in den DB schreibt und ausliest.
Da die Anlage schon in Betrieb ist, kann ich nicht mal einfach so einzelne Bausteine im OB1 deaktivieren.
Aber die Idee ist gut, vielleicht bekomme ich morgen ein wenig Zeit und werde dann nur den FC aufrufen, der mit dem DB kommuniziert.

ich würde versuchen den Datenbaustein zu initialisieren.

Hhm, mit initialisieren meinst du den DB mit Default-Werten füllen?
Ich habe es zwar noch nicht ausprobiert, aber ich glaube nicht, dass das funktioniert, denn ich kann die Operanden auch nicht auf true/false mit STEP7 steuern.

Der Nachweis des Nicht-Fehlers der Hardware lässt sich sehr leicht führen:
Die Bausteine in einer anderen Reihenfolge in die CPU laden.
- Hört das Gezappel dann auf, dann sollte die CPU zur Reparatur geschickt werden.

Das kann ich leider auch erst morgen ausprobieren.
Kann das echt an der Reihenfolge liegen?

Gruß,
Forumaner

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann das echt an der Reihenfolge liegen?

nein, nur dann würde ein möglicher fehler der hardware (z.B. defekter RAM) evtl. in einem anderen bereich deines programms auftreten ...

 

[Forumaner]

Hallo an alle.

Ich habe die Tipps in die Tat umgesetzt, aber das Ergebnis ist immer noch das selbe.
Der ein Byte breite Bereich im DB spinnt nach wie vor rum.
Das DBB0 in meinem Startposting war nur als Beispiel gewählt, in Wirklichkeit sitzt das Byte "mitten im DB" und davor sowie dahinter arbeiten die Bits wie sie auch sollen.

Vielleicht ist wirklich ein Byte defekt?!
Aber solange es sich nur auf dieses eine Byte auswirkt, wir diesen Speicherbereich meiden und keiner den Kommentar löscht, können wir damit leben.

Gruß und vielen Dank für euer Kopfzerbrechen,
Forumaner

 

[MSB]

Also ich sehe im Prinzip 2 Möglichkeiten:
- Du hast in deinem Programm trotzdem irgendwas, was dir in die Suppe spuckt
- Es ist ein Bug in der Firmware der CPU

Passiert das auch wenn du nur den DB rüberschiebst, ohne Programm außenrum?

Mfg
Manuel

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube wirklich nicht, daß ein Byte defekt ist. Viel eher ist wirklich eine verunglückte indirekte Adressierung oder sogar ein Bug in der Firmware der SPS schuld. Ich hatte das allerdings auch schon, daß ein Ausgang gesetzt wurde, (war zufällig eine rote Leuchte), obwohl er im Programm noch gar nicht verwendet wurde, so kam ich erst darauf. Ein wirklich häßlicher Fehler ist z.Bsp. ein Überlaufen des Lokaldatenstacks. Das kann exakt zu derartigen Ergebnissen führen. Bei einigen CPU (318, Speed7, 400-er) kann man den Stack vergrößern, das mache ich inzwischen schon standardmäßig. Versuch mal 3 lange Strings (254) zu verarbeiten, z.Bsp. in SCL, da ist bei Step7 aber alles vorbei, ist eben nicht für so was gedacht, leider.

PS: Die benötigten Lokaldaten kann man ansehen, irgendwo bei Eigenschaften der Bausteine. Wenn man viele Bausteine ineinander schachtelt, kann das bei vielen Variablen im Temp-Bereich problematisch werden.

 

[Forumaner]

Hallo.

Also ich sehe im Prinzip 2 Möglichkeiten:
- Du hast in deinem Programm trotzdem irgendwas, was dir in die Suppe spuckt
- Es ist ein Bug in der Firmware der CPU

Viel eher ist wirklich eine verunglückte indirekte Adressierung oder sogar ein Bug in der Firmware der SPS schuld.

Dass mir das Programm etwas durcheinander bringt, das kann ich 100%-ig ausschließen! Und eine indirekte Adressierung gibt es nicht.
Dann wird es wohl in dieser Hinsicht eher ein Bug in der Firmware sein.

Passiert das auch wenn du nur den DB rüberschiebst, ohne Programm außenrum?

Ich habe jeden Baustein einzeln übertragen und mir den Status der besagten Bits angeguckt. Auch wenn nur der DB einzeln auf der CPU ist, werden die Bits gesetzt.

IDEE: Aber vielleicht liegt es nicht an einem Bug in der Firmware und das Byte ist nicht defekt:
Kann es sein, dass ich von anderen Steuerungen Signale empfange?
Die CPU ist nämlich via TCP/IP ans Netzwerk angebunden (schaufelt Daten von A nach B).
Es ist doch auch möglich, dass mir eine andere Steuerung Bits sendet, die genau auf die Adressierung meines DB passen?!
Nur um das zu testen, das wird kritisch, da viele Anlagen mit den Daten versorgt werden.

Gruß,
Forumaner

 

[OHGN]

IDEE: Aber vielleicht liegt es nicht an einem Bug in der Firmware und das Byte ist nicht defekt:
Kann es sein, dass ich von anderen Steuerungen Signale empfange?
Die CPU ist nämlich via TCP/IP ans Netzwerk angebunden (schaufelt Daten von A nach B).
Es ist doch auch möglich, dass mir eine andere Steuerung Bits sendet, die genau auf die Adressierung meines DB passen?!
Nur um das zu testen, das wird kritisch, da viele Anlagen mit den Daten versorgt werden.

Gruß,
Forumaner

Das könnte ich mir gut vorstellen, z.B. wenn in einer anderen CPU beispielsweise der SFB15 "PUT" aufgerufen wird und auf den genannten Datenbereich deiner CPU zugreift.
Trenne doch einfach mal Deine CPU vom TCP/IP Netzwerk und schau mal ob das Phänomen immer noch auftritt.

 

[kpeter]

Zuviel Werbung?
-> Hier kostenlos registrieren

hallöchen

hast du mal was ganz einfaches getest

spiel dein programm in denn simulator und teste es dort
ist dort der gleiche fehler ????

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

du wirst doch denn baustein schon des öfteren in deine s7 gespielt haben
dann steht der baustein immer an einer anderen adresse also ist das mit defekten speicherplatz fast nicht möglich

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

leg mal in deinen programm alles still zieh alle leitungen ab das deine s7 alleine ist und wenn du dann noch immer das problem hast dann .... sollte es wirklich die firmware sein

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

und natürlich kann es sein das dir jemand was auf deinen db spielt wenn mehrere sps daten zu dir übertragen

 

[Ralle]

und natürlich kann es sein das dir jemand was auf deinen db spielt wenn mehrere sps daten zu dir übertragen

Das würde ich mal am wahrscheinlichsten annehmen, wenn er Programmierfehler, bzw. indirekte Adressierung ausschließen kann. Auch ein HMI kann einem ganz nett Daten in einen DB reinschießen und zwar unabhängig vom SPS-Zyklus.

 

[Jordy]

Das gleiche hatte ich auch schonmal. Konnte ein Doppelwort im DB nicht richtig beschreiben. War auch kein Programmfehler, da es drei Identische Maschinen waren mit 3 Identischen CPUS und Prorammen.

Wenn ich ein Merker genommen habe oder einen anderen Datenbereich im DB, wars kein Problem.

Naja, habe stundenlang gesucht, aber nichts gefunden (bei den anderen beiden Anlagen trat das Problem auch nciht auf)

Im Endeffekt musste ich den DB noch verschieben, wegen Programmänderung, dadurch war das Problem dann auch gelöst.