Step 7 FB aus einem FC heraus aufrufen wird mit falschen Werten übergeben

[Escride]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

ich habe in einer Förderstrecke für z.B. Stopper einen FB geschrieben, der immer mit anderen Werten am IN sowie einem DB für jeden Stopper aufgerufen wird.
Diese FB-Aufrufe liegen alle in einem FC in den Netzwerken hintereinander.

Nach einiger Zeit allerdings ergibt es plötzlich Probleme:

Im FB aus NW 2 bis Ende erscheinen teilweise Werte des FBs aus Netzwerk 1. In den dazugehörigen DBs sind die Werte, im FC selbst sind sie ebenfalls richtig, öffne ich allerdings den FB mit passendem DB zum beobachten stehen dort andere Aktualwerte vom IN-Parameter drin. Diese verhindern dann den weiteren Programmablauf.

Es sind nicht nur INT-Werte, sondern auch einfache boolsche Operanden.

Nehme ich nun einfach einen FB aus diesem FC heraus und stelle ihn in einen anderen FC ein, so funktioniert es ohne Probleme.

Woher könnten solche Probleme kommen?
Zeitstempel sind alle okay
Datenbausteine und FBs habe ich von der CPU gelöscht, DBs neu im Programm generiert (gelöscht und generieren lassen) und wieder übertragen, ohne Erfolg.
Kopiere ich den FB, bennenne ihn um und lade den neuen, dann funktioniert es auch, aber kann ja nicht des Rätsels Lösung sein. Dann hätte ich gleich einen FC schreiben können sowie DBs um die dann dort hineinzuschreiben, davon abgesehen würden 60 gleiche FBs den Speicher sprengen.

Es gibt keine Querverweise auf Speicherbereiche, auch keinen absoluten Aufruf innerhalb des FBs. Alles was hinein soll wird an IN, IN/OUT, OUT verarbeitet. Genutzt wird für Flankenmerker der STAT-Bereich. Den TEMP nutze ich nie.

Das Programm liegt auf einer CPU315-2DP 315-2AH14-0AB0 mit FW 3.3.11 - Aktualisierung der FW würde ich ungern machen, da ich bei einem Fehlschlag/Defekt keinen Ersatz bekommen kann (Afrika).
Programmiert wurde mit Step7 5.5 + SP4

Es betrifft im übrigen nicht nur diesen einen FB, sondern ALLE. Also alle Weichen, Stopper, Kettenschmierungen, Pufferstrecken, etc.

Ein Urlöschen der CPU habe ich bereits einmal durchgeführt, naja mehrmals inkl. Werkseinstellungen.

Der OB35 wird zyklisch mit 100ms aufgerufen und öffnet einen FC, welcher 4 PID-Regler beinhaltet. Sollte aber doch kein Problem darstellen.

Der Gesamtzyklus beträgt 5ms laut Diagnose. Fehler sind keine eingetragen.

Wie oben erwähnt, wird der FB problemlos ausgeführt wenn ich ihn verschiebe oder umkopiere, aber nur dann, wenn er nicht noch einmal verwendet wird, daher schliesse ich einen Programmierfehler aus.

Gibt es evtl. die Möglichkeit das die DBs nicht richtig dem FB zugeordnet werden? Wie kann ich das feststellen, wenn er mit einfacher CALL-Anweisung mitsamt DB geöffnet wird?

Es ist relativ schlecht, wenn der FB mit DB221 aufgerufen wird und der FB mit DB230 plötzlich den Wert des DB221 erhält, obwohl im DB230 ein anderer Wert steht.

Hoffe auf Abhilfe .

LG
Björn

EDIT:
Ich habe den aufrufenden FC und den aufgerufenen FB angehangen. Der FB in Netzwerk 2 hat im DB seinen richtigen Wert stehen, aber beim Beobachten und auf der CPU nutzt er den Wert aus dem DB aus Netzwerk 1. Leider ist es kein einfacher Beobachten-Fehler, sondern tatsächlich blockiert es so (Im Testbetrieb beobachtet mit gleichem Ergebnis)

 

[Paul]

Hallo
Ich vermute, dass das Programm schon korrekt abgearbeitet wird.

Du schreibst:
......Im FB aus NW 2 bis Ende erscheinen teilweise Werte des FBs aus Netzwerk 1.

