TIA SPLIT-Funktion OHNE ENDSeparator

Warum unbedingt SPLIT?
Es gibt ja neben FIND noch String-Funktionen wie LEFT, MID, RIGHT.
Damit kann man also mit FIND nach der Position des Doppelpunktes suchen, Mit LEN die Länge bestimmen und dann links und rechts davon die gewünschten Teilstrings ausschneiden.

Also

1. FIND
2. LEN
3. LEFT --> Key
4. RIGHT --> Value

1. FIND
2. LEN
3. LEFT --> Key
4. RIGHT --> Value​

Zum Vergrößern anklicken....

Vielen Dank Ralle, ich hab nicht dran gedacht das es auch einfach möglich ist.
Hab es jetzt soweit angepasst, sollte auch funktionieren. Nun bekomme ich aber eine Fehlermeldung wobei ich mein Array of Strings nicht weiter verkleinern kann.

Error: ToDictionary (FC2), Der temporäre Speicherbereich überschreitet die zulässige Größe. Benötigter Speicherbereich: 22786 Bytes (182288 Bits), maximaler Speicherbereich: 16384 Bytes (131072 Bits).



P.S. trotzdem noch die Frage ob es den möglich ohne die Parameter zu Spliten?

Yadid schrieb:

Benötigter Speicherbereich: 22786 Bytes (182288 Bits), maximaler Speicherbereich: 16384 Bytes (131072 Bits).

Zum Vergrößern anklicken....

:sm14: Was splittest Du da in der SPS? Eine ganze Datei? Dein Beispiel war doch nur eine einzelne überschaubare Zeile.
Oder arbeitest Du mit STRING-Arrays mit jedem String der unbegrenzten/maximal möglichen Stringlänge? Dann deklariere die Strings nur mit der tatsächlich maximal benötigten Länge.

Harald

Hallo Harald,
Das Beispiel war nur ein Teil des ganzen nach dem ich das Beispiel ins komplette Projekt eingebunden hatte, tauchte die Nachricht auf.
Das Problem konnte ich lösen indem ich alle STRING-Arrays nicht mehr Temporär speichere sondern als Ausgang auf einen Datenbaustein lade.

Dann deklariere die Strings nur mit der tatsächlich maximal benötigten Länge.​

Zum Vergrößern anklicken....

Das ist leider nicht möglich da der Kunde beliebige String-Nachrichten variable Länge schicken wird.
Die Lösung des ganzen wäre ein dynamisch wachsendes Array zu erstellen wie z.B. in C.
Kann ich aber mit meinen momentanen Kenntnissen in TIA nicht realisieren.
Falls du mir da weiterhelfen kannst wäre ich dir dankbar.

Gruß Yadid

Yadid schrieb:

Dann deklariere die Strings nur mit der tatsächlich maximal benötigten Länge.

Zum Vergrößern anklicken....

Das ist leider nicht möglich da der Kunde beliebige String-Nachrichten variable Länge schicken wird.

Zum Vergrößern anklicken....

Das MUSS möglich sein, sich mit dem Kommunikationspartner auf eine maximale Nachrichtengröße zu einigen. Oder Du mußt es so programmieren, daß Du nur eine maximale Größe (notfalls "häppchenweise") verarbeitest. Es kann nicht sein, daß Du mit Nachrichten von 100-200 Bytes testest und irgendwann schickt Dir der Partner 10kB und Dein Prozess schmiert ab wegen Zykluszeitüberschreitung.
Wofür braucht ein FC 20kB TEMP-Daten? Wenn er die wirklich braucht dann muß da ja irgendwas hineingeschrieben und herausgelesen werden. Das kann schon ganz schön Rechenzeit kosten.

Yadid schrieb:

Die Lösung des ganzen wäre ein dynamisch wachsendes Array zu erstellen wie z.B. in C.
Kann ich aber mit meinen momentanen Kenntnissen in TIA nicht realisieren.

