Step 7 String Bearbeitung mit KOP

TomDrom

Level-1
Beiträge
19
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,
mache grad ein Programm, bei dem ich Strings bearbeiten, kopieren und vergleichen muss. Dabei kann sich zum einen die Länge der Strings ändern. Zum anderen werden Teile des Strings mit z.B. Vorwahlen aus dem Bedienpanel (MP277) verglichen.
Für das Ganze benutze ich die Funktionen aus der iec-Bibliothek also FC4, FC10 usw. Dabei habe ich aber größere Probleme:

Problem 1:
In einem DB habe ich einen String mit 16 Zeichen deklariert. Nun will ich mit FC4 die aktuelle Zeichenlänge auslesen. Geht bei mir leider nicht, ich habe Längen wie 18 oder 20??
Wenn ich über Varibalen beobachten/steuern den String beschreibe passiert rein gar nichts.

Problem 2:
Die Funktion MID FC26. Diese Funktion funktioniert im Prinzip wunderbar, außer wenn sich die Zeichenlänge zwischendurch ändert. Habe ich z.B. erst ein Wort mit 8 Zeichen und dann eins mit 7 Zeichen, bleibt das 8 Zeichen drin stehen und wird nicht abgelöscht. Jetzt habe ich mir für diesen Fall einen Lösch-String gebaut, der dann den Ausgangsstring über BLKMOV ablöscht. Das funktioniert auch, ist aber für mich nicht sauber gemacht, weil ich nämlich davon abhängig bin, das im Lösch-String sicher nichts drin steht. Diesen könnte ich mit FILL zwar ständig auf NULL halten, aber da steigt mir dann das BIE-Bit von FC26 aus.
Habe auch schon versucht die Strings lokal anzulegen (mit gleicher Zeichenlänge deklariert, wie die String aus dem DB), aber diese lokalen Varibalen mag der FC26 nicht. Das BIE-Bit wird nicht durchgeschaltet und somit arbeitet der FC26 nicht.

Könnte diese Funktion im Prinzip selber programmieren, zumindest den FC26, kenne mich aber mit der Stringbearbeitung innerhalb FC's leider nicht. Die Strings als IN oder OUT Varibalen zu bearbeiten verstehe ich nicht, oedr habe ich noch nicht rausgefunden.

Kennt sich da von euch jemand damit aus? Ihr würdet mir sehr weiterhelfen. Vielleicht gibt es auch irgendwo Beispielprogramme, wo man mal sieht, wie das Ganze gehandhabt wird.

Vielen Dank an alle

TomDrom
 
Hallo,
so wie du deine Probleme beschreibst gehe ich zunächst davon aus, dass du mit einem un-initialisierten String arbeitest (zu irgendeinem Zeitpunkt muss mindestens der String-Header mit dem String übereinstimmen).
Dann ist es auf alle Fälle sportlich das in KOP zu machen ...
Des Weiteren - wenn du mit den Routinen LEFT,MID,RIGHT arbeitest ... wohin packst du deine Zwischen-Strings ?
Im Prinzip wäre es sinnvoll, deine Arbeit mal sehen zu können - ich würde hier aber AWL bevorzugen.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Larry,
danke schon mal für deine Antwort, werde mal versuchen nachher das Programm hier niederzuschreiben. Bin aber schon etwas weitergekommen. Der FC4 LEN funktioniert. Erstes Problem war, das der FC nicht auf der CPU war:( Naja, macnhmal ist der OB121 doch nicht so gut). Danach habe ich rausgefunden, das dieser FC die Länge der Zeichen zurückbringt die schon an Byte 2 eines Strings stehen. D.h. ich kann genauso gut das Byte 2 direkt auslesen. Mein Problem besteht aber weiter dahin, das sich das Byte 2 vom String nicht aktualisiert, somit bringt auch FC4 nichts zurück. Die Frage ist nun , wie diese Strings arbeiten? Wie aktualisiert die CPU die Anzahl der Zeichen?