Wenn du den FB öffnest und dann mit "Brille" beobachtest, siehst du die aktualwerte des ersten Aufrufes.
Kannst du die Aufrufreihenfolge (zum beobachen) mal ändern, so dass der "Problemstopper" als erster (letzter?) augerufen wird?

Man kann das einstellen, Zielsystem--Testbetrieb--Aufrufumgebung oder so ähnlich (habe momentan kein Step 7 parat).
Geht aber glaube ich auch nur wenn der "Stopper-FB" in verschiedenen FCs aufgerufen wird und nicht in einem FC nacheinander

 

[Escride]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich öffne standardmäßig FBs, indem ich im dazugehörigen FC den Baustein rechtsklicke und dann auf Baustein-öffnen Beobachten gehe. Ich habe den Testbetrieb bereits versucht, hatte aber den gleichen Effekt.

Wenn ich den "Problemstopper" als ersten aufrufe, dann haben alle folgenden FBs seine Werte, aber nur teilweise. So wird mal nur ein BOOL, mal ein INT falsch übergeben.

Irgendwie glaube ich langsam das der FB der abgearbeitet wurde noch was im Speicher stehen hat, der vom darauf folgenden FB nicht überschrieben wird oder sowas, sprich Daten von DB1 bleiben zum Teil hängen.

Tests kann ich erst morgen wieder machen, allerdings wollte ich die Anlage am Dienstag übergeben, was eh schon schwierig wird mittlerweile.

 

[Paul]

Irgendwie glaube ich langsam das der FB der abgearbeitet wurde noch was im Speicher stehen hat, der vom darauf folgenden FB nicht überschrieben wird oder sowas, sprich Daten von DB1 bleiben zum Teil hängen.

Kann ich mir nicht vorstellen.
Jeder FB-Aufruf hat ja seinen eigenen Instanz DB. Was für Werte stehen denn da drin?


Das in dem FB keine absoluten Adressen (Merker, Zeiten...) erlaubt sind ist klar?
Kommt in dem FB indirekte Adressierung vor?
Sind #TEMP Variablen im Spiel?

 

[Thomas_v2.1]

Ich öffne standardmäßig FBs, indem ich im dazugehörigen FC den Baustein rechtsklicke und dann auf Baustein-öffnen Beobachten gehe. Ich habe den Testbetrieb bereits versucht, hatte aber den gleichen Effekt.

Das funktioniert aber so nicht. Es gibt zwei Möglichkeiten (dich ich zumindest verwende):
1) FB öffnen, Testbetrieb einstellen, Instanz-DB manuell eingeben
2) Übergeordeten Baustein ONLINE öffnen, Rechtsklick auf Instanz -> Beobachten mit Aufrufpfad

Bei deiner Variante ist garantiert der falsche Instanz-DB beim Beobachten geöffnet. Lass dir beim Beobachten einer AWL-Zeile mal das DB2 Register anzeigen, das ist der geöffnete Instanz-DB.

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lass dir beim Beobachten einer AWL-Zeile mal das DB2 Register anzeigen, das ist der geöffnete Instanz-DB.

Guter Tip!

 

[TP-Inc]

Warum hängen an deinen 3 FBs immer immer die gleichen drei boolschen Operanden aus dem L-Stack ? z.B. ZählenPusherDogs = L0.0 ?

 

[Boxy]

Warum hängen an deinen 3 FBs immer immer die gleichen drei boolschen Operanden aus dem L-Stack ? z.B. ZählenPusherDogs = L0.0 ?

Weil das wohl der Editor selbst macht, da der Baustein bestimmt in KOP oder FUP eingegeben wurde.
Selbst wenn AWL, wäre es ja egal, da diese Pararmeter jeweils vor dem Aufruf ja durch die Zuweisung beschrieben wurden...

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum hängen an deinen 3 FBs immer immer die gleichen drei boolschen Operanden aus dem L-Stack ? z.B. ZählenPusherDogs = L0.0 ?

Das kommt daher weil das ursprünglich in FUP programmiert ist.
Wenn du dann auf AWL umschaltest macht Step7 die TEMP Variablen selbstständig daraus

L 0.0 ist das Ergebnis der UND-Verknüpfung die in FUP am IN-Beinchen CU hängt

