Step 7 Zähler in SCL

Zuviel Werbung?
-> Hier kostenlos registrieren
Was ich jetzt bei der ganzen TAKT-Geschichte immer noch nicht verstanden habe (obwohl ich mich wirklich bemüht habe ;)) ist, welchen Sinn das Alles in Verbindung mit dem Counter hat ...

Gruß
Larry

Also, erst einmal lieben Dank euch allen! Im Grunde wollte ich halt mal einen Flanken- u. Impulsoperanden in SCL programmieren. Und um zu sehen, ob es klappt musste ein Zähler herhalten. Und dann kamen all die komischen Dinge zum Vorschein... :p
Zwar schreiben alle eine Flanke ist bei einem Zähler nicht notwendig; aber wenn er beispielsweise zählen soll, wenn etwas die LS verlässt, so muss man doch mit einer (negativen) Flanke arbeiten (egal ob in FUP, AWL, SCL), oder etwa nicht?

Du hast aber gelesen, dass das mit dem Flankenmerker bei einem Counter nicht wirklich Sinn machen würde ... ?

In SCL-Code sähe das dann z.B. so aus :
Code:
TAKT := Eingang and not FM ;
FM := Eingang ;
// TAKT kann hier ein TEMP sein
// FM muss hier ein STAT sein
Gruß Larry

Tja gelesen schon Larry, aber siehe oben... die Erklärung steht leider noch aus! ;)

Achja, und da wir leider schon wieder bei der Fragestunde angekommen sind; warum darf denn TAKT hier plötzlich eine temporäre Variable sein? Die könnte doch auch von anderen Bausteinen überschrieben werden oder hängt das damit zusammen, dass eine Flanke eh nur immer für einen Zyklus aktiv ist?
 
Achja, und da wir leider schon wieder bei der Fragestunde angekommen sind; warum darf denn TAKT hier plötzlich eine temporäre Variable sein? Die könnte doch auch von anderen Bausteinen überschrieben werden oder hängt das damit zusammen, dass eine Flanke eh nur immer für einen Zyklus aktiv ist?

In dem Beispiel von mir, auf das du dich beziehst, wird TAKT vor seiner ersten Verwendung im weiteren Programm zugewiesen.
Code:
TAKT := Eingang and not FM ; FM := Eingang ; // TAKT kann hier ein TEMP sein // FM muss hier ein STAT sein
... wenn du nun TAKT erst ab dieser Zuweisung verwendest (denn anders würde es ohnehin keinen Sinn machen) dann ist er nicht/nie undefiniert.

Ist das mit der Flanken-Bildung in SCL denn nun klar ?

Im Prinzip gilt :
TEMP := Variablen, die eine Art Zwischenergebnis bilden und die IMMER erst nach ihrer Zuweisung weiterverwendet werden.
STAT := Variablen, die ihren Wert über einen oder mehrere Programmzyklen (also eine unbestimmte Zeitdauer) nach ihrer Zuweisung behalten/speichern sollen.

Selbstverständlich ist es nie falsch, wenn man eine Variable, die eigentlich eine TEMP sein könnte, als STAT deklariert (es nützt nichts - es schadet aber auch nicht).
Für Probier-Aktionen kann das sogar ganz nützlich sein ...

Gruß
Larry
 
In dem Beispiel von mir, auf das du dich beziehst, wird TAKT vor seiner ersten Verwendung im weiteren Programm zugewiesen.
Code:
TAKT := Eingang and not FM ; FM := Eingang ; // TAKT kann hier ein TEMP sein // FM muss hier ein STAT sein
... wenn du nun TAKT erst ab dieser Zuweisung verwendest (denn anders würde es ohnehin keinen Sinn machen) dann ist er nicht/nie undefiniert.

Ist das mit der Flanken-Bildung in SCL denn nun klar ?

Gruß
Larry

Naja Larry, glaube noch nicht so ganz. Das heißt die Flankenbildung ist mir schon klar, aber nicht, warum TAKT plötzlich auch eine Temp-Variable sein kann. TAKT wird mehrmals im Programm abgefragt und an einer Stelle zugewiesen. Klar ist TAKT dann nicht undefiniert, aber die Temp-Variable könnte doch dennoch von einem anderen Baustein überschrieben werden, oder etwa nicht? Denn das ist doch das blöde an diesen Temp-Dingern, dass deren Speicherbereich auch von anderen Bausteinen mitverwendet werden...

