TIA UINT to String Unterschied zwischen KOP und SCL?

[UDP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich hatte grade beim Testen mit PLCSIM unter 15.1 Upd4 folgendes Verhalten, dass ich mir nicht erklären kann:

Wenn ich die mittels S_Conv einen UINT in einen String wandeln möchte, ist das Ergebnis anders, als wenn ich das Ganze in SCL nachstelle. Als Code in SCL habe ich folgendes Verwendet:

#statYear_SCL := UINT_TO_STRING(#statSystime.Year);

Zum Vergleich rufe ich das ganze danach nochmal in KOP über S_CONV auf, beides in einem FB mit optimiertem IDB im OB1. Mehr Programm ist nicht enthalten. Was mache ich falsch, dass die Ergebnisse sich so Unterscheiden?

 

[Heinileini]

Was mache ich falsch, dass die Ergebnisse sich so Unterscheiden?

Sooo unterschiedlich sind die Ergebnisse nicht. Beide liefern 2022. Genauer: StringDarstellung in SCL '+2022' und in KOP ' 2022', also einmal mit '+' und einmal mit ' ' als positives Vorzeichen.
Allerdings ist der Unterschied in der Darstellung Array of Char etwas grösser.
Bei SCL steht das Ergebnis linksbündig und bei KOP rechtsbündig in den 6 Zeichen.
Wie kann es sein, dass in der StringDarstellung des KOP-Ergebnisses von den 2 vorausgehenden Leerzeichen nur eins zu sehen ist?

Edit:
Scheint wohl keine MonoSpace-Schriftart für die Darstellung der Strings verwendet worden zu sein ... das, was wir dort sehen, sind anscheinend 2 Leerzeichen.

 

[UDP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei der KOP-Darstellung landen doch beide Leerzeichen im Array? Im SCL ist der String nur 5 Zeichen lang.

Ich finde den Unterschied schon nicht unerheblich, in der einen Darstellung habe ich einen String mit 6 Zeichen und 2 führenden Leerzeichen, in der anderen 5 Zeichen und ein führendes Vorzeichen. Ich hätte jetzt eigentlich das gleiche Ergebnis erwartet, wenn ich die gleiche Funktion verwende.

 

[codemonkey]

UINT_TO_STRING und S_CONV sind nun mal nicht die gleiche Funktion.

Aus der Hilfe:

Der Wert wird in eine Zeichenkette konvertiert.

Die ersten Zeichen der Zeichenkette werden mit Leerzeichen aufgefüllt. Die Anzahl der Leerzeichen ist abhängig von der Länge des numerischen Werts.

Positive numerische Werte werden ohne Vorzeichen ausgegeben.

Wenn die Länge der Zeichenkette überschritten wird, wird der Freigabeausgang ENO auf "0" gesetzt.

Für SCL gelten folgende Besonderheiten:

Es werden keine Leerzeichen eingefügt.

Die Zeichenkette wird mit einem führenden Vorzeichen dargestellt.

 

[UDP]

@codemonkey : Danke für die Information, das war mir so nicht bewusst. Ich hatte an der Stelle ursprünglich aus der Bausteinbibliothek S_Conv nach SCL gezogen und dann die Datentypen ausgewählt, daher ging ich davon aus, dass es sich um die gleiche Funktion handelt. Finde es nach wie vor Eigenartig, dass es sich so verhält, aber scheint ja ein gewolltes Verhalten zu sein.

Bedeutet das im Umkehrschluss dann aber nicht, dass es keine 1 zu 1 Übersetzung des KOP-Bausteins zu SCL gibt?

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

@codemonkey : Danke für die Information, das war mir so nicht bewusst. Ich hatte an der Stelle ursprünglich aus der Bausteinbibliothek S_Conv nach SCL gezogen und dann die Datentypen ausgewählt, daher ging ich davon aus, dass es sich um die gleiche Funktion handelt. Finde es nach wie vor Eigenartig, dass es sich so verhält, aber scheint ja ein gewolltes Verhalten zu sein.

Bedeutet das im Umkehrschluss dann aber nicht, dass es keine 1 zu 1 Übersetzung des KOP-Bausteins zu SCL gibt?

Willkommen im Club ... Darüber hab ich auch schon geflucht.
Ich schreibe fast keine reinen SCL-Bausteine mehr, sondern nutze sehr oft SCL-Netzwerke in KOP/FUP.
Damit bin ich dann flexibel

 

[TP-Inc]

Willkommen im Club ... Darüber hab ich auch schon geflucht.
Ich schreibe fast keine reinen SCL-Bausteine mehr, sondern nutze sehr oft SCL-Netzwerke in KOP/FUP.
Damit bin ich dann flexibel

Aber total unflexibel wenn man zB einen Baustein den man in V16 geschrieben hat in einem V15.1 Projekt verwenden will… deshalb nehm ich nur noch SCL für Standard-Bausteine

 

[UDP]

Willkommen im Club ... Darüber hab ich auch schon geflucht.
Ich schreibe fast keine reinen SCL-Bausteine mehr, sondern nutze sehr oft SCL-Netzwerke in KOP/FUP.
Damit bin ich dann flexibel

Ich wollte an der Ursprünglichen Stelle auch einfach "nur" einen reinen SCL Baustein im Programm haben von einer Funktion, die vorher im KOP realisiert wurde und dabei bin ich über dieses Verhalten gestolpert. Ich wäre glaube auch nie auf die Idee gekommen die Hilfe zu einem Baustein nach Unterschieden SCL/KOP zu durchsuchen, aber scheinbar muss man das jetzt wohl machen.

Ich wollte nämlich genau das machen was @TP-Inc beschreibt und wollte dazu mal eben fix den Baustein so wandeln, dass ich eine Quelle generieren kann. Geht ja leider nur, wenn Bausteine als rein SCL angelegt werden.

Kennt jemand noch weitere Funktionen, wo es Unterschiede in der Funktion zwischen Programmiersprachen gibt?

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätte jetzt eigentlich das gleiche Ergebnis erwartet, wenn ich die gleiche Funktion verwende.

Soweit die Theorie. Aber auch Gepflogenheiten haben einen Einfluss.
Wer schreibt schon ein positives Vorzeichen? Es ist also (meistens) völlig korrekt, ein positives Vorzeichen "wegzulassen".
Aber was heisst "weglassen" in diesem Fall? Durch ein Leerzeichen ersetzen, damit untereinander geschriebene Zahlen nicht unnötig mal nach links, mal nach rechts ausgerichtet werden? Oder "wirklich" weglassen, damit der ErgebnisString um Himmels Willen nie länger als unbedingt nötig wird?
Oder sollte man auch positive Vorzeichen grundsätzlich schreiben? Der Computer wird diese "MehrArbeit" klaglos verrichten.
Es gibt auch Schreibweisen, bei denen das Vorzeichen rechts (also hinter der Zahl) erscheint.
Oder "ganz weit links", gefolgt von vielen Leerzeichen als Platzhalter für die Darstellung grosser Zahlen, bis dann die erste Ziffer >0 folgt.
Soll man "vorlaufende Nullen" unterdrücken (durch Leerzeichen ersetzen) oder nicht?
Egal, wie man das "Problem" löst, es wird immer GegenArgumente geben, um eine andere DarstellungsForm bevorzugen.
Darum wurden auch Funktionen erfunden, die eine Formatierung der ZahlenDarstellung ermöglichen, weil die zu erfüllenden Kriterien je nach Anwendung und Geschmack sooo unterschiedlich sein können.
Dies ist allerdings etwas, das in der SPS-Programmierung nocht nicht so richtig angekommen ist. Die üblichen Funktionen, die für die TextBearbeitung in SPS geboten werden, sind sehr rudimentär und z.T. so, wie sie sind, kaum zu gebrauchen.
Aber die SPS-Programmierung bietet natürlich die Möglichkeit, selber Funktionen zu stricken, ganz nach eigenem Geschmack oder als eierlegende WollMilchSau, mit der sich viele dann in der Anwendung (fast) überfordert fühlen.
Du bist über ein Beispiel gestolpert, bei dem die Begriffe "korrekt" bzw. "inkorrekt" leider "GummiBegriffe" sind. So dehnbar, dass sie sich leicht überschneiden können.

 

[Blockmove]

@Heinileini
Sorry aber irgendwie kann dich deinen Ausführungen nicht ganz folgen bzw. auch nicht verstehen.
Siemens hat die Wandlung als EINGEBAUTE Funktion in SCL und in KOP.
Und die Funktionen liefern unterschiedliche Ergebnisse. Das ist einfach nur Müll und hat nichts mit Gepflogenheit zu tun.

 

[UDP]

Sehe das genau wie Blockmove. Mir persönlich ist es auch egal, welche der beiden Varianten jetzt die "richtige" ist. Aber ein unterschiedliches Verhalten geht halt gar nicht.

Das ist doch hier ein gutes Beispiel: Ich muss schon wissen, ob hier aus einer 4-stelligen Jahreszahl ein 6-stelliger String mit 2 führenden Nullen wird oder ein 5-stelliger String mit führendem Vorzeichen. Abhängig davon kann (oder muss) ich den String doch im Nachhinein ganz anders behandeln, wenn ich damit weiterarbeiten möchte. Und dann abhängig davon ob ich den String in SCL oder in KOP erstellt habe ein unterschiedliches Handling einbringen zu müssen, ist halt auch sehr unglücklich gelaufen von seitens Siemens.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Siemens hat die Wandlung als EINGEBAUTE Funktion in SCL und in KOP.
Und die Funktionen liefern unterschiedliche Ergebnisse. Das ist einfach nur Müll und hat nichts mit Gepflogenheit zu tun.

Und dann abhängig davon ob ich den String in SCL oder in KOP erstellt habe ein unterschiedliches Handling einbringen zu müssen, ist halt auch sehr unglücklich gelaufen von seitens Siemens.

Ihr habt ja beide Recht und das wollte ich auch gar nicht wegdiskutieren!
SOS (Shame on Siemens)!
Fakt bleibt aber, dass StringBefehle in der SPS-Programmierung (wie auch in manchen anderen ProgrammierSprachen) recht stiefmütterlich ausgeführt sind.
Was mich ein wenig wundert ist, dass die zunehmende Anwendung von WString noch keine Lawine von Beiträgen hier im Forum ausgelöst hat.
Muss wohl daran liegen, dass überwiegend Wandlungen String -> WString gefragt sind und nicht in Richtung WString -> String ...