[FONT=Courier][SIZE=1][FONT=Courier][SIZE=1]U #Schritt_1 #Schritt_1
U #Kette_laeuft #Kette_laeuft
UN #Schritt_2 #Schritt_2
U #ZaehlenPusherDogs #ZaehlenPusherDogs
= L 0.0
BLD 103
U(
O #RESET #RESET
O #HM_R #HM_R
)
= L 0.1
BLD 103

CALL #Zaehlwert_Schmieren #Zaehlwert_Schmieren
CU:=L0.0
R :=L0.1
PV:=#Kettenlaenge_Pulse #Kettenlaenge_Pulse
Q :=
CV:=
NOP 0
[/SIZE][/FONT][/SIZE][/FONT]

 

[Escride]

So hallo,

erstmals Danke das Ihr Euch dem Problem angenommen habt soweit.

Was ich heute getestet habe:
CPU in Testbetrieb, Beobachten mit Aufrufpad und die Werte in folgenden FBs werden vom ersten DB übernommen, also wieder teilweise falsch.
Das ganze habe ich sehr oft versucht, immer wieder mit dem gleichen Ergebnis. Bei vielen, aber nicht allen FBs.

Wenn ich die Aufrufreihenfolge der FBs z.B. umdrehe, dann haben die folgenden die Werte des ersten, obwohl das ja eigentlich nicht sein darf.

Im AWL zeigt er mir im FB immer wieder andere Werte an wie die die im DB stehen. Es sind dann immer wieder die gleichen. Zum Test habe ich die CPU komplett gelöscht und nur den FC, FB, OB1 und die drei DBs geladen. Gleiches Ergebnis.
Erstelle ich drei FCs und rufe diese separat auf, gehts. Irgendwie macht es keinen Sinn.

Ich habe das Programm nun soweit abgeändert das ich die FBs kopiert habe und mit neuem Namen aufrufe, als FB1, FB2, FB3, etc. Dadurch ist der Speicherplatz nun ziemlich am Ende. Ich hoffe, das ich mit dem Rest noch klar komme, schaut zumindest so aus da die Anlage alle 6 Teilbereiche startet und jetzt anständig abarbeitet. Werde dann eine größere Karte beim nächsten Besuch mitnehmen. Das Projekt habe ich so wie es ist mal an Siemens zur Überprüfung geschickt, am Telefon konnten die logischerweise auch nicht helfen.

Das mit dem FB-Beobachten wusste ich vorher nicht mit dem Testbetrieb, immerhin habe ich das nun gelernt, aber bisher musste ich auch nie wirklich oft in einen FB schauen, weil die bisher immer problemlos liefen.

Die Bausteine wurden ursprünglich in FUP geschrieben, ja. Liegt daran, das unsere Kunden ein leicht lesbares Programm haben wollen und FUP da natürlich für die meisten einfacher ist.

Sollte Siemens mir eine Lösung angeben oder überhaupt herausfinden was da los ist, werde ich mich hier erneut melden und die Antwort zurückgeben.

Bis dahin erstmal Vielen Dank!

edit:
An Siemens habe ich mich gewendet weil die Zeit zu knapp wird und das Problem ja nicht immer war, sondern erst seit kurzem. Vielleicht hat die CPU ja doch ne Macke oder sowas ^^.

 

[Thomas_v2.1]

Und welchen Instanz-DB sagt das DI/DB2-Register?

Edit: Hast du das Programm mal testweise in Plcsim geladen, und geprüft wie das Verhalten dort ist?

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Weil das wohl der Editor selbst macht, da der Baustein bestimmt in KOP oder FUP eingegeben wurde.
Selbst wenn AWL, wäre es ja egal, da diese Pararmeter jeweils vor dem Aufruf ja durch die Zuweisung beschrieben wurden...

Ups, sorry das hab ich komplett vergessen

Um auch etwas konstruktives zu schreiben:
Konsistenzprüfen, falls noch nicht gemacht.
I-DBs on und offline löschen und neu generieren lassen.

 

[Paul]

Hallo
Die CPU hat keine Macke.
Was du beschreibst ist völlig logisch.

Du beobachtest den FB87.
Der wird aber im Programm 10 mal aufgerufen.
Bei jedem Aufruf arbeitet er mit anderen Werten.
Im Beobachtungsmodus siehst du die Werte vom ersten Aufruf.
Ich bin sicher, wenn du direkt in den Instanz-DB vom 5ten Aufruf schaust, stehen da die richtigen Werte drin.