Lieben Dank!
 
... aber die Temp-Variable könnte doch dennoch von einem anderen Baustein überschrieben werden, oder etwa nicht? Denn das ist doch das blöde an diesen Temp-Dingern, dass deren Speicherbereich auch von anderen Bausteinen mitverwendet werden ...

Nein ... in dem Baustein und solange der Baustein aktiv ist gehört die TEMP-Variable bzw. der von ihr beanspruchte Speicher nur und ganz exklusiv dem Baustein - selbst dann, wenn du in dem Baustein wieder einen anderen Baustein aufrufst.
Wird eine TEMP-Variable am Anfang des Bausteins zugewiesen so behält sie diesen Wert (es sein denn es erfolgt eine neue Zuweisung durch dich) bis zum Ende des Bausteins.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein ... in dem Baustein und solange der Baustein aktiv ist gehört die TEMP-Variable bzw. der von ihr beanspruchte Speicher nur und ganz exklusiv dem Baustein.

Gruß
Larry

OK Larry, aber wie kann dann (wie so oft hier beschrieben) ein anderer Baustein in diesen Temp-Bereich reinpfuschen? Dann ist doch die Verwendung von Temp-Var. gar nicht so gefährlich...
 
Also bei den Temp Variablen geht es eher darum das du dort Beispielsweiße etwas mit einer Positiven Flanke speicherst!
Es ist aber nicht sichergestellt das im nächsten Zyklus der Wert odgl. auch noch Plausibel bzw. generell vorhanden ist!
Deshalb verwendet man dann Statische Variablen oder Merker dafür!

Mfg
 
Danke SCM,

aber eine Flanke wirkt doch eh nur für einen Zyklus...

Das heißt also doch, dass während eines Bausteinaufrufes die in diesem Baustein deklarierten Temp-Variablen (Speicherbereich) ausschließlich von dem aktuell aufgerufenem Baustein genutzt werden. Dann kann doch eigentlich niemals ein anderer Baustein da auch was hineinschreiben, solange der ursprüngl. Baustein abgearbeitet wird. Insofern verstehe ich nicht ganz, wo das Problem bei diesen Temp-Variablen liegt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
aber eine Flanke wirkt doch eh nur für einen Zyklus...
Die Flanke ja, aber der Flankenmerker nicht!

Ein Flankenmerker speichert den Zustand des Inputs vom vorigen Zyklus, deshalb muss er zyklusübergreifend gespeichert werden. Und genau da wäre das Problem bei den Temp-Variablen. Deren Speicherplatz wird bei Beendigung des Bausteins wieder freigegeben und kann damit ggf. von anderen Bausteinen überschrieben werden.
 
Zum komplettieren (gibt's aber auch 'ne FAQ zu) ->

So würde man die Flankenbildung per Hand in AWL programmieren:
Code:
U  #Eingang_jetzt
UN #Eingang_vorher
=  #Flanke_positiv

UN #Eingang_jetzt
U  #Eingang_vorher
=  #Flanke_negativ

U  #Eingang_jetzt
=  #Eingang_vorher

bzw. so in SCL:
Code:
#Flanke_positiv=: #Eingang_jetzt AND NOT #Eingang_vorher;
#Flanke_negativ=: NOT #Eingang_jetzt AND #Eingang_vorher;
#Eingang_vorher=: #Eingang_jetzt;
Die beiden Flanken können temp sein, weil sie erst zugewiesen werden und dann irgendwann gelesen. Beim Flankenmerker "#Eingang_vorher" wird erst die Zuweisung aus dem letzten Zyklus gelesen und dann die neue Zuweisung getätigt = zyklusübergreifend, daher statisch.

Die eingebaute S7-Flanke macht genau das - Zustände von Eingang und Flankenmerker vergleichen, Zustand von Eingang im Flankenmerker speichern. Deshalb kann man jeden Flankenmerker auch nur einmal im Zyklus nutzen. Bei einer weiteren Benutzung im gleichen Zyklus würde man keine Flanke mehr feststellen, da der Flankenmerker mittlerweile den gleichen Zustand wie der Eingang bekommen hat.
 