Sorry, das mit dem Downloaden vergessen war blöd.

Gruss
TomDrom
 
Werden die Stringfunktionen angewandt, aktualisieren diese auch die Stringlänge in der richtigen Form.
Die Funktionen belegen aber nur den Teil des Strings mit den aktuellen Zeichen, der innerhalb der in Byte 2 angegebenen Länge liegt. Der Rest im String bleibt einfach stehen wie er ist, es kann also aussehen, als ob der "alte String" nach wie vor vorhanden ist, entscheidend ist die Länge in Byte 2.
Wenn das stört, sollte man die Strings vorbelegen (mit Leerzeichen), bevor man sie mit den eigenen Strings füllt.
 
Hallo Ralle
danke schon mal für dein Antwort. D.h. wenn ich das Ganze testen will und ich den String über Variablen beobachten/steuern mache, wird das Byte 2 gar nicht aktualisiert? Habe ich dich da richtig verstanden? Wie kann ich dann meine Programme testen?

Gruß
TomDrom
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
hier das Programm:

Netzwerk 1:
CALL "LEN"
S :="DB_Ein".BUS_EIN.TypString
RET_VAL:=#Laenge_String

Netzwerk 2:
// löscht die Strings VerzahnungAkt und StueckNrAkt erstmal ab.
CALL "BLKMOV"
SRCBLK :="DB_Plausibilität".Check.LoeschString
RET_VAL:=#RETVAL
DSTBLK :="DB_Plausibilität".Check.VerzahnungAkt

CALL "BLKMOV"
SRCBLK :="DB_Plausibilität".Check.LoeschString
RET_VAL:=#RETVAL
DSTBLK :="DB_Plausibilität".Check.StueckNrAkt

Netzwerk 3:
CALL "MID"
IN :="DB_Ein".BUS_EIN.TypString
L :=1
P :=#Laenge_String
RET_VAL:="DB_Plausibilität".Check.VerzahnungAkt

L #Laenge_String
L 2
-I
T #AC0

CALL "MID"
IN :="DB_Ein".BUS_EIN.TypString
L :=#AC0
P :=2
RET_VAL:="DB_Plausibilität".Check.StueckNrAkt

Die Strings sind als String[16] deklariert. Die Lokalvariablen Laenge_String, RETVAL und AC0 sind Integer.
Die Varibale "DB_Ein".BUS_EIN.TypString hat 16 Zeichen. Hier kommt z.B. die Stücknummer L202439E über den Bus rein. Bei dieser Nummer muss zum einen, die Buchstaben rausfiltern um danach als DINT weiterarbeiten zu können. Zum anderen wird das letzte Zeichen (hier jetzt ein "E") gefiltert. Mit diesem letzten Zeichen wird die Art der Verarbeitung (Verzahnung) einer anderen Maschine gewählt. Jetzt kann es aber auch die Stücknummer L79385C geben. Hier nun mit der Bearbeitung "C".
Diese Daten sollen auf Plausibilität gepürft werden und dazu muss ich zum Teil trennen, löschen vergleichen.

Zu deinen Fragen, Larry:
- Was sind un-initialisierte Strings?
- Zwischen-Strings sind im Moment die Strings im DB, die Arbeit mit lokalen Strings hat nicht funktioniert.
- ich habe noch nicht verstanden warum es in KOP schwieriger sein soll?

Vielen, vielen dank!
TomDrom
 
Hallo TomDrom,
ein uninitialisierter String ist so einer, der einfach nur irgendwo deklariert worden ist (z.B. im Bereich der Lokaldaten - TEMP) und in dem dann dadurch die Header-Info's fehlen (deklarierte Länge , tatsächliche Länge). Ist das nicht da dann funktionieren die Siemens-FC's schon mal nicht.
Nun zu deinem Eingangs-String : der kommt von iregdwoher in die SPS ... aber hier wirklich als String mit den korrekten Header-Info's ? Oder schreibst du den erst in einen String und hast ggf. den Header vergessen ?

