TIA String und Sonderzeichen Warnung

Beiträge
9.191
Reaktionspunkte
2.950
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

wenn ich im SPS-Programm Strings verwende und hier deutsche Umlaute in den Text eingebe, erhalte ich ja an jeder Stelle eine Warnmeldung wie:

Der Text ''ä'' enthält Sonderzeichen. Beachten Sie, dass die Darstellung von Sonderzeichen von den Regions- und Spracheinstellungen auf dem PG/PC abhängt.

Jetzt könnte ich natürlich anstelle String ein WString verwenden, nur um die Warnmeldung wegzubekommen, was aber dementsprechend den doppelten Speicher benötigt. Grundsätzlich sind Warnmeldungen immer unschön, aber man muss ja auch an den Speicher denken. Denn wenn ich die Strings in einer UDT habe, dann werden wenn nur ein Wert in der UDT remanent sein soll, gleich alles remanent und somit auch die Strings. Weil ich um das HMI Engineering zu vereinfachen, einige mehr Strings aus der SPS übernehmen wollte, werden das letztendlich einiges mehr an Strings und ggf. auch Warnmeldungen. Gibt es dazu eine Lösung?
 
Worauf bezieht sich die Warnmeldung? Auf den Inhalt des Strings oder den Variablenname des Strings? Hast Du ein Beispiel?
Meine Meinung: Der Inhalt des Strings sollte dem TIA egal sein, das weiß doch gar nicht auf welchem Gerät der String angezeigt werden soll, da sollte es keine Warnung geben oder die Warnung sollte abwählbar sein.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Warnung kommt, sobald du z.B. einen deutschen Umlaut in dem Text hast. Also 'Loesung' ist Ok ohne Warnung, 'Lösung' erzeugt eine entsprechende Warnung. Der Warntext mag ja auch richtig sein, aber dann habe ich bei hunderten Texten anschließend hundert Warnungen, und wenn darunter doch mal eine sinnvolle Warnung ist, dann geht diese unter weil die kaum jemand durchgehen wird.
 
Aus diesem Grund verwende ich WString statt String. Braucht zwar doppelt so viel Speicherplatz aber dafür gibt es keine Warnungen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aus diesem Grund verwende ich WString statt String. Braucht zwar doppelt so viel Speicherplatz aber dafür gibt es keine Warnungen.
Ach sooo. Ja, jetzt habe ich's verstanden. Siemens will den Programmierern den Umstieg auf WString schmackhaft machen, weil sie freiwillig nie diesen Schritt der Globalisierung auf sich nehmen würden. ;)

... nur damit der Compiler nicht mehr warnt...
Der Compiler kann doch nur warnen bei TextKonstanten mit diesen fürchterlichen Umlauten und dem noch schlimmeren 'ß'!
Wenn die SPS zur Laufzeit über solche Zeichen in StringVariablen stolpert, dann warnt sie gar nicht?
Das genügt aber nicht, um die Programmierer endgültig umzupolen!

In CodeSys liesse sich das doch noch einbauen, so wie die Prüfung auf Division durch 0 oder die Prüfung auf Unter- bzw. Überschreitung der BereichsGrenzen von Arrays zur Laufzeit ... oder gibt's das schon in CodeSys für die mehrdeutigen Zeichen in Strings? ;)
 
wenn man Program_Alarm verwendet, hat man nicht die Möglichkeit, WString bei den Begleitwerten zu verwenden. Da meckert der Compiler immer
Das habe ich noch gar nicht getestet, das würde mein Problem dann nur verschieben, da ich das wirklich auch bei den ProgramAlarm verwenden möchte.

Aber davon habe mich mittlerweile eh wieder verabschiedet, da gibt es noch einige andere Einschränkungen die vermutlich die Vorteile wieder aufwiegen.

Aber bei den Warnungen wäre es schon nützlich, dass man bestimmte Warnungen deaktivieren kann. Wenn ich weiß, dass mein Projekt ausschließlich in einer Sprache auf dem PG programmiert wird, kann ich das doch ignorieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn dir der Speicher und Zykluszeit doch egal sind dann gäb's da noch eine Variante:
Leg deine Texte als WString an und wandle sie bei der Übergabe an "Program_Alarm" in String.
 
Wenn dir der Speicher und Zykluszeit doch egal sind dann gäb's da noch eine Variante:
Leg deine Texte als WString an und wandle sie bei der Übergabe an "Program_Alarm" in String.
Müsste es da nicht auch eine Warnung geben? In WString lassen sich ja auch chinesische oder kyrillische Zeichen eingeben, und die gehen garantiert verloren. Bzw. wovon wäre es dann abhängig ob die Darstellung einwandfrei funktioniert?

Ich habe mich ja jetzt gegen das Anlagen in der SPS entschieden. Das sprengt vermutlich jeden Rahmen bezüglich Speicherplatz und Laufzeit, auch wenn es eigentlich komfortabel wäre.
 
Der Compiler ahnt ja nicht was im String drinstehen wird, kann also auch nicht warnen...

Wow,Wow,Wow... mal langsam, hier gings um Warnungen des Compilers nicht um Chinesische Schriftzeichen!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das geht doch nicht nur um chinesische Zeichen, denn im ASCII Zeichensatz existieren auch mehrere Codepages wonach deutsche Umlaute theoretisch unterschiedlich konvertiert werden könnten. Wenn für den Datentyp String die Codepage feststeht damit WString zu String immer gleich funktioniert, dann sollte es das im Editor doch eigentlich auch sein. Ich habe noch nicht die Hilfe dazu konsultiert ob dazu etwas vermerkt ist.
 
