TIA Strings auslesen und vergleichen bei unterschiedlicher Zeichenlänge

[DennisBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo
wir haben einen QR Code Leser der uns in einen db von [243] bis [253] den ausgelesenen Code Buchstabe für Buchstabe im ascii Format überträgt (beispiellänge 10 Zeichen)
Liest er zb Auto dann steht in [243] "A" in [244] "u" in [245] "t" und [246] "o" in allen anderen (da Name kürzer als 10 Zeichen) von [247] bis [253] steht '$00'
den daraus generierten String vergleichen 'Auto' - 'Auto' funktioniert.

Nun haben wir eine CSV Datei in denen 5 ähnliche Namen abgelegt sind mit unterschiedlicher Zeichenlänge zb Auto, Autos, Automatik, Autor

Wie mache ich das nun, dass der Vergleich -> angewähltes Produkt aus CSV Datei mit gelesenem QR Code vom Leser
auch bei ähnlichen und kürzeren oder längeren Namen funktioniert?

Der QR Code Leser wertet zb folgende Zeichen aus und schreibt dann in den db:
'Autos$00$00$00$00$00" 243 bis 247 = Autos, ]248] bis [253] = $00
In der CSV Datei als string steht aber nur 'Autos' ohne die $00

nun würde ich ja 'Autos' (aus der csv datei gelesen) mit 'Autos$00$00$00$00$00' vom QR Code vergleichen und somit kein VKE=1 erhalten.

Ich möchte nicht alle Namen in der CSV Datei künstlich auf 10 Zeichen verlängern mit $00 oder anderen Platzhaltern.

Ich hoffe ich hab das einigermaßen verständlich erklärt worin das Problem ist.:shock:

Das weitere Problem ausser den $00 und kürzeren Zeichen ist, dass er 'Auto' nicht bei 'Autos' oder 'Automatik' erkennen soll

danke für Hilfe


P.s. hab eben rausgefunden dass $00 = Lerrzeichen ist, das würde dann bedeuteten, dass ich oben viel zu kompliziert gedacht habe oder?

 

[maxder2te]

P.s. hab eben rausgefunden dass $00 = Lerrzeichen ist, das würde dann bedeuteten, dass ich oben viel zu kompliziert gedacht habe oder?

Nein, $00 ist das sogenannte NULL-Zeichen. Das Leerzeichen hat den Ascii-Code $20.

Außerhalb die Simatic-Welt ist es üblich, Strings "Nullterminiert" abzulegen. Das bedeutet, dass ein String im Speicher um 1 Byte mehr belegt, als er tatsächlich Zeichen besitzt. Um beim Beispiel 'Auto' zu bleiben, benötigt der String 5 Bytes: 4 Bytes für die Zeichen und 1 Byte mit dem Inhalt $00.

In der Simatic-Welt macht man das anders. Hier stehen vor der eigentlichen Zeichenkette die 'maximale Länge' und die 'tatsächliche Länge', so dass Stringfunktionen nicht mühsam die Nullterminierung suchen müssen.

Was du nun machen willst ist ein "weder-noch". Es wird dir nichts anderes übrig bleiben als Zeichen für Zeichen zu vergleichen und die Null-Felder abzufragen. Anbei ein Codebeispiel (welches nicht 1:1 S7-kompatibel ist)

a: ARRAY[0..9] OF CHAR;
lena: INT;
QR: ARRAY[0..253] OF CHAR;    // in [243]-[253] steht der Code
i: INT;
equal: BOOL;

a := "Auto";
lena := 4;
equal := TRUE;
FOR i:= 0 TO 9 DO
    IF ((i > lena) AND (QR[i+243] = 0)) THEN
        EXIT;
    ELSIF (QR[i+243] <> a[i]) THEN
        equal := FALSE;
        EXIT;
    END_IF;
END_FOR;

Am Ende ist der Vergleich positiv, wenn equal = TRUE ist.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Außerhalb die Simatic-Welt ist es üblich, Strings "Nullterminiert" abzulegen. Das bedeutet, dass ein String im Speicher um 1 Byte mehr belegt, als er tatsächlich Zeichen besitzt. Um beim Beispiel 'Auto' zu bleiben, benötigt der String 5 Bytes: 4 Bytes für die Zeichen und 1 Byte mit dem Inhalt $00.

In der Simatic-Welt macht man das anders. Hier stehen vor der eigentlichen Zeichenkette die 'maximale Länge' und die 'tatsächliche Länge', so dass Stringfunktionen nicht mühsam die Nullterminierung suchen müssen.

Ich glaube C ist wohl die einzige Sprache in der Strings nullterminiert ablegt werden, genaugenommen existiert in C der Datentyp String nicht. Es ist ganz einfach ein char-Array bzw. ein char-Pointer.

So wie mit Strings üblicherweise gearbeitet wird, wie aneinanderreihen von Strings, ist die Nullterminierte Speicherung gegenüber der Speicherung mit Längenangabe immer im Nachteil.
In den String-Objekten der meisten objektorientierten Programmiersprachen verstecken sich darum entsprechende Variablen zur Speicherung der Länge.

Wenn man heutzutage immer noch nur 1 Byte für die Stringlänge vorsieht, ist das natürlich etwas sparsam. Als Jugendlicher habe ich unter CP/M mit Turbo Pascal meine ersten Programmierversuche gemacht, und da wurden die Strings mit Abspeichern der Längeninformation abgelegt. Das ist auch fast 30 Jahre her, aber bei manchen 300er CPUs platzt der Stack ja bei 254er Stringlängen schon aus allen Nähten. Und bei den neuen "modernen" CPUs hat man das warum auch immer beibehalten. Mit 2 Bytes für die Längenangabe hätte man in der SPS jeden Anwendungsfall erschlagen können, so wie es jetzt ist bastelt man sich ordentlich einen zurecht wenn längere Strings benötigt werden.