TIA TIA v14SP1/S7-1500 Fehlerhafte Beeinflussung von Temp-Variablen

RONIN

Level-3
Beiträge
2.518
Reaktionspunkte
765
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute

Bin vor kurzen anscheinend über einen Bug in den 1500er CPUs in Verbindung mit Temp-Variablen gestolpert.
Getestet hab ich hier mit TIA v14 SP1 Update 5 und ner 1510 ET200SP v2.5.
Scheint aber ein generelles Problem zu sein da vom 3rd-Level-Support nur die Meldung "Wird mit Version v15.1 behoben, voraussichtlich Q4 2018" zurück kam.
TIAv14SP1_1500_TempProblem.jpg

Ich hab noch keine generelle Ahnung wodurch das Problem entsteht bzw. wie man es am besten umschifft. Hier mal der Hintergrund:
Basis ist ein FB mit 4 Variant am IN welcher UDTs vom einem bestimmten Type (immer der selbe) angeschaltet bekommt.
Im ersten Netzwerk prüfe ich die Variant ob außen der korrekte Datentyp angelegt wurde und setze mit Bits in Temp.
Danach kopiere ich mir die 4 UDT in ein Array[0..4] of UDT wobei mir Array[0] als Leerdaten dient.
In Netzwerk 2 weise ich dann zuerst das Temp-Bit von Oben nochmal zu, man sieht es ist noch TRUE.
Dann kopiere ich 2 dieser UDT im Temp hin und her.
Danach ist das Bit dann FALSE.

Alle Bausteine sind optimiert und voll-symbolisch. Irgendwelche Adressüberschneidungen kann man ausschließen. Wodurch es genau beeinflusst wird hab ich noch nicht heraus?
Oder hab ich das was übersehen?

Hier noch ein Downloadlink zu nem Testprojekt falls es jemand mit v15 und ner anderen CPU testen will.
https://www.dropbox.com/s/l29lpbp1jod2afo/TempBug_V14.zap14?dl=0
 
Zuletzt bearbeitet:
ist der A2.0 "ausserhalb" des FB auch false? Wird der FB mehrfach aufgerufen?

Also, vielleicht stimmt nur das "beobachten" der Temp-Variable nicht?

Die #ipFW1_OK mal an verschiedenen Stellen im FB auf verschiedene Ausgänge schalten, und schaun, wie die stehn...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Beispiel ist schon soweit reduziert wie es geht. OB1 - Aufuf FB -> Aufruf gezeigter FB als Multiinstanz (1x)
Den A2.0 hatte ich da eben nur eingefügt um einen Beobachtungsfehler auszuschließen.
Wenn ich Netzwerk 2 (Bild in Beitrag #1) so umschreibe....
Code:
//Netzwerk 2
"A2.1":=  #ipFW1_OK;    //Ausgang A2.1 auf der Karte leuchtet

#iFW_tmp:= #iFW[#KanalAkt];

"A2.0":= #ipFW1_OK;    //Ausgang A2.0 auf der Karte leuchtet  nicht
Von daher scheint das Beobachten zu stimmen.

Hier noch ein paar Variationen wie sich der Code verhält wenn man verschiedene Änderungen macht.
So richtig kann ich nicht festnageln welcher Befehl der Verursacher ist.
TIAv14SP1_1500_TempProblem2.jpg

Derweilen hab ich die Sache für mich mal so umschifft dass ich die ipFW_OK-Bits in den STAT verfrachtet habe.
Versuche noch vom Support rauszubekommen von welcher Ecke das Problem kommt, die "Entwicklung" sollte es ja wissen....
 
Hallo Ronin,

ich habe dein Beispielprojekt mal eben in V15 simuliert, zunächst das gleiche Verhalten wie bei dir in V14. Was mich aber ein wenig beruhigt ist die Tatsache, dass es fehlerfrei läuft wenn man nichtoptimiert programmiert.


Gruß, Onkel
 
Hallo Ronin,

ich habe dein Beispielprojekt mal eben in V15 simuliert, zunächst das gleiche Verhalten wie bei dir in V14. Was mich aber ein wenig beruhigt ist die Tatsache, dass es fehlerfrei läuft wenn man nichtoptimiert programmiert.


Gruß, Onkel

Onkel, warum beruhigt sich das? Heißt ja, "optimiert" wird dann fehlerhaft umkopiert, das kann üble Folgen haben.
 
@Onkel: Danke für die Info.

Scheint wohl ein Compilerproblem zu sein da die Sache mit einer neuen TIA-Version behoben werden können soll.
Vom Support bzw. der "Entwicklung" kam noch nicht viel detailliertes retour außer dass man keinen Workaround für das Problem benennen kann. Was auch immer das heißt.
Wege den Code funktionsfähig zu machen gibt es ja genug, da wird wohl der Befehl gemeint sein welcher das Problem auslöst.
Leider hat man mir noch nicht genannt welcher Befehl oder welche Kombination die Probleme verursachen...

Da das Problem in v14 und v15SP0 ohnehin bestehen bleiben wird (warum kann man sowas nicht mit nem Update beheben?) heißt es aufpassen bei solchen Variant oder "Array mit var. Index"-Konstrukten im Temp, da TIA nicht immer den Code zu generieren scheint den man schreibt.

Mal sehen ob es da noch mehr Infos kommen.
 
Kein Witz:
Manch seltsames Verhalten mit "kippenden" Variablen habe ich durch Einfügen einer Leerzeile oder einer Zuweisung A:=A "beheben" können. (V13 und V14)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Manch seltsames Verhalten mit "kippenden" Variablen habe ich durch Einfügen einer Leerzeile oder einer Zuweisung A:=A "beheben" können. (V13 und V14)

Bringt in dem Falle nichts:

Bug.jpg

TIA V14 SP1 Upd 6 mit CPU 1511-1AK00 FW1.7 ( +FW1.8.5)
 
Zuletzt bearbeitet:
Ronin,

folgendes ist noch interessant.

Du hast ja den Befehl:
#iFW_tmp:= #iFW[#KanalAkt];

#KanalAkt wird mit 0 dauerhaft vorbelegt. Die tempVar ist nach dem Array schreiben auf FALSE.

Ändere ich deinen Befehl auf:
#iFW_tmp:= #iFW[0]; ( wäre ja vom Programmablauf her prinzipiell das gleiche, da deine #KanalAkt immer auf 0 steht )
ist die Variable auf einmal TRUE.

Das ist natürlich ein sehr problematisches Verhalten

Hier ein Screenshot:
Bug.jpg


getestet mit TIA V14 SP1 Upd 6 mit CPU 1511-1AK00 FW1.7 ( +FW1.8.5 )
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Firmware 1.7 ist natürlich auch uralt, vielleicht bringt ein Update auf V1.8 was. (mehr geht bei dieser CPU nicht)
Die Behebungsliste für die neueren Firmwareversionen ist ellenlang.
Eine Sauerei ist, daß die Bugfixe aus >=V2.0 nicht mehr für die "alten" CPUs nachgepflegt werden. Wie soll man einem Kunden z.B. vermitteln, daß er für eine funktionierende TCP-Kommunikation eine neue CPU kaufen muß? (V1.8.1 reproduzierbare Zykluszeitüberschreitungen, V2.1 läuft, Behebung erfolgte angeblich mit V1.8.0)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe jetzt noch einmal ein wenig rumgespielt und nun wird es ganz mysteriös:

Wenn man die Zeile #KanalAkt := 0; verschiebt, verändert sich das Verhalten:
Bug.png

Interessant ist nun, füge ich den Befehl im Netzwerk 1 ganz unten in der letzten Zeile ein, funktioniert es nicht:
NW1_Zeile17.jpg

Füge ich es aber in Netzwerk 2 in die erste Zeile ein, geht es auf einmal?!?!
NW2_Zeile1.png


PS: 17 ist definitiv die letzte Zeile im Netzwerk 1, danach kommt nichts mehr ( außer halt Netzwerk 2 )
 
Zuletzt bearbeitet:
Mein letzter Versuch erbrachte:

In V14 wie in V15 funktioniert es wenn man nicht "optimiert" verwendet in allen bisher getesteten Varianten wie gewünscht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da bin ich jetzt echt beruhigt, ich dachte bisher, ich bin der einzige, bei dem sowas vorkommt ...

und ich bin beruhigt, dass ich keine "optimierten Bausteine" und auch kein SCL mit dem TIA-Dings verwende ;) Und ansonsten für 24/7 Anlagen gleich garkein TIA ;)

