Step 7 Frage zu temporären Variablen bei asynchronen Unterbrechungen( Step7 V5.5 / CPU 315 )

F

Faceman

Level-2
Beiträge
151
Reaktionspunkte
72
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich habe einmal eine kurze Frage. Wenn ich einen FB mit einer temporären Variable ( hv : INT; ) habe, dort innerhalb
des FB´s einen Wert reinschreibe und dann der asynchrone OB35 aufgerufen wird. Dieser FB35 hat auch eine Variable ( hv : INT; ),
wo ein anderer Wert drin steht. Welcher Wert steht in der hv Variable des FB? Also wenn der OB35 abgearbeitet wurde und das
Programm wieder im FB weitergeht? Werden temporäre Variablen beeinflusst, müssen diese "gerettet" werden?

Oder gibt es nur Probleme, wenn die temporäre Variable in beiden Bausteinen den gleichen Namen hat.
In den Siemens DOKU´s konnte ich nichts erklärendes finden.

Vielen Dank für die Hilfe

Programmiersprache SCL
CPU 315-2EH14
Step7 V5.5
 
Jeder Baustein (OB, FC, FB) hat seinen eigenen Bereich im Stack, wo seine eigenen TempVariablen abgelegt sind.
Wird derselbe VariablenName in verschiedenen Bausteinen benutzt, so sind dies verschiedene Variablen (SpeicherPlätze).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist völlig egal wie die Variablen heißen, sie beeinflussen sich nicht gegenseitig. Die temporären Variablen liegen auf verschiedenen Adressen. Da braucht nichts "gerettet" werden.
Außerhalb der Bausteine sind die temporären Variablen nicht bekannt. Ein Baustein kann nicht schauen, ob ein anderer Baustein womöglich gleiche Namen für seine temporären Variablen verwendet.
Es kann passieren, daß ein Baustein für seine temporären Variablen den selben Speicherbereich erhält, den ein anderer bereits beendeter Baustein vorher für seine temporären Variablen verwendet hat. Dann sind da schon irgendwelche "zufälligen" Werte in den Variablen, was aber kein Problem ist, weil man ja temporäre Variablen nie liest bevor man selber kontrolliert was reingeschrieben hat.

Harald
 
Hallo und danke für eure schnellen Antworten,

ich suche gerade einen Fehler bei meinem Tischnachbarn.

Er hat eine FOR Schleife

FOR hv := 0 TO 50 BY 1 DO

....

END_FOR;

Da es Probleme mit dieser FOR Schleife gab, hat er mal innerhalb dieser FOR Schleife den MAX Wert von HV gesichert.
Und dieser ist eine Zeit lang 50, dann auf einmal auch 51.

Ich vermute das Problem darin, das hv eine temporaere Variable ist und zwischendrin die Weckalarme ( 32/35 ) aufgerufen
werden, dadurch hv verloren geht bzw. verfälscht wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Auf die Variable hv wird doch wohl nicht in der Schleife schreibend zugegriffen?
Zum Vergrößern anklicken....
Nein, überhaupt nicht.

Nach Durchlaufen der Schleife dürfte hv 51 enthalten.
Zum Vergrößern anklicken....
Richtig, nach dem END_FOR; sollte die hv auf 51 stehen.

Wie gesagt, ich vermute das Problem darin, das hv eine temporaere Variable ist und die FOR Schleife in der Bearbeitung
durch einen asynchronen OB unterbrochen wird und daher Probleme entstehen.
 
Wie wäre dieses Verhalten dann noch zu erklären?

Ich habe seine Variablen jetzt von VAR_TEMP nach VAR verschoben und alles funktioniert.
Dann muss doch der Interrupt durch einen OB die temporaere Variable beeinflussen.
Oder was könnte noch sein?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe bislang eigentlich immer Programme mit Zeit-OB's geschrieben und auf der anderen Seite auch Bausteine mit Schleifen-Variablen, die als TEMP deklariert waren, gehabt. Ich kann mich nicht an Probleme damit erinnern - das muss dann also noch irgendeinen anderen Hintergrund haben.
Was macht denn der eine und der andere Baustein so in etwa ?

Gruß
Larry
 
Andere Frage noch dazu :
Hast du in dem einen oder anderen Baustein sehr viele temporäre Variablen deklariert (ggf. Strings) ?
 
Was macht denn der eine und der andere Baustein so in etwa ?
Zum Vergrößern anklicken....

Dort werden nur Bereiche Initialisiert
Code: 
FOR hv := 0 TO 50 BY 1 DO
    "Daten".ZumPC[hv];
END_FOR;

Der DB "Daten" geht bis "Daten".ZumPC[50];

Ab und an wird allerdings der OB122 Programmierfehler aufgerufen, klickt man auf "Gehe zu" springt er auf diese Zeile,
weil hv auf 51 steht. Der DB geht nur bis 50.

