Step7V11 (TIA-Portal) - Merkerzustand nicht eindeutig

[Frank12NR]

Heyho.
Heute tauchte an mehreren Schülerrechnern folgender Fehler auf:

Ein Merker (physischer, keine Variable), der im ersten Netzwerk auf den Zustand "1" gesetzt wurde, wurde im zweiten und dritten Netzwerk weiterverwendet.

Im zweiten Netzwerk wurde er als Verriegelung verwendet und dabei am Eingang des Netzwerks erstmal negiert.

Im 3. Netzwerk wurde er ganz normal - also nicht negiert - weiterverwendet.

Soweit, so gut. Nun trat der Fehler auf, dass der Merker im zweiten Netzwerk - also vor der Negierung - den Wert 0 hatte. Entsprechend funktionierte die ganze Schaltung nicht so, wie sie sollte.

Der Fehler war nur "halb-reproduzierbar": An zwei Schülerrechnern trat er auf, an zwei weiteren, auf die wir probeweise das Programm überspielten, verhielt sich der Merker, wie er sollte.

Kennt jemand diesen Fehler? Ist das möglicherweise einer der vielen Bugs, die in Step7V11 wohl noch drinstecken? (aktuell ist wohl 13, unsere Schule plant erst bei 14 das nächste Upgrade).

Oder kann das ein Hardwarefehler sein? (m.E. eher unwahrscheinlich, da er an mehreren Rechnern auftauchte)

Gruß,
Frank

[IH-Elektriker]

Normal kann sowas dann auftreten wenn jemand auf einen Merker oder Augang zweimal in einem Programm schreibend zugreift.

Dank der sequentiellen Programmabarbeitung wird das nix....

Betreffend TIA-Portal - ab V13 kann man daran denken damit zu arbeiten, dann sind wohl die allerschlimmsten Fehler raus und die übriggebliebenen "nur" noch nervig. Zumindest haben das Kollegen gesagt welche das Portal schon getestet haben.

Was interessant wäre - läuft das S7-Programm auf einer CPU oder auf einem SW-Simulator ab ?

Eventuell kannst Du ja mal die Netzwerke als Ausdruck posten....

[Frank12NR]

Hi,
das Programm zeigt den Fehler sowohl in der PLCSim-Simulation als auch an einer echten SPS (ET200s).

Im Anhang sind drei Bilder aus dem Beobachten-Modus, in dem das Problem deutlich wird. Beim problematischen Merker handelt es sich um M1.0. Ich hatte in der Beschreibung oben allerdings die Netzwerke vertauscht: In NW3 tritt der Fehler auf, nicht in NW2.

Gut zu erkennen: Der Merker meldet eigentlich "true", die Zuleitung ist aber blau gestrichelt (=false).

Dass es sich um einen Anzeigefehler handelt (wäre mein erster Tip gewesen), kann ich ausschließen, da der Zähler immer wieder neu startet. Da wird also tatsächlich ständig zurückgesetzt.

Zu guter Letzt: Der Anhang ist das gesamte Programm. Es wird also außer im NW1 nirgends schreibend auf besagten Merer zugegriffen.

Gruß,
Frank

EDIT: Kleiner Nachtrag: Auch die Freigabebedingungen S0 und Motorschutz werden nicht geändert, sie werden bei uns über Schalter mit Raststellung simuliert. Der MErker wird also definitiv nicht zurückgesetzt.

[Klein-Eli]

Hallo Frank,

habt ihr nur den Baustein getestet oder habt ihr die Systemeinstellungen auch mit auf die anderen PC's übertragen?
Ev. Taktmerkerbyte auf diesen Bereich eingestellt?

[Frank12NR]

Hallo Frank,

habt ihr nur den Baustein getestet oder habt ihr die Systemeinstellungen auch mit auf die anderen PC's übertragen?
Ev. Taktmerkerbyte auf diesen Bereich eingestellt?

Hi Klein-Eli
Wir haben nur die Software übertragen, allerdings sind die Hardwarekonfigurationen überall identisch, die Schüler ziehen sie immer am Anfang der Stunde vom gemeinsamen Poollaufwerk.

Der Merker 1.0 an sich funktioniert normalerweise einwandfrei, an einer Fehlerhaften Zuweisung kann es deshalb m.E. auch nicht liegen.

Je mehr ich drüber nachdenke, desto mehr glaube ich wirklich an einen Fehler von Siemens-Seite. Allein die Tatsache, dass "True" dransteht, der Eingang aber offenbar mit "False" belegt ist, schließt ja eigentlich einen Fehler von uns schon aus. Werde nächste Woche mal ausprobieren, wie ernst es unserem Siemens-Kontaktmann mit "Sie können jederzeit anrufen" ist :-)

Gruß,
Fraknk

[IH-Elektriker]

Das Verhalten ist in der Tat komisch. Frag mal bei Siemens nach was die dazu sagen....

[DBY656]

Hallo zusammen,
mit dem TIA-Portal habe ich zwar bisher noch nie programmiert und meine letzten S7-Programmierungen liegen auch schon eine Zeit zurück. Trotzdem fällt mir an
der FUP-Darstellung etwas auf.
Über der Eischaltverzögerung steht eine Zeit, und diese ist unter der programmierten Zeit von 3 Sekunden.
Wird der gleiche Timer in einem anderen Baustein ein weiteres mal angesprochen?

Gruß Markus

[Frank12NR]

Hi Markus.

Über der Eischaltverzögerung steht eine Zeit, und diese ist unter der programmierten Zeit von 3 Sekunden.

Das liegt daran, dass der Screenshot im Beobachtungsmodus gemacht wurde, während das Programm läuft. Die Zeit oben ist die, die aktuell noch ablaufen muss, die links ist die Gesamtzeitvorgabe.

Wird der gleiche Timer in einem anderen Baustein ein weiteres mal angesprochen?

Gruß Markus

Wie geschrieben, das ist das komplette Programm.

Gruß,
Frank

[DBY656]

Hallo Frank,
wie sieht das AWL-Listing dazu aus?

Da laut deinen Angaben die Zeit immer wieder vom neuen Anläuft, tippe ich schwer auf eine falsche Timer-Type. Die Reaktion des Systems ist wie bei einer normalen Einschaltverzögerung (SE), gebraucht wird aber eine speichernde Eischaltverzögerung (SS).

Gruß Markus

[Frank12NR]

Hallo Frank,
wie sieht das AWL-Listing dazu aus?

Da laut deinen Angaben die Zeit immer wieder vom neuen Anläuft, tippe ich schwer auf eine falsche Timer-Type. Die Reaktion des Systems ist wie bei einer normalen Einschaltverzögerung (SE), gebraucht wird aber eine speichernde Eischaltverzögerung (SS).

Gruß Markus

Hi Markus,
an die AWL komm ich im Moment leider nicht ran, mein Step7 auf dem Laptop hat's zerschossen.

Das eigentliche Problem mit dem M1.0, ist sowieso vom Zeitglied auch unabhängig. Man sieht ja im Beobachten-Modus, dass er im NW3 offenbar zwei Zustände gleichzeitig hat. Dieser Merker wird aber nicht vom Zeitglied angesteuert, damit kann's m.E. nichts zu tun haben.

Gruß,
Frank