tobi221081
Level-1
- Beiträge
- 27
- Reaktionspunkte
- 0
-> Hier kostenlos registrieren
Hallo Leute...
Ich kämpfe gerade mit einem Problem und taste mich nun langsam zur Ursache vor. Ich hoffe einer von euch kann mir helfen oder mich eventuell auf eine neue Spur bringen.
Ich habe einen FB geschrieben, welcher sehr viele Lokaldaten (>500Byte) besitzt. Nun rufe ich meinen FB im OB1 auf. Ebenfalls wird die selbe Instanz im OB35 aufgerufen obwohl er dort keinerlei Funktion ausführt.
OB1 OB35
CALL FB11,DB99 CALL FB11,DB99
meine parameter identischer parametersatz
(Der Hinweis den FB nicht im OB35 aufzurufen, wenn er dort keinerlei Funktion ausführt bringt nicht die Lösung => Der Grund warum mein Baustein im OB1 und OB35 liegt ist, dass wenn ich ihn in einem CFC einbaue er standardmaßig auf OB35 gelegt wird. Der zusätzlich Einbau in OB1 wird über das Attribut S7_tasklist erreicht. Der Aufruf in OB35 ist quasi "ohne nutzen". Ich möchte dem Kunden nur ersparen den Baustein dort löschen zu müssen. Das Problem ist aber nicht PCS7-spezifisch. Ich erreiche das gleiche Verhalten bei reiner AWL-Programmierung.)
Wird der Baustein aus dem OB35 aufgerufen, erkennt er dieses und macht ein BE. (Diese Implementierung ist überprüft. Der Baustein steigt im OB35 wirklich aus.)
Arbeitet mein Baustein nun in einem OB1-Zyklus und wird durch den OB35 unterbrochen treten beim fortführen des OB1 Zykluses Fehler auf und das immer an Stellen wo mit Lokaldaten gearbeitet wird.
L XY
L AB
*I
SLD 3
LAR1
TAR1 TEMP0_DWORD
/*mach irgendwas anderes*/
LAR1 TEMP0_DWORD
L 5
T W[AR1,P#0.0]
Ich vermute das der Baustein im OB1-Zyklus an der Stelle "mach irgendwas anderes" unterbrochen wird. Danach will er die berechnete Adresse (TEMP0_DWORD) rekonstruieren und diese stimmt nicht mehr und ich hab den Salat. Kann das sein, dass ab einer gewissen Größe es Probleme bei der Rekonstruktion der Lokaldaten nach einem Weckalarm gibt?
Oder kann es sein das mein Programm nach LAR1 TEMP0_DWORD unterbrochen wird und das Adressregister (welches im OB35 auch geändert wird) nicht mit gesichert und zurückgeschrieben wird? Gravierende Fehler bei der algorithmischen Implementierung schließe ich (vorerst) aus, da keinerlei Probleme auftreten, wenn der Baustein nur im OB1 aufgerufen wird..
Gibt es eine Möglichkeit zu sehen an welcher Bausteinadresse für den OB35 unterbrochen wurde?
Das beschriebene Verhalten tritt bei vielen Steuerungssystemen sowohl aus der 300er- als auch der 400er-Serie auf.
Vielen Dank!
Ich kämpfe gerade mit einem Problem und taste mich nun langsam zur Ursache vor. Ich hoffe einer von euch kann mir helfen oder mich eventuell auf eine neue Spur bringen.
Ich habe einen FB geschrieben, welcher sehr viele Lokaldaten (>500Byte) besitzt. Nun rufe ich meinen FB im OB1 auf. Ebenfalls wird die selbe Instanz im OB35 aufgerufen obwohl er dort keinerlei Funktion ausführt.
OB1 OB35
CALL FB11,DB99 CALL FB11,DB99
meine parameter identischer parametersatz
(Der Hinweis den FB nicht im OB35 aufzurufen, wenn er dort keinerlei Funktion ausführt bringt nicht die Lösung => Der Grund warum mein Baustein im OB1 und OB35 liegt ist, dass wenn ich ihn in einem CFC einbaue er standardmaßig auf OB35 gelegt wird. Der zusätzlich Einbau in OB1 wird über das Attribut S7_tasklist erreicht. Der Aufruf in OB35 ist quasi "ohne nutzen". Ich möchte dem Kunden nur ersparen den Baustein dort löschen zu müssen. Das Problem ist aber nicht PCS7-spezifisch. Ich erreiche das gleiche Verhalten bei reiner AWL-Programmierung.)
Wird der Baustein aus dem OB35 aufgerufen, erkennt er dieses und macht ein BE. (Diese Implementierung ist überprüft. Der Baustein steigt im OB35 wirklich aus.)
Arbeitet mein Baustein nun in einem OB1-Zyklus und wird durch den OB35 unterbrochen treten beim fortführen des OB1 Zykluses Fehler auf und das immer an Stellen wo mit Lokaldaten gearbeitet wird.
L XY
L AB
*I
SLD 3
LAR1
TAR1 TEMP0_DWORD
/*mach irgendwas anderes*/
LAR1 TEMP0_DWORD
L 5
T W[AR1,P#0.0]
Ich vermute das der Baustein im OB1-Zyklus an der Stelle "mach irgendwas anderes" unterbrochen wird. Danach will er die berechnete Adresse (TEMP0_DWORD) rekonstruieren und diese stimmt nicht mehr und ich hab den Salat. Kann das sein, dass ab einer gewissen Größe es Probleme bei der Rekonstruktion der Lokaldaten nach einem Weckalarm gibt?
Oder kann es sein das mein Programm nach LAR1 TEMP0_DWORD unterbrochen wird und das Adressregister (welches im OB35 auch geändert wird) nicht mit gesichert und zurückgeschrieben wird? Gravierende Fehler bei der algorithmischen Implementierung schließe ich (vorerst) aus, da keinerlei Probleme auftreten, wenn der Baustein nur im OB1 aufgerufen wird..
Gibt es eine Möglichkeit zu sehen an welcher Bausteinadresse für den OB35 unterbrochen wurde?
Das beschriebene Verhalten tritt bei vielen Steuerungssystemen sowohl aus der 300er- als auch der 400er-Serie auf.
Vielen Dank!