So ein Problem hatte ich auch noch nie.


Hast du in dem einen oder anderen Baustein sehr viele temporäre Variablen deklariert ?
Zum Vergrößern anklicken....
Nur 8 INT´s, jede PRIO Klasse hat >100 Bytes Lokaldaten reserviert.

Wie gesagt, stelle ich von VAR_TEMP auf VAR um, tritt der Fehler nicht mehr auf.
 
Zuletzt bearbeitet:
Der Fehler tritt auch nicht sofort auf sondern erst nach einigen oder vielen Sekunden, obwohl diese Schleife bei jedem Zyklus durchlaufen wird. Daher auch meine Vermutung mit den asynchronen OB´s
( OB32 10ms ist drin und OB35 100ms )
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... und die Deklaration des Array's passt auch (also beinhalte die 51 Elemente) ?

Macht der baustein nur die Schleife und die dann alle 10 ms ? Wenn ja dann könnte es auch gut sein, dass du sporadisch ein Re-Entrance-Problem bekommst - also dass dein Baustein wiederholt aufgerufen wird noch bevor er zuende bearbeitet worden ist ...

Gruß
Larry
 
... und die Deklaration des Array's passt auch (also beinhalte die 51 Elemente) ?
Zum Vergrößern anklicken....

Ja, 0..50

Macht der baustein nur die Schleife und die dann alle 10 ms ?
Zum Vergrößern anklicken....
Diese FOR Schleife, welche das Problem verursacht liegt in einem FB, welcher gang normal im OB1 zyklisch aufgerufen wird.
Im OB35/OB32 werden nur Zähler hochgezählt ( hat mit dieser Funktion nichts zu tun )

Wenn ja dann könnte es auch gut sein, dass du sporadisch ein Re-Entrance-Problem bekommst
Zum Vergrößern anklicken....
Wie ist das zu verstehen
 
Re-Entrance ist, wie schon beschrieben, das ein erneuter Aufruf erfolgt während der Baustein noch läuft.
Das wäre für mich bei einer 315 und einem Zeit-OB mit 10 ms durchaus vorstellbar (die 315 ist ja nun nicht soooo das Rennpferd ...).

Ich muss aber sagen, dass ich nach deinem letzten Beitrag die/deine Baustein-Tätigkeiten-Konstellation nicht mehr so recht verstehe ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also im Prinzip ist ja meine Frage,

wie kann es sein, das eine temporäre Hilfsvariable innerhalb einer FOR-Schleife 0 TO 50 auf 51 stehen kann ( nur wenn die hv temporär deklariert wird ).
Zykluszeit liegt bei 3ms.

Ich muss mich am WE noch mal in die Thematik temporaere Variablen einarbeiten. Ich habe sie jetzt auf VAR umdeklariert, es funktioniert alles
aber ich möchte schon wissen, warum dies so ist.
 
Faceman schrieb:
Ich habe seine Variablen jetzt von VAR_TEMP nach VAR verschoben und alles funktioniert.
Zum Vergrößern anklicken....
Mit dem SchleifenZähler als VAR_TEMP war es doch ein sporadisch auftretender Fehler - so hatte ich es verstanden.
War das Testen mit hv als static-Variable denn über einen genügend langen Zeitraum gelaufen, um davon ausgehen zu können, dass der Fehler jetzt nicht mehr (oder vielleicht sehr viel seltener) auftritt?
Eigentlich solltest Du die Version, bei der der Fehler auftritt, Siemens zur Verfügung stellen . . .

PS:
Faceman schrieb:
Ich habe sie jetzt auf VAR umdeklariert, es funktioniert alles aber ich möchte schon wissen, warum dies so ist.
Zum Vergrößern anklicken....
Au ja, das interessiert uns auch!
 
Zuletzt bearbeitet:
Ist ein bißchen "Fischen im Trüben" was wir hier machen ... man kann das als Außenstehender auch nur raten ...

Wie Heinileini schopn geschrieben hat steht hv am Ende des Ablaufs des Bausteins in jedem Fall auf 51 - du siehst hier kein Ergebnis dazwischen.
Ist es denn sicher, dass die Indexierung das Problem ist ? Dann müßte es ja auch weg sein wenn du das Array auf 0..51 deklarierst - auch wenn hv ein TEMP ist. Irgendwie passt das für mich nicht so richtig ...

Gruß
Larry
 

Similar threads

N
Step 7 Diagnose und Informationen zur CPU im Anwenderprogramm (SFC51, 78 und 87)
Antworten
9
Aufrufe
5K
ducati
D
Sebastian
Kontinuierliche Daten mit der S7 aufzeichnen
Antworten
6
Aufrufe
6K
argv_user
A
Zurück
Oben