Also wenn man sich auf TEMP-Variablen nicht verlassen kann, dann ist es eigentlich nicht möglich damit wichtige Anlagen zu bauen. Von Gefahren für Anlage und Personen mal zu schweigen...

Wir hatten ja damals diesen PEW-Bug, doch der ist wenigstens reproduzierbar. Bei dem TEMP-Problem sag ich nur gute Nacht...

Gruß.
 
Ändere ich deinen Befehl auf:
#iFW_tmp:= #iFW[0]; ( wäre ja vom Programmablauf her prinzipiell das gleiche, da deine #KanalAkt immer auf 0 steht )
ist die Variable auf einmal TRUE.
Danke für die fleißigen Tests. Das ich den variablen Array-Index starr auf 0 gesetzt hatte diente Demonstrationszwecken. Ich hatte den Index für die Anwendung schon variabel gebraucht. Ich hatte den auch fest weil ich, so wie du auch schon, gemerkt hatte dass es nicht geht wenn ich den Index am Ende von NW1 setze, dafür aber schon wenn ich den Befehl am Anfang von NW2 habe.

Firmware 1.7 ist natürlich auch uralt
Scheint nicht die Ursache zu sein. Ich hatte das ursprünglich auf ner ET200SP-CPU mit FW1.8 getestet und dann auf 2.5 upgegradet, ohne Erfolg. Da der Support bzw. "die Entwicklung" sagt dass die Sache nur mit ner neunen TIA-Version zu beheben ist, kann man die Firmware-These wohl ausschließen. Das Problem wird wohl im Compiler liegen.

Finale Aussage vom Support hab ich nicht welcher Befehl das zentrale Problem ist, ob es nun von der Variant-Seite oder einer Kombination kommt.
Moral von der Geschicht ist dass man sich nicht blind darauf verlassen darf dass die Steuerung das tut was man programmiert.

@Ducati: Verstehe die Philosophie. Wenigstens ist das hier ein konstantes Problem das man Beobachten kann und nichts sporadisches... oh Grauß...
Der PEW-Bug war aber schlimmer, das hat an grobe Fahrlässigkeit gegrenzt.
 
Zuletzt bearbeitet:
Die Korrektur des Verhaltens soll jetzt doch noch in Upd7 für v14SP1 einfließen. Das ist schon mal gut.
 
Zurück
Oben