OPC String nach TIA V17 String/wstring

[AW123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich bin gerade dabei mich in OPCUA einzuarbeiten.
Ich habe vom Kunden eine XML Datei bekommen mit verschiedenen Datenpunkten. Unter anderem
Datenpunkte mit Strings. Wenn ich die XML Datei nach TIA konvertiere macht mir TIA alle Strings
zu wstrings.
Da wir UNICODE verwenden wollen ist dies auch ok.
Als ich die wstrings in Strings einfach mal gewandelt habe konnte ich auch UNICODE Zeichen verwenden.
Ich dachte immer String = ASCII wstring UNICODE.
Heist dies, dass ich auch nen String verwenden kann? Wenn ja mit welcher Länge? 127 der 254?

Die nächste Frage ist:

Welche länge hat ein String in OPC? 256 mit header?
Weil dann könnte ich auch ein wstring verwendet und diesen begrenzen. Derzeit sind alle offen
was natürlich zu hoher Speicherauslastung führt.

MfG AW123

 

[Tschoke]

Ein String in der SPS ist "ISO 8859-1". ASCII besteht aus nur 7Bits (127 Zeichen). "ISO 8859-1" besteht aus 8 Bits. Die ersten 7 haben aber die gleiche Bedeutungen wie ASCII. ASCII kann zum Beispiel keine Umlaute. "ISO 8859-1" (bzw. ein String in der SPS) schon. "ISO 8859-1" ist eine Erweiterung von ASCII. Man sieht auch häufiger die Bezeichnung ASCII-256.
Ein WString ist USC2. Mit 16Bit (fixe Länge) pro Zeichen.
Ich glaube nicht das du ein Zeichen vom WString, das nicht in "ISO 8859-1" vorhanden ist, in einen String erfolgreich gewandelt hast.
Wie soll das auch gehen.

 

[AW123]

Zuviel Werbung?
-> Hier kostenlos registrieren

ah ok. dann war die Vermutung richtig mit 127 Zeichen. Das wiederum bedeutet, ich muss einen Wstring verwenden, da
es sonst zu Fehlern kommt bei größer 127 Zeichen vom OPCUA.
SO wie ich es verstehe, hat ein String vom OPCUA 254 Zeichen im "ISO 8859-1" Format. Somit muss ich zwingend
ein wstring[254] verwenden.

 

[Thomas_v2.1]

Die Stringlänge hat nichts mit der Zeichencodierung zu tun. Was Tschoke mit 127 Zeichen meint, ist, dass du mit 7 Bits 127 verschiedene Zeichen codieren kannst.

 

[Tschoke]

@Thomas_v2.1 Richtig.
Fass nochmal zusammen:
In Siemens SPSen:
String: Max Länge=254, Codierung="ISO 8859-1", 8Bit pro Zeichen in String
WSTRING: Max Länge=16382, Codierung=USC2, 16Bit pro Zeichen in String

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

In Siemens SPSen:
String: Max Länge=254, Codierung="ISO 8859-1", 8Bit pro Zeichen in String
WSTRING: Max Länge=16382, Codierung=USC2, 16Bit pro Zeichen in String

Hast du eine Quelle für ISO 8859-1 für String bei Siemens SPS?

Da war doch letztens das Thema, dass Siemens warnt wenn ich einen deutschen Umlaut in einem String verwende. Die wären nämlich in ISO 8859-1 enthalten und die Warnung wäre falsch, jemand meinte hier aber, da wäre angeblich nur ASCII erlaubt. Wenn die Codepage variabel wäre, dann würde mir auch bei S_CONV ein zusätzlicher Parameter für die Codepage des Strings fehlen, wenn ich von String auf WString / String auf WString konvertiere. Die Funktion macht für mich etwas undokumentiertes.

 

[Tschoke]

Nein ich habe keine Quelle. Kann aber eigentlich nichts anderes sein. Umlaute funktionieren ja.
Hab es mir grad nochmal angeschaut. Die Warnung sagt:
...Beachten Sie, dass die Darstellung von Sonderzeichen von den Regions- und Spracheinstellungen auf dem PG/PC abhängt.
Die beziehen sich nur auf PG und nicht auf die SPS.
Wenn ich ein chinesisches Zeichen einfüge kommt: ...kann in der eingestellten Kultur nicht codiert werden.
Ich glaube da bringt Siemens ein paar Sachen durcheinander. Die Kultur ist in dem Fall egal. Ich bin mir ziemlich sicher, dass es kein encoding gibt in dem ein chinesisches Zeichen in 8Bit passt.

 

[Thomas_v2.1]

Aber mal angenommen, jemand aus Griechenland programmiert in TIA und gibt in einem String ein Delta ein, was unter ISO 8859-7 0xC4 wäre. Was passiert wenn er dieses Zeichen in einen String eingibt, und das mit S_CONV in einen Wstring konvertiert? Sieht er dort ein "Ä" oder ein "Δ"? Dann ist das nicht nur ein Darstellungsproblem, sondern das im SPS-Programm selber wird das auch anders verarbeitet. Mich hat das bei S_CONV schon immer gewundert, weil wenn ich unter Windows etwas von Single- in Multibyte String konvertieren will, muss ich der Funktion die Codepage des Single-Byte Strings übermitteln.

 

[Tschoke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab es getestet:

In dem Fall ist die Zuweisung des String Wertes, im TIA, Spracheinstellungs-Abhängig.
Aber s_conv nimmt immer ISO 8859-1.
Das haben sie wohl verkackt.

 

[Thomas_v2.1]

Eben. Ich gehe mal davon aus, dass die TIA Programmieroberfläche Unicode ist. Bei der Codegenerierung muss dann bei String immer auf ISO 8859-1 konvertiert werden. Dann würden deutsche Umlaute auch keine Warnung benötigen, weil das dort völlig problemlos darstellbar ist. Nur der Grieche und alle anderen bekommen ein Problem (ggf. muss er dann mit Steuercode hantieren), aber besser der Fehler tritt beim Programmieren auf als später im Programm. Schwierig da für alle Länder einen passenden Weg zu finden, aber so wie es jetzt ist, ist es auch nicht richtig.