CLR Befehlt

[netmaster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Morgen zusammen,

ich habe ein mir unerklärliches Verhalten beobachtet.
Ein Kollege von mir hat folgendes Programmiert.

CLR
R DBX253.1

Normal sollte es doch so sein, das der CLR Befehl das Bit nicht zurücksetzt, oder besser gesagt keinen Einfluss hat.
Aber so lang diese Zeile im Programm ist kann ich das Bit vom Touch nicht setzten.
Indirekte und doppelte Belegung habe ich schon geprüft. Das Bit wird auch nur einmal schreibent verwendet genau an dieser Stelle.

Was mir noch aufgefallen ist, in PLCSIM funktioniert es richtig. Aber in einer S7-313C kann ich das Bit nicht setzte.
Vielleicht hat von euch einer eine Idee was das sein könnte. Im Anhang ein Screenshort online mit einer CPU, hier sieht man das das VKE 0 ist.


Über Sinn oder Unsinn von diesen zwei Zeilen mal abgesehen.

 

[borromeus]

Diese zwei Zeilen machen mal "nichts".
Nach CLR ist VKE 0
R Bit wird daher nicht durchgeführt, da VKE-abhängig.

Weitere Spekulationen, z.B. ob der DB der richtige ist unterlasse ich, weil wenns im PLCSIM funzt und auf der CPU nicht gibts m.E. ein Megaproblem.

OK:
ich vermute das Bit wird im Touch GESETZT, in der SPS wird es gelesen und am Ende soll es wieder auf 0 geschrieben werden- also ne Tastenfunktion (ist das so?)
Schreib mal:

U DBX253.1
R DBX253.1

 

[netmaster]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein dies ist nur drin weil mehere Antrieb diese Struktur haben, nur bei diesen Antrieb soll es von der SPS nicht zurückgesetzt werden können.
Es sollte aber in der Querverweisliste auftauchen. Das wenn mal ein Rücksetztebefehl kommt der an dieser Stelle reinkommen soll.

Des es nichts machen soll war auch meine Meinung. Aber dies stimmt nicht. Was ich selber sehr komisch finde.
Im Touch ist nur inventiere Bit.
Wenn genau diese zwei Zeilen im Programm sind, kann es das Touch nicht setzten. Kommentiere ich diese zwei Zeilen aus kann das Touch das Bit wieder setzten.
Aber ich bin der festen Meinung das sollte keinen Einfluss haben ob ich diese zwei Zeilen genau so im Programm habe oder nicht.

 

[borromeus]

Nur so interessehalber, wie hast Du das mit PLCSIM probiert?

 

[netmaster]

PLCSIM gestartet, Programm eingespielt. PLCSIM auf RUN
WinCC flexible gestartet, dann Runtime gestartet.

Dann meine Anlage Störungsfrei gemacht und den notwendigen Betriebszustand hergestellt.
Jetzt dann den Taster gedrückt.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK, also Unterschied ist sicher, dass die WinCC Runtime am PC sicher anders mit PLCSIM kommuniziert als ein OP mit der SPS.
Wenngleich das so ist, kann ich Dir leider trotzdem nicht sagen was an:
CLR
R
nun so "böse" ist.

Aber irgendwer wird schon eine Idee haben, Hexen gibts ja nicht.

 

[Aventinus]

Da bin ich auch neugierig, aber im schlimmsten Fall würde ich Siemens kontaktieren...
Meiner Meinung nach sollten die beiden Zeilen keinen Einfluss haben.

 

[netmaster]

So gehts mir auch.
Werde des dann heute mal an Siemens weiter geben. Ob die eine Erklärung dafür haben.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
es ist vielleicht nicht so unbedingt eine Frage, wie wir den Code aus unserem Verständnis der Befehle übersetzen sondern was als MC7-Code hinterher dabei heraus kommt ... Es kann ja sein, dass da eine freie Interpretation dieser Befehls-Sequenz stattfindet.

Aber was mich mal interessiert : was passiert denn, wenn du an Stelle des CLR ein SET dahin schreibst ?

Gruß
Larry

 

[borromeus]

klug gesprochen.....
was kommt denn wirklich raus aus dem AWL?
Soweit ich weiss gibts da ja auch einen Compiler...

 

[Aventinus]

Hallo,
es ist vielleicht nicht so unbedingt eine Frage, wie wir den Code aus unserem Verständnis der Befehle übersetzen sondern was als MC7-Code hinterher dabei heraus kommt ... Es kann ja sein, dass da eine freie Interpretation dieser Befehls-Sequenz stattfindet.

Aber was mich mal interessiert : was passiert denn, wenn du an Stelle des CLR ein SET dahin schreibst ?

Gruß
Larry

Was aber dann wieder nicht erklärt, warum sich PLCSim und reale SPS unterschiedlich verhalten.

Ausserdem, Auszüge aus der Online-Hilfe:

CLR setzt das VKE auf den Signalzustand "0".

R (Rücksetze Bit) schreibt bei VKE = 1 und bei eingeschaltetem Master Control Relay (MCR = 1) den Wert "0" in das adressierte Bit. Bei MCR = 0 wird das adressierte Bit nicht verändert.

Demzufolge macht der TE was mit dem MCR

EDIT: die liebe Rechtschreibung

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bin gespannt wie das ausgeht....
CLR
R
DARF nichts rücksetzen, dann würde ja keine Anlage funktionieren....
umgekeht würde ich es ja akzeptieren, im PLCSIM nicht funktionierend.... aber auf der SPS schon....

 

[PN/DP]

Genau! CLR + R dürfen keinen Einfluß auf das DBX253.1 haben. Wenn doch, dann muß das ein Firmwarefehler sein.

Oder wurde vielleicht nur das CLR auskommentiert?

Harald

 

[borromeus]

Er schreibt:
"Wenn genau diese zwei Zeilen im Programm sind, kann es das Touch nicht setzten. Kommentiere ich diese zwei Zeilen aus kann das Touch das Bit wieder setzten."

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

So gehts mir auch.
Werde des dann heute mal an Siemens weiter geben. Ob die eine Erklärung dafür haben.

Und, gibts schon eine Erklärung.
Würde mich brennend interessieren.

 

[netmaster]

Bin zur Zeit auf IBN und deswegen mit diesen Problem noch nicht weitergekommen.
Werde euch aber eine Rückmeldung geben.

 

[Herbert]

Hast du auch alle Bausteine Online/Offline verglichen, bevor du in den Ref. Daten nach der Verwendungstelle geguckt hast? Kann ja eingentlich nicht sein das der Befehl ausgeführt wird wenn CLR davor steht.