TIA Misteriösitäten im Bausteinkopf eines FC bei Temp-Variable

[Outrider]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe eine 1515-F CPU
in der befindet sich ein FC mit Temp-Variablen.
Habe folgendes Problem, die Bool-Variable mit dem Offset 10.2 im Kopf ist auf True gesetzt ohne dass im Programm diese Variable bearbeitet wird, den es gibt gar kein Code in diesem FC.
Frage, wer setzt diese Variable, und wie kann ich das ausfindig machen?
Kann man nicht irgendwie Generell durch einen Befehl alle Temp-Werte auf Null setzen bevor man in den FC einsteigt ?
Ich könnte sicherlich per Hand jeden Wert Null-setzen !
Danke

 

[Manfred Stangl]

die sind ja beim Aufrufen undefiniert. Also im 1 NW beschreiben...Das ist ein alter Hut...

 

[Outrider]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was mich bei TIA und vor allem bei den 1500er wundert dass das so ist, dabei ist doch alles "durchdachter" und mann kann nicht mal eben.... was auch immer (Pfuschen)

 

[vollmi]

Erstaunlich das er beim übersetzen keine Warnung wirft. TIA wirft sonst bei den üblichen Pfusch wie hier immer ne Warnung.

mfG René

 

[oliver.tonn]

Das ist aber auch bei anderen SPS-Herstellern so, das nicht initilisierte Variablen "Zufallswerte" enthalten. Die Temp-Variablen sollen ja temporäre (Daher der Name) Zwischenergebnisse enthalten und die überschreiben dann ja eh den bisherigen Inhalt, so das es egal ist, ob und was da vorher drin stand.

Von irgendwas mit Internetzugang gesendet

 

[Outrider]

Zuviel Werbung?
-> Hier kostenlos registrieren

Gefährlich wirds aber wenn man die Temp-Variable direkt abfragt ohne sie vorher gesetzt zu haben und damit z.B. ein Ventil steuert.

 

[DeltaMikeAir]

Gefährlich wirds aber wenn man die Temp-Variable direkt abfragt ohne sie vorher gesetzt zu haben und damit z.B. ein Ventil steuert.

Ja, dies ist ein bekanntes Verhalten, auch schon zu Step 7 Zeiten. Daher wie bereits weiter oben beschrieben, wenn man diese Temp Variablen
nutzen möchte, zuerst Werte zuweisen oder rücksetzen.

 

[RONIN]

Wobei es bei 1500 zwei Fälle gibt...

Bei "optimierten" Bausteinen wird der L-Stack sehr wohl mit 0 initialisiert.
Bei "nicht optimierten" Bausteinen wird das Verhalten der 300/400 nachgestellt und nicht initialisiert... Schöner Blödsinn....

Der Lokaldatenspeicher ist ein einfacher Stack-Speicher der bei 300/400 nicht initialisiert wird, deshalb bekommt man dort quasi die Werte die andere Bausteine dort abgelegt haben.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wobei es bei 1500 zwei Fälle gibt...

Bei "optimierten" Bausteinen wird der L-Stack sehr wohl mit 0 initialisiert.
Bei "nicht optimierten" Bausteinen wird das Verhalten der 300/400 nachgestellt und nicht initialisiert... Schöner Blödsinn....

Hat man vermutlich aus kompatiblitätsgründen beibehalten. Gibt sicher Programme wo der Programmierer besonders gewitzt sein wollte und sich auf den inhalt des Lokaldatenstacks verlässt. Also in einem Baustein Temporäre Variablen beschreibt und im nächsten Baustein genau die Daten erwartet.

mfG René

 

[oliver.tonn]

Gefährlich wirds aber wenn man die Temp-Variable direkt abfragt ohne sie vorher gesetzt zu haben und damit z.B. ein Ventil steuert.

Dann nutzt man sie aber auch falsch und das Problem hat man dann, wie schon erwähnt, auch bei anderen SPS-Herstellern. Nochmals, eine Temp-Variable ist zur Aufnahme von Zwischenergebnissen dar, und Dein Beispiel mit dem Ventil ist kein Zwischenergebnis, sondern je nach vorliegender Bedingung, schon am Anfang das Endergebnis und somit kein Kandidat für eine Temp-Variable.

 

[Outrider]

Bei mir ist der Fehler aufgetreten als ich in diesem Baustein einen FB aufgerufen habe, der hatte eine INOUT Variable, und gerade diese habe ich mit einer Temp-Variable belegt, diese sollte dann paar Netzwerke später benutzt werden. :-(
Gruß

 

[Outrider]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei mir ist dieser Fehler aufgetreten, als ich einen FB aufgerufen habe der eine INOUT Variable hatte. Diese Variable wurde aus dem FC mit Temp-Variablen belegt, die dann paar Netzwerke später benutzt werden :-(
Gruß

 

[PN/DP]

Bei "optimierten" Bausteinen wird der L-Stack sehr wohl mit 0 initialisiert.
Bei "nicht optimierten" Bausteinen wird das Verhalten der 300/400 nachgestellt und nicht initialisiert... Schöner Blödsinn....

Ich meine eher, das "Schöner Blödsinn" gehört an den ersten Punkt: das eigentlich völlig unnötige generelle Initialisieren des L-Stack. Ich glaube das wurde extra eingeführt eben weil so viele Programmierer nicht wissen wie sich temporäre Variablen verhalten... das war offensichtlich ein Punkt ganz oben auf der Liste der notwendigen "Innovationen", damit jeder Idiot ein Programm für eine S7-1200/1500 zusammenklicken kann.

Harald

 

[DeltaMikeAir]

Ich glaube das wurde extra eingeführt eben weil so viele Programmierer nicht wissen wie sich temporäre Variablen verhalten

Das ist durchaus möglich. Vielleicht war dass immer wieder Thema beim technischen Support und man wollte dass so lösen.

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zumal es diesen "Luxus" in vielen anderen Programmiersprachen gar nicht gibt.

 

[PN/DP]

@Outrider
Ist Dein FC als "optimiert" oder mit Standard-Zugriff eingestellt?

Harald

 

[RONIN]

Bei mir ist der Fehler aufgetreten als ich in diesem Baustein einen FB aufgerufen habe, der hatte eine INOUT Variable, und gerade diese habe ich mit einer Temp-Variable belegt, diese sollte dann paar Netzwerke später benutzt werden. :-(

INOUT heißt nunmal das der Wert zuerst gelesen wird... Wenn da dann nix gültiges drin steht...

Ich meine eher, das "Schöner Blödsinn" gehört an den ersten Punkt: das eigentlich völlig unnötige generelle Initialisieren des L-Stack...

Da bin ich eh voll bei dir. Blödsinn ist nur weil man es nicht uniform gemacht hat.
Aber da hätte man möglicherweise irgendwelche crazy KnowHow-Schutz-Temp-Übergabe-Konzepte aus Step5 Zeit zerschossen...