In KOP ist es für mich schwieriger zu sehen ... :(

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo dtsclipper,
Wäre evtl. auch ne Idee, ist mir bis jetzt noch nie gekommen. Müsste mit halt meine Funktionen selber zusammenbasteln. Zum jetztigen Zeitpunkt fehlt mir dazu aber die Zeit.
Aber trotzdem Danke, werd ich mir merken.
 
Zuletzt bearbeitet:
Hallo Larry,
ja diese Erfahrung habe ich nun nach dem heutigen Tag auch gemacht. Fehlt die aktuelle Länge in Byte 2 funktionieren die String-Funktionen nicht, meistens fehlt dann das BIE-Bit, oder es geht halt nicht.
Der Eingangsstring "DB_Ein".BUS_EIN.TypString wird mal irgendwann vom Profibus kommen. Im Moment beschreibe ich ihn über die Variablentabelle, geht ja nicht anderes...das bedeutet dann aber, dass ich das Header-Byte 2 vom String immer von Hand steuern muss. Dann funktioniert's auch.

Gibt es denn Möglichkeit, Strings anders zu steuern als über die Variablentabelle. So, dass das Header-Byte immer stimmt?

Hat jemand noch ne Lösung zu Problem 2 (siehe erster Beitrag)? Das Ablöschen mit dem BLKMOV (vor der eigentlichen Bearbeitung des Strings) ist im Moment das Einzige was mir eingefallen ist.

Dank an alle
TomDrom
 
Gibt es denn Möglichkeit, Strings anders zu steuern als über die Variablentabelle. So, dass das Header-Byte immer stimmt?
Ja ... du könntest dir z.B. in einer vorhandenen Visu ein Eingabefeld dafür machen. Das würde den Stringheader immer mitziehen ...

Hat jemand noch ne Lösung zu Problem 2 (siehe erster Beitrag)? Das Ablöschen mit dem BLKMOV (vor der eigentlichen Bearbeitung des Strings) ist im Moment das Einzige was mir eingefallen ist.
Das ist auch die einzige Möglichkeit die mir einfällt. Du müßtest vor dem Empfangen des String (der kommt warscheinlich als Array of Char oder Byte) deinen Hilfsstring mit chr(0) löschen und den Header manuell korrigieren (das kann aber auch eine selbstgebaute Funktion für dich machen - dann ist es übersichtlicher), dann liesst du deinen String, der aus der Perepherie kommt darin ein, und ermittelst dann die tatsächliche Länge in dem du den String von hinten nach vorne scannst und beschreibst dann passend den Header des String (das wäre dann auch wieder etwas, dass eine eigene FC für dich erledigen könnte).
Danach funktioniert dann auch die restliche String-Geschichte (schreibst du ja auch selber).

Etwas schöner zu machen (als in AWL oder KOP oder FUP) ist so etwas generell in SCL ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Larry,
danke nochmal für deine Ideen, kann ich alles sehr gut gebrauchen. Hatte heute Morgen auch nochmal ne Idee wie ich mir die BLKMOV sparen kann. Ich wollte eigentlich von Anfang an lokale Strings nehmen, aber da die ja nicht die richtigen Header-Infos hatten, funktionierten die String-Funktionen nicht. Jetzt habe ich aber ganz einfach die lokalen Bytes der Strings mit Header-Infos gefüttert und siehe da, die String-Funktionen machen ihre Arbeit. Wichtig ist bloß, die lokalen Variablen am Anfang mit „0“ abzulöschen, sonst geht’s wieder nicht;)
Hoffe jetzt nur, dass ich mir nicht noch en Ei gelegt habe, das ich noch nicht weiß.

Grüße
TomDrom

PS: Ja, SCL wär mir auch lieber, vorhanden Programme auf SCL umstellen ist aber Aufwand und brauch Zeit.
 
Zurück
Oben