wenn ich im SPS-Programm Strings verwende und hier deutsche Umlaute in den Text eingebe, erhalte ich ja an jeder Stelle eine Warnmeldung wie:

Der Text ''ä'' enthält Sonderzeichen. Beachten Sie, dass die Darstellung von Sonderzeichen von den Regions- und Spracheinstellungen auf dem PG/PC abhängt.

Jetzt könnte ich natürlich anstelle String ein WString verwenden, nur um die Warnmeldung wegzubekommen, was aber dementsprechend den doppelten Speicher benötigt. Grundsätzlich sind Warnmeldungen immer unschön, aber man muss ja auch an den Speicher denken. Denn wenn ich die Strings in einer UDT habe, dann werden wenn nur ein Wert in der UDT remanent sein soll, gleich alles remanent und somit auch die Strings. Weil ich um das HMI Engineering zu vereinfachen, einige mehr Strings aus der SPS übernehmen wollte, werden das letztendlich einiges mehr an Strings und ggf. auch Warnmeldungen. Gibt es dazu eine Lösung?

TIA erlaubt die Einfügung Deiner in Windows eingestellten Zeichen nur weil Dein System auf der 8-Bit ASCII-Tabelle basiert. Du musst allerdings Zeichen aus der 7-Bit ASCII-Tabelle eingeben. Nur das wäre IEC-konform, und durch die Warnung hält sich Siemens daran und hat es entsprechend normgerecht umgesetzt.

Um nun aber die Zeichen ohne Warnung im STRING nutzen zu können musst Du diese direkt im HEX-Code angeben:
falsch: 'Lösung'
richtig: 'L$F6sung'
Hier ist also das Fluchtsymbol $ genutzt um anschließend aus unserer Ascii-Tabelle das Zeichen HEX F6 auszuwählen. TIA interpretiert das $ als o als Ankündigung "hiernach kommt was was anders dargestellt sein muss".

Sollte man die Warnung ignorieren dann kann auf einem PC mit eingestellter Codepage Englisch eben ein anderes Zeichen erscheinen da an der Stelle des ö eben ein anderes Zeichen eingesetzt ist.

STRING ist immer eine Kodierung nach ASCII 7-Bit. Jedes Zeichen ist ein Byte.
WSTRING ist eine Kodierung nach Unicode. Das sind bis zu 4 Byte pro Zeichen. TIA nutzt eine 2-Byte Variante (Twincat 3 glaub auch). Hierdurch sind eben die meisten Sonderzeichen aber auch Buchstaben der verschiedenen Sprachen abgedeckt.

Da ich immer häufiger ausschließlich IEC-konforme Projekte abgeben darf muss ich selbst immer unterscheiden ob ich STRING oder WSTRING nutze. Sobald es ein Programm mit möglicher Sprachumschaltung sein muss wird eben WSTRING genutzt, da STRING sonst zu komischen Zeichen führen würde. Falls jemand dafür natürlich eine elegantere Lösung kennt, bin ich auch gerne offen dafür ;).
 
Welche IEC gilt denn bei TIA?
In der IEC61131-3 gilt der Zeichensatz Row 00 aus dem IEC 10646 Zeichensatz, und das ist so wie ich das verstehe Latin-1 aka IEC 8859-1, also 8 Bit mit deutschen Umlauten.

1646867262519.png
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Welche IEC gilt denn bei TIA?
In der IEC61131-3 gilt der Zeichensatz Row 00 aus dem IEC 10646 Zeichensatz, und das ist so wie ich das verstehe Latin-1 aka IEC 8859-1, also 8 Bit mit deutschen Umlauten.
Öhm, die 61131 ist schon gemeint:

Du zitierst hier das Row 00 des 10646-Sets genommen werden soll. Das ist 00 bis 7F der Unicode-Tabelle, Row 00 eben. Dort kommt noch kein öäü vor:

Ebenso steht direkt nach der gelben Markierung "the three-character combination of the dollar sign ($) followed by two hexadecimal digits shall be interpreted as the hexadecimal representation of the eight-bit character code, as shown in feature 1 of table 5."

Bedeutet letztendlich doch das nur der 7-Bit Satz genutzt wird, aber ein $-Zeichen dafür sorgen soll das auch 8-Bit Zeichen dargestellt werden können.
 
Wenn dir der Speicher und Zykluszeit doch egal sind dann gäb's da noch eine Variante:
Leg deine Texte als WString an und wandle sie bei der Übergabe an "Program_Alarm" in String.
Das geht zwar, aber im ProgramAlarmmeldung wird die Text kriptisch dargestellt. Siehe das Bild.
Meldung besteht aus;
Schlüsselword PLC NAme / Tagnummer als String / klartext in Wstring / feste klartext
Die sprache ist Russisch.

Ich such grad nach ein alternative.

https://sieportal.siemens.com/de-de...ring-als-begleitwert-f-r-program-alarm/145096
Möglich nach Bitmeldeverfahren umsteigen.


Image.jpg
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Siemens implementiert mit wstring also einen mehr-Byte Unicode.
In der IT-Welt hat sich das ja wegen der oben diskutierten Probleme nie durchgesetzt. Hier wird immer utf-8 benutzt.
Würde es nicht Sinn machen, das in der SPS Welt genauso zu tun?
 
Zurück
Oben