Stringverabeitung nicht THREAD-SAFE

2020-02-28T05:00:15.434000Z

Originally created by: 61131

Hallo,

falls es noch jemanden interessiert, hier die Aussge der Fa. Wago zum Thema:

a) Die Stringfunkionen in CoDeSys V2.3 sind ab Werk nicht „Threadsafe“ -> Deswegen erhält man auch in der CoDeSys-Hilfe den Warnhinweis. Die Wago-Dokumentation hält sich an den Vorgaben von 3S -> also nicht Threatsafe.
Dies liegt daran, dass wir bei dem IPC das originale Laufzeitsystem von 3S benutzen.

b) Bei den 32Bit Nucleus-Kontrollern wurde die Stringverarbeitung abgeändert und ist bis in die 10. Ebene Threadsafe.
Nutzen Sie bitte folgende Anweisung sString3:= CONCAT(STR1:=sString1, STR2:=sString2); sIch_bin_Retain:=sString3;

P.S. Woran liegt es, dass ich keine Email-Benachrichtigung bei Antworten auf Forumsbeiträge erhalte, wenn ich Dieses doch per Häckchen aktiviert habe?

Stringverabeitung nicht THREAD-SAFE

2020-02-28T05:00:09.711000Z

Servus

Nun, ich kann dich beruhigen. Du bist nicht der erste. (Falls dich das wirklich beruhigt...)
Ist mir genauso passiert. Das war aber bei der RTE.
Ich hab mich dann beschwert, dass das ja wohl nicht wahr sein kann und auch nicht so schwer.
Dann gabs erst ne Beta zum testen und beim nächsten Release wars fest drin.

Wenn WAGO jetzt auch so reagieren würde, wär dein Problem gelöst.

Ich hab mir damals kurzfristig mit einem eigenen CONCAT beholfen. Den kannst du haben wenn du willst.

Zitat:
Kann ich mir schwer vorstellen. Woher soll man wissen, welcher FB aus welcher Lib die Concat aus der StandarLib verwenden?

Nun, man könnte den fragen der die lib geschrieben hat.

Ansonsten kannst du nur die verdächtigen FB's vorher auf dieses Verhalten testen oder eben aus dem selben Task aufrufen.
Wann du welchen FB aufrufst musst du ja selbst wissen.
Das ist aber zugegebenermassen ein ziemlicher Sch...

Gruß
Erik

Stringverabeitung nicht THREAD-SAFE

2020-02-28T05:00:07.642000Z

Originally created by: 61131

Hallo,

Erik Böhm hat geschrieben:
Servus
Hast du denn wirklich schon Probleme damit gehabt oder fragst du nur weil es in der Doku so steht ?

Gute Frage! Ja, es gab einmal ein Problem. Mein Mailhandler (eigener Hintergrundtask) verschickt regelmäßig bzw. nach bestimmten Ereignissen Mails an div .Adressen. Hat mehrer Monate gut funktioniert. Als ich die Funktion ""Concat" für eine Funktionserweiterung verwendet habe, waren plötzlich meine in einem Array gespeicherten Strings (From:, To:, Passwort, etc.) zerschossen. Stand nur noch Müll drinn.
Ich hab mich auch schon gefragt, ob ich der Einzige bin, der Probleme damit hat (schön, wenn es so wäre). Da aber auf jeder Seite der Doku das "...Achtung ... nicht Thread-safe steht, kann ich mir das nicht vorstellen.

Erik Böhm hat geschrieben:
Wenns wirklich nicht geht, gibts nur 2 Auswege:
1. Alles was Strings verarbeitet im selben Thread aufrufen

Kann ich mir schwer vorstellen. Woher soll man wissen, welcher FB aus welcher Lib die Concat aus der StandarLib verwenden?
Grüße,
Martin

Stringverabeitung nicht THREAD-SAFE

2020-02-28T05:00:01.938000Z

Es gibt auch noch einen 3. und evtl sogar 4. Ausweg:

Eine Steuerung benutzen die das kann...

Wobei die Aussage von Wago natürlich auch nur die halbe Wahrheit ist.
Es liegt natürlich nicht an CoDeSys (dem Entwicklungssystem), sondern am Laufzeitsystem (das aber auch von 3S kommt).
4. Da es bei anderen LZS auch geht, könnte dieses Feature ja auch in eine zukünftige neue Firmware einfliessen.

Gruß
Erik

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:59.891000Z

Servus

Hast du denn wirklich schon Probleme damit gehabt oder fragst du nur weil es in der Doku so steht ?
Denn es gibt ja diverse Laufzeitsysteme, die das entgegen der Doku auch threadübergreifend richtig machen.

Wenns wirklich nicht geht, gibts nur 2 Auswege:

Alles was Strings verarbeitet im selben Thread aufrufen
Selbstgeschriebene Stringfunktionen benutzen (was bei fertigen libs allerdings schwierig wird).

Gruß
Erik

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:53.972000Z

Originally created by: 61131

D.Hauer hat geschrieben:
Hallo,
Das Steuerungssystem hat sehr viel damit zu tun.
Der Steuerungshersteller setzt ja die string funktionen in seinem system um.
Bei Berghof und Beckhoff (da weiß ich es, weil ich die einsetze) sind die string funktionen grundsätzlich thread safe.
Dein Steuerungshersteller kann dir da mehr sagen.
cheers

Endlich hatte ich Zeit mit Wago zu telefonieren.
Hmh, die sachten, dass liegt an Codesys, weil das ja auch in der Original-Doku von Codesys so drinne steht. Es seien 2 Funktionen betroffen, "concat" und "?" (die 2te wird noch gesucht).
Hmh, war ein nettes Gespräch, Ergebnis war, man könne sich ja für Concat eine eigene Funktion zusammenbauen (Pointer und so was wie memcpy).

Tja, jetzt steh' ich hier und freue mich..

Grüße,
Martin

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:51.935000Z

Moin

Ob die Standard.lib was damit zu tun hat weiss ich nicht.
Aber das Laufzeitsystem. Das hat wohl was mit der Stack-Reservierung zu tun.
Bei der RTE z.B. sind Stringfunktionen ThreadSafe.
In diesem Fall musst du dich wohl an den Wago-Support wenden.

Gruß Erik

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:46.193000Z

Hallo,

Das Steuerungssystem hat sehr viel damit zu tun.
Der Steuerungshersteller setzt ja die string funktionen in seinem system um.

Bei Berghof und Beckhoff (da weiß ich es, weil ich die einsetze) sind die string funktionen grundsätzlich thread safe.

Dein Steuerungshersteller kann dir da mehr sagen.

cheers

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:44.123000Z

Originally created by: 61131

Hmh, gern:
WAGO 750-880!

Hat die Standard.lib etwas mit dem Steuerungssystem zu tun?

Grüße,
Martin

Stringverabeitung nicht THREAD-SAFE

2020-02-28T04:59:42.061000Z

Moin
Wär nett wenn du den Steuerungstyp angeben würdest.
Gruß Erik

Recent posts to Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

falls es noch jemanden interessiert, hier die Aussge der Fa. Wago zum Thema:

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE

Stringverabeitung nicht THREAD-SAFE