Das ist halt das Problem mit Mehrfachaufrufen.
Sollte man nur mit FBs machen die 100% auf Herz und Nieren getestet sind (mit Einzelaufruf),
sonst wird es mit der Diagnose schwierig.

Ach noch was...
Ich weiß ja nicht wie oft du die FBs jetzt duplizieren musstest, aber:
Die Bausteine aus deinem Beispiel sind ja wirklich nicht groß.
Wenn der Speicher so ausgereizt ist, dass du die nicht 20 mal duplizieren kannst, läuft bei der Hardwareplanung was schief.
Zumindest wenn ihr Sondermaschinen baut, bei Serienmaschinen schaut das anders aus,
aber da sollten die Bausteine dann so funktionieren, das man gar nicht mehr reinschauen muss...

 

[Escride]

Sodele,

habe heute einen Anruf vom Siemens-Support bekommen, welcher mir am Telefon Anweisungen gab und immer nur sagte das das nicht sein kann.
Also habe ich ihm Teamviewer angeboten weil ich die Bauleitung herumbekommen habe mir Internet zu gewähren was Siemens ablehnte. Eine halbe Stunde später haben sie dann doch drauf geschaut, einen ganzen Haufen an Punkten abgearbeitet und nun wird eine neue CPU per Vorabtausch hergeschickt, die glücklicherweise vom Kunden getauscht wird und uns die defekte dann zuschickt. Das fertige Programm hat er ja. Die genaue Diagnose habe ich nicht verstanden, er redete viel vom Speicher, ich hatte aber auch andere Dinge im Kopf weil ich noch einige andere Punkte klären musste. An der Karte lag es nicht, da ich zwei weitere, allerdings kleinere, nach und nach eingesetzt habe und diese die gleichen Symptome hatten. Das ganze hat auch nur 3,5h gedauert, Zeit, die ich eigentlich anders nutzen wollte. Wenigstens trägt die Kosten der Endkunde, der die Anlage vor 3 Jahren gekauft hat (ohne Prog) und sie erst dieses Jahr hat aufstellen lassen.

Habe in 19 Jahren zwar noch nicht erlebt das eine CPU solche Macken hat, aber man lernt ja nicht aus.


@Paul:
Ich habe eine 128KByte Karte verbaut. In Deutschland hatte das Programm noch 87kByte, also ausreichend Platz für Erweiterungen. Ich habe im übrigen absichtlich den kleinsten nicht laufenden FB hochgeladen, dachte ich mache es Euch einfach und nicht absichtlich schwer mit 140 Netzwerken. Der grösste, den ich auch duplizieren musste hat 8720Byte. Glaubst Du wirklich das das der größte gewesen sein soll? Ne Kettenschmierung? Da ist alleine die Routine um die Träger auf die Pufferstrecken aufzuteilen ja noch größer.
Eine Fehlplanung bei der Hardware gab es auch nicht. An jeder der 4 Stationen sind noch je 8 I/Os zur Reserve frei, die CPU kann mit den mittlerweile 15 PID Reglern arbeiten und die Förderstrecke von gerade einmal 722m, aufgeteilt auf 3 Ketten mit je 2 Motoren ist auch nicht gerade groß. Da habe ich schon mit größeren gearbeitet.
Serienmaschinen haben wir nicht, ausschließlich Sondermaschinenbau. Allerdings gibt es einige Bausteine wie z.B. die Routine eines Stoppers, die immer wieder kopiert werden, laufen ja auch.
Im übrigen...da die Bausteine fehlerfrei sind, hätten sie ja auch laufen müssen, also hätte ich nie in den FB schauen müssen, also wäre da kein Problem gewesen. Da aber die CPU nen Schaden hat, was Siemens selbst ja nun diagnostiziert hat, lief die gesamte Anlage eben nicht bzw. hat falsch reagiert. Ich bin nicht ganz auf den Kopf gefallen .

Ach ja, der vom Support meinte auch erst ich öffne die FBs falsch, aber er hat es später genauso gemacht.

Für mich ist das Problem dann nun abgehakt.

Bis dann, und danke für die Mühe.

edit: Finde den Button "Thema abgeschlossen" nicht ^^.