Das nächste ist das ein aktueller Baustein auch durch einen weckalarm unterbrochen werden kann. Somit könnte eine temp variable beim vortsetzen des Bausteine einen anderen Zustand haben.

Gruß
 
Das nächste ist das ein aktueller Baustein auch durch einen weckalarm unterbrochen werden kann. Somit könnte eine temp variable beim vortsetzen des Bausteine einen anderen Zustand haben.
Also da bin ich mir ziemlich sicher, dass das nicht passiert, weil der Temp-Speicher des unterbrochenen Bausteins reserviert ist und diese Reservierung bestehen bleibt, bis der Baustein wirklich beendet ist und nicht nur unterbrochen.

Was man verändern kann, sind die Adressregister. Deshalb ist es eine gute Angewohnheit, sie vor Benutzung immer zu sichern und anschließend wieder herzustellen.

Zumindest wurde mir das hier im Forum so vermittelt.
:TOOL:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... das wird nicht nur hier im Forum so "vermittelt" ... 8)
Das ist auch wirklich so. Das würde dann ansonsten für einen zwischendurch aufgerufenen Baustein ebenso gelten wie für einen Interrupt-OB. Die jeweiligen Ergebnisse wären nicht mehr kontrollierbar. Nein ... es ist wie Hucky es schreibt.
Im Grunde würde das ansonsten ja auch für unsere FUP-Fraktion (und natürlich auch KOP) katastrophale Folgen haben - wenn man sich mal ansieht wie FUP (und auch KOP) bei manchen Konstrukten so mit den Lokaldaten herumschmeisst ...

Gruß
Larry
 
OK ... habe ich möglicherweise nicht richtig gelesen, was du geschrieben hast :-(
Es ging mir aber auch im Wesentlichen die Aussage ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK ... habe ich möglicherweise nicht richtig gelesen, was du geschrieben hast
Ich hab' mal gelernt, man kann nicht falsch verstehen, man kann nur nicht richtig erklären.
Ich hätte einen größeren Abstand zwischen 1. und 2. Absatz machen sollen.

Und Danke, dass Du meine Aussage noch mal bestätigt hast. Ich hatte schon eine der berühmten Ausnahmen befürchtet, auch wenn die hier nun gar keinen Sinn gemacht hätte. Denn dann könnte man die Temp-Variablen überhaupt nicht nutzen.
 
Die temporären Lokaldaten sind die am besten gekapselten Variablen im S7-Konzept. Auf sie kann nicht von anderen Prozessen zugegriffen werden - auch nicht von anderen OB (die haben ihren eigenen Lokaldatenstack). Nur ein direkt aufgerufener FC oder FB kann mittels Pointer auf die "Vorgänger-Lokaldaten" auf die Lokaldaten des aufrufenden Bausteins zugreifen und diese auch verändern. Solange ein Baustein keinen anderen Baustein aufruft, solange kann er sicher sein, daß nichts "seine" Lokaldaten verändert. Erst wenn ein Baustein beendet wird dann wird der für seine Lokaldaten verwendete Speicher freigegeben und kann anderen Bausteinen zur Nutzung zugeteilt werden - dadurch kann der Inhalt der Speicherstellen verändert werden und wenn der Speicher im nächsten Zyklus dem Baustein wieder zugeteilt wird, dann ist es unbestimmt, welchen Inhalt die Speicherstellen dann haben - daher darf der Inhalt der Lokaldaten erst ausgewertet werden, nachdem ihnen ein Wert zugewiesen wurde.

Harald
 
Also da bin ich mir ziemlich sicher, dass das nicht passiert, weil der Temp-Speicher des unterbrochenen Bausteins reserviert ist und diese Reservierung bestehen bleibt, bis der Baustein wirklich beendet ist und nicht nur unterbrochen.

Was man verändern kann, sind die Adressregister. Deshalb ist es eine gute Angewohnheit, sie vor Benutzung immer zu sichern und anschließend wieder herzustellen.

Zumindest wurde mir das hier im Forum so vermittelt.
:TOOL:

Okay ich war mir da nicht so ganz sicher!Aber wenn ihr das sagt ist es jetzt geiwss!
Ich verwende generell ungern Temp variablen!

Gruß
 
Zurück
Oben