TIA "Stringfehler in FB XXX" bei Vergleich mit ''

[R.K.]

Zuviel Werbung?
-> Hier kostenlos registrieren

TIA Version: V18 Upd 4, CPU: CPU 1516F-3 PN/DP Firmware V2.9
Hallo zusammen,
ich hatte heute morgen einen Interessanten Fehler bei dem ich gerne wüsste, ob schon mal jemand etwas vergleichbares erlebt hatte:
In meinem aktuellen Projekt arbeite ich auch mit ein paar String Variablen. Nichts ungewöhnliches oder etwas dass ich nicht schon hunderte male gemacht habe. Die Anlage läuft auch schon seit ein paar Wochen und ich bin nur noch zur Prozessbegleitung etc. vor Ort bis alle Bediener die Anlage kennen. In einem der FBs werden Stings verglichen mit Stings in anderen DBs oder ob sie komplett Leer sind in dem mit = '' verglichen wird.
Die Anlage lief über die Nacht und als ich gegangen bin war alles OK. Als ich gekommen bin Stand die Anlage und im Fehlerspeicher der CPU war "Stingfehler in FB XXX"
Nach etwas suchen und ausprobieren habe ich gefunden, dass immer wenn ich einen Vergleich mit '' in dem einem FB der auch im Fehlerspeicher aufgezeigt war mache dieser Fehler kommt. Den Gleichen Code in einen anderen FB kopiert hat ohne Probleme Funktioniert. Alle anderen FBs in denen der selbe Vergleich stattgefunden hat haben auch noch weiterhin ohne Fehler funktioniert.
Anlagen Neustart hat nichts verändert, SPS Komplett übersetzten und Übertragen hat auch nichts verändert. Ich habe das Problem gelöst in dem ich eine Konstante als String angelegt habe mit '' und überall diese Konstante verwendet.
Ein Support Request wurde erstellt und wenn ich eine Antwort bekomme schreibe ich sie natürlich hier rein. Aber das ist ein sehr komisches Problem und ich frage mich manchmal ob ich der einzige bin der in solche Probleme läuft
Mit Freundlichen Grüßen Ralf

 

[DCDCDC]

Wenn's eine temp Variable war und die nicht sauber initialisiert wurde, kann die Möglichkeit bestehen dass in der Variable etwas stehen kann.

Deswegen ist es gut dass du eine Konstante verwendest, das ist nämlich die ordentliche Variante so etwas zu lösen.

Statische Werte zum vergleichen/schreiben gehören einfach in Konstanten gepackt.. Punkt.

 

[R.K.]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es waren keine temp Variablen, es war ein normaler DB mit Werten die Irgendwann mal von nem Scanner gescannt wurden und während der Arbeit zwischen gespeichert und auf nen RFID geschrieben wurden.

Wenn ich auf einen Inhalt verglichen hätte, hätte ich es vermutlich als Konstante angelegt, aber an der Stelle wollte ich nur wissen ob der String voll oder leer war.

 

[DCDCDC]

oder ob sie komplett Leer sind in dem mit = '' verglichen wird.

Das ist halt auch keine Konstante sondern einfach "irgendwas" (ich schätze mal es wird im temp Abbild hinterlegt).. ein leerer Inhalt ist auch ein Inhalt, ein Bool ist nicht "leer" nur weil es auf false steht, genauso hat ein String auch einen Defaultwert ohne Zeichen.. deswegen nennt sich das ja auch Defaultwert.. und so etwas gehört einfach per Konstante sauber abgefragt, entweder in der Funktion oder global

 

[R.K.]

Ich glaube ich verstehe die Logik dahinter, aber Wenn ich eine Bool Variable mit TRUE oder FALSE beschreibe funktioniert es ja auch. Ja, TRUE und FALSE sind Keywörter und deshalb ist es was anderes. Aber mit Zahlen funktioniert es ja auch. Und wenn ich einem String 'abc' zuweise ist es ja auch garantiert dass 'abc' drin steht. Wenn ich in einem Programm eine eindeutige Zeichenabfolge abfrage hätte ich erwarte dass auch genau das drin steht.
Aber keine Frage, wenn ich einen temp string angelegt hätte und einfach erwartet hätte das er ohne Initialisieren mit '' befüllt ist, kann es nicht funktionieren. Aber wenn ich einen temp string vorbelegen möchte, dann habe ich bisher immer oben im Baustein tempString := ''; geschrieben.
Heißt das, dass ich in den letzten 10 Jahren in denen ich SCL Programmiere einfach immer nur Glück hatte dass ich nie so ein Problem hatte?

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Heißt das, dass ich in den letzten 10 Jahren in denen ich SCL Programmiere einfach immer nur Glück hatte dass ich nie so ein Problem hatte?

Eventuell.. vielleicht..

ich arbeite seit jeher schon mit Konstanten und habs deshalb nie so richtig drauf angelegt

 

[PN/DP]

TIA Version: V18 Upd 4, CPU: CPU 1516F-3 PN/DP Firmware V2.9

Liegt es vielleicht an der Firmware-Version?

Als ich gekommen bin Stand die Anlage und im Fehlerspeicher der CPU war "Stingfehler in FB XXX"

Du meinst, die CPU war in STOP?
Wie lautet der Fehlertext genau? Hatte der auch eine Fehler ID?
Hast du den CPU-Diagnosepuffer gespeichert und kannst uns einen relevanten Auszug zeigen?

Nach etwas suchen und ausprobieren habe ich gefunden, dass immer wenn ich einen Vergleich mit '' in dem einem FB der auch im Fehlerspeicher aufgezeigt war mache dieser Fehler kommt.

Ist der FB in SCL programmiert? Oder welche Programmiersprache?
Wie genau ist der Vergleich programmiert? Wo liegt der zu vergleichende String und wie wurde der erzeugt?

 

[Larry Laffer]

Vielleicht noch einmal zur Erinnerung : das Problem bei den Strings ist der Header - darin steht wie lang der definierte String ist und wieviel davon aktuell benutzt wird. Wenn das in deinem DB (oder sonst wo) verloren geht dann nützt dir auch nicht, dass die Zeichen hinter dem Header im Grunde korrekt sind ...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist der FB "optimiert" oder mit Standard-Zugriff?

Nach meinem Verständnis sollte ein Vergleich #mystring = '' lediglich die String-IstLänge (2. Byte im String-Header) auf = 0 vergleichen. Da ist normal keine Chance für irgendwelche "Stringfehler ...". Oder wurde der String irgendwie als Referenz/Pointer übergeben und die Referenz zeigte auf nicht vorhandenen oder zu "kurzen" Speicher (nur 1 Byte groß)?

 

[R.K.]

Liegt es vielleicht an der Firmware-Version?

Firmware ist auf dem neuesten Möglichen Stand für die Hardware Version

Du meinst, die CPU war in STOP?
Wie lautet der Fehlertext genau? Hatte der auch eine Fehler ID?
Hast du den CPU-Diagnosepuffer gespeichert und kannst uns einen relevanten Auszug zeigen?

War Falsch ausgedrückt. Die CPU lief noch, da der entsprechende Fehler OB mit läuft. Die Anlage an sich hat nicht mehr produziert.
Der Genaue Text im Ereignis war "Stringfehler im FB140". Ich habe Screenshots vom Fehlerspeicher gemacht die ich mittlerweile aus nicht mehr nachvollziehbaren Gründen gelöscht habe.... Und der Fehlerspeicher ist weil ich weiter dran rum gespielt habe um es zu reproduzieren mit Bereichslängenfehlern überlaufen, also ist der Original Fehler nicht mehr im Speicher. Wenn ich jetzt mein altes Programm zurück lade kann ich den Fehler nicht mehr reproduzieren.
Das war ein bisschen sehr dumm von mir das nicht mehr gespeichert zu haben.

Ist der FB in SCL programmiert? Oder welche Programmiersprache?
Wie genau ist der Vergleich programmiert? Wo liegt der zu vergleichende String und wie wurde der erzeugt?

Ja, es ist in SCL Programmiert.
Der zu Vergleichende String liegt in einem Optimierten DB.
Die genaue Programmstelle war
#TMP_bEinlManEnde :=
("DB_Auftragsdaten".scPostenEinlager.sAGPosten <> '') AND
("DB_Auftragsdaten".scPostenEinlager.sAGSerie <> '') AND
("DB_Auftragsdaten".scPostenEinlager.uiAGAnzBehaelter = 0) AND
NOT "dbG20PruefRFID".bPruefAktiv AND
"dbG05".scRobi.bGreiferFrei
;
Einträge Strings, also Posten und Serie haben den Fehler ausgelöst. Die Stings die hier gelesen werden, werden entweder mit String beschrieben die von einem HMI eingegeben werden (Inhalte werden mit einem Handscanner befüllt, aber das sollte keinen Unterschied machen) oder Wenn der eine Auftrag abgeschlossen wurde an einer anderen Stelle in dem FB mit
"DB_Auftragsdaten".scPostenEinlager.sAGPosten := '';
wieder abgelöscht. Beide Variablen im DB sind nur als Sting deklariert ohne spezielle Größenangabe aber der Posten ist immer nur 3 Stellig, die Serie ist immer 10 Stellig.

Vielleicht noch einmal zur Erinnerung : das Problem bei den Strings ist der Header - darin steht wie lang der definierte String ist und wieviel davon aktuell benutzt wird. Wenn das in deinem DB (oder sonst wo) verloren geht dann nützt dir auch nicht, dass die Zeichen hinter dem Header im Grunde korrekt sind ...

Ich hatte während der Fehlersuche die Variablen mit Variablen Steuern mehrfach die Werte hin und her geschrieben. Das sollte auch den Header auf den gesteuerten Wert setzten. Mein Verständnis bisher war, dass wenn ich im Programm z.B.
"DB_Auftragsdaten".scPostenEinlager.sAGPosten ='abc'
verwende, dann wird 'abc' vom Compiler wie eine String Konstante mit passendem Header behandelt

 

[R.K.]

Ist der FB "optimiert" oder mit Standard-Zugriff?

Nach meinem Verständnis sollte ein Vergleich #mystring = '' lediglich die String-IstLänge (2. Byte im String-Header) auf = 0 vergleichen. Da ist normal keine Chance für irgendwelche "Stringfehler ...". Oder wurde der String irgendwie als Referenz/Pointer übergeben und die Referenz zeigte auf nicht vorhandenen oder zu "kurzen" Speicher (nur 1 Byte groß)?

FB und DB sind beides optimiert

Es war keine Referenz oder Pointer. In allen Verwendeten Stellen wurden die Variablen direkt angesprochen, auch keine Übergabe über IN / OUT / INOUT.

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Firmware ist auf dem neuesten Möglichen Stand für die Hardware Version

sicher..?

 

[R.K.]

Anhang anzeigen 85389

sicher..?

Ja, meine Artikelnummer ist
6ES7 516-3FN02-0AB0

 

[R.K.]

Entschuldigt das viele gespamme, aber ich habe es gerade wieder hin bekommen. Das ist der Code der es ausgelöst hat
#bTest := "dbIBN".sting = '';
bTest ist eine Lokale Temp Variable in dem FB in dem ich bisher ach immer das Problem habe. dbIBN ist ein optimierter DB. string ist ein String ohne längenangabe.
Gleicher Code in einen anderen Baustein kopiert führt zu keinen Fehlern

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Entschuldigt das viele gespamme, aber ich habe es gerade wieder hin bekommen. Das ist der Code der es ausgelöst hat
#bTest := "dbIBN".sting = '';
bTest ist eine Lokale Temp Variable in dem FB in dem ich bisher ach immer das Problem habe. dbIBN ist ein optimierter DB. string ist ein String ohne längenangabe.
Gleicher Code in einen anderen Baustein kopiert führt zu keinen Fehlern

Steht im String jetzt die Eingabe aus dem Hmi? Evtl hast du nach dem letzten Zeichen ein Leerzeichen oder sonst etwas.. was dir die Länge verhaut..

 

[R.K.]

Nein, mein Test String wird nirgendwo im Programm beschrieben. Ich hab ihn beim beobachten mit rechtsklick gesteuert.

Jetzt kommen schon wieder keine Fehler Einträge, obwohl ich nichts geändert habe, was sehr stark dafür spricht dass es etwas mit Temporäten Variablen zu tun haben muss, auch wenn ich nicht verstehe wo und wie

 

[DCDCDC]

Intialisierst du alle temp variablen vor der Verwendung? Mal alle mit Konstanten initial beschreiben

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deine Anweisung ist, so wie du es gepostet hast, korrekt und sollte auch funktionieren sofern sie denn auch wirklich immer bearbeitet wird - das wäre dann bei dem TEMP der Unterschied zu einer Instanz-Variablen.
Um da jetzt aber mehr sagen zu können müßte man schon den kompletten Baustein sehen ...

 

[DCDCDC]

Vllt ist das auch mal einen service request bei Siemens wert..

 

[Larry Laffer]

Vllt ist das auch mal einen service request bei Siemens wert..

Ich denke eher nicht - wenn es in dem einen Baustein funktioniert und in dem anderen nicht dann wird es wohl an irgendetwas in dem Baustein liegen - deshalb würde ich da ja auch gerne "etwas mehr" sehen ...