Zum Vergrößern anklicken....

Da laß lieber die Finger davon. Sowas wird aus gutem Grund nicht unterstützt. Dynamische Speichernutzung ist die Hauptursache von Programmabstürzen und unzuverlässig arbeitenden Programmen auf Systemen wo sowas möglich ist. SPS-Programme hingegen müssen absolut zuverlässig arbeiten, mit egal welchen Eingangsdaten.

Harald

PN/DP schrieb:

Dynamische Speichernutzung ist die Hauptursache von Programmabstürzen und unzuverlässig arbeitenden Programmen auf Systemen wo sowas möglich ist.

Zum Vergrößern anklicken....

Die dynamische Speichernutzung soll die Hauptursache von Programmabstürzen sein? Da würde ich gerne mal eine Quelle sehen, oder ein Beispiel warum alleine die Nutzung einer solchen Funktionalität zu einem Programmabsturz führt.

Thomas_v2.1 schrieb:

Die dynamische Speichernutzung soll die Hauptursache von Programmabstürzen sein?

Zum Vergrößern anklicken....

Hmm, wie nennt sich das wenn auf Speicher zugegriffen werden soll, der nicht zu dem anvisierten Objekt gehört oder gar nicht vorhanden ist? Wie kommt eine Anwendung zu einem Pointer zu Speicher, der auf was anderes als den erwarteten Speicher oder auf nicht vorhandenen Speicher oder gar auf nichts zeigt?

Was ist Deiner Meinung nach die häufigste oder eine häufige Ursache von Programmabstürzen?

Harald

PN/DP schrieb:

Hmm, wie nennt sich das wenn auf Speicher zugegriffen werden soll, der nicht zu dem anvisierten Objekt gehört oder gar nicht vorhanden ist? Wie kommt eine Anwendung zu einem Pointer zu Speicher, der auf was anderes als den erwarteten Speicher oder auf nicht vorhandenen Speicher oder gar auf nichts zeigt?

Zum Vergrößern anklicken....

Was du meinst ist vermutlich ein Buffer Overflow, z.B. wenn ein Speicher (z.B. als Array, in C verwendet für Strings) bestimmter Größe angelegt wird, und dann auf ein Index der den Bereich überschreitet zugegriffen wird. Dabei macht es aber keinen Unterschied ob das Array auf dem Stack oder auf dem Heap (mittels dynamischer Speicherverwaltung) angelegt wird. In einem Fall schreibst du dir den Stack kaputt, im anderen Fall den Heap. Das Problem hat mit dynamischer Speicherverwaltung erst einmal nichts zu tun, denn der Fehler ist bei lokalen Variablen auf dem Stack, bei globalen Variablen (wie bei S7 Datenbausteine) wie auch bei dynamisch allokiertem Speicher gleichermaßen möglich.

Wie ein Zeiger auf etwas anderes zeigen sollte als erwartet, und wie das jetzt mit dynamischer Speicherverwaltung zusammenhängt verstehe ich nicht. Zeiger lassen sich (in Sprachen die Zeiger zulassen) auch auf dem Stack anlegen und auf Bereiche auf dem Stack zeigen lassen, oder auf globale Speicherbereiche die statisch allokiert wurden. Warum sollte das Problem hauptsächlich auftreten wenn Speicher dynamisch angefordert wird?

Ich sehe das eher so, das der angeforderte Speicher irgendwann auch wieder sauer freigebeben werden muß. Dabei gibt es immer mal Probleme, es verbleiben "Löcher" etc, trotze moerner Metoden,genau das zu verhindern. Auch Compiler haben Bugs. Das kann schon mal Prbleme geben, die ich auf der SPS nicht haben will. Z.B. dass nach 2 Jahren Laufzeit, der Speicher so durchlöchert ist, dass die SPS einfach mal abschmiert. Bringt in vielen Branchen kein allzu großes Problem, in manchen wäre das eine Katastrophe.