String: Übergabe der Max Länge Falsch

... so langsam wird es etwas klarer ...

Irgendetwas füllt dir deinen Datenbaustein.
Mit den verschiedenen Funktionen greifst du unterschiedliche Stellen des DB's ab und verschiebst Lese-Pointer etc. (Seek).

Dann von Anfang an :
1.) steht der erwartete Inhalt in der korrekten Form im Puffer ?
2.) liefert dir "DCI_SeekByParamID" das korrekte Ergebnis ?
3.) liefert dir dann darauf "DCP_ReadByte" das korrekte erste Zeichen ?
4.) steht in Size der korrekte Wert drin ?

... es geht nur schrittweise ...

Ich hätte das Script-technisch nicht so gelöst (zu viele Funktionen, die etwas hin- und herreichen). Nichts-desto-weniger sehe ich aber erstmal noch keinen Fehler (außer, dass sich das sicher sehr schlecht debuggen läßt).
 
... dann fällt mir im Augenblick nur noch eins ein :
nimm doch mal für den String-Parameter in "DCI_GetStringParam" einen IN_OUT statt einem OUTPUT.
 
jop dachte ich auch schon aber daran liegt es leider nicht ^^

es kommt auch beim output richtig raus wie gesagt da wird es richtig übergeben. da ist der header auch korrekt und auch der inhalt. wenn ich dann die var kopiere wird der string header total verhunst.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... wenn du dich bei deiner Annahme auf das folgende beziehst :
Code: 
    IF DCI_Command.isOK THEN  
        DATA.PortID     := Var1;
        DATA.MaterialID := Var2;
        DATA.LocationID := Var3;
    END_IF;
... dann denk bitte hier an 3 Sachen :
1.) zu welchem Zeitpunkt siehst du Var3 ? (immer dran denken - du arbeitest mit TEMP's)
2.) ist zu dem Zeitpunkt, wo du Var3 (mit dem richtigen Inhalt) siehst auch "DCI_Command.isOK = true" ?
3.) wenn "DCI_Command.isOK = TRUE" dann wird das übertragen, was zu übertragen zur Verfügung gestellt wird. Es wird (zu dem Zeitpunkt) nichts daran geändert.

Zusätzlich hätte ich dann noch etwas :
- in "DCI_GetStringParam" ist s nicht initialisiert.
- in "DCI_GetStringParam" ist s 254 Zeichen groß - in der Folge willst du aber einen String mit 16 Zeichen verwenden. Da haut das dann schon mal mit der max.Size des String nicht mehr hin.

...
 
Ich hab mir das nun auch mal kurz angetan. Larry, das wird wohl so nichts.

1. Ich denke Kai86 ist Informatiker. Wenn dem so ist, ist ihm leider nicht zu helfen. Sorry Kai, aber das sind Erfahrungswerte aus vielen Jahren.
2. Die Stringverarbeitung in der S7-SCL ist nicht unproblematisch, aber sie funktioniert bei Beachtung der Angaben die Larry gemacht hat.
3. Die S7 ist kein Windows, also immer schön Piano alles streng nacheinander und fein zerlegt. Warum trennst du im String nicht alles jeweils durch ein Trennzeichen, dann kann man danach suchen den String zerlegen und das funktioniert.
4. Der Code sieht nett aus, ist sogar strukturiert und trotzdem blickt keine Sau durch (siehe Larrys Nachfragen). Das sollte dir mal zu denken geben, wer soll das mal warten? Klingt ja alles schön klug (seek, ID etc.) sagt aber eigentlich gar nichts!!!

PS: Kommentare im Code sind immer gut!!!
 
Ich versuchs ja nur auf das wesentliche zu beschränken.

Machen wir es ganz einfach.

Ich habe Irgendwo nen Datenblock "Data". Darin steht die MaterialID vom Typ String[16].
Warum wird der Header von Var3 (b0 = 16 und b1 = 5) nicht übernommen sondern ein neuer mit (b0 = 16 und b1 = 16) generiert??? der vorherige Code spielt hier keine Rolle mehr. Was ist hier noch falsch?
Code: 
FUNCTION DCI_HandleCommand:Void
VAR
    Var3 : STRING[16];
END_VAR

Var3 := 'AAAAA';
DATA.LocationID := Var3;

END_FUNCTION
 
Hallo,
deine "benutzte Länge" kommt ja von hier :
Code: 
    S_REF.s_act:=INT_TO_BYTE(size);
... aus der (beliebten) "DCI_GetStringParam" ...

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Yep, hab ich überlesen, sorry.

Aber einen hab ich noch:ROFLMAO:

Zitat Step7 Hilfe
Wird der Inhalt eines Strings vom Anwenderprogramm geändert, muss auch das Byte "Tatsächliche Länge" beschrieben bzw. aktualisiert werden, damit der String vom PG angezeigt werden kann.
Zum Vergrößern anklicken....

Das mit dem PG lass ich jetzt erstmal aussen vor. Vor dem Kopieren steht in dem DB irgendeine Soll und Istlänge. Vielleicht geht SCL ja nur hin und kopiert den nackten String ohne Soll und Istlänge.

Wenn alles nicht mehr hilft geh doch mal hin, und sieh Dir den AWL Code an, den SCL aus einer Stringzuweisung erzeugt. Vielleicht wird man dann schlauer.
 
Hallo kai86,

lege mal weitere neue Stringvariablen an und weise Var3 diesen Variablen zu:
Code: 
FUNCTION DCI_HandleCommand:Void
VAR
    Var3 : STRING[16];
    [COLOR="Red"]Testvar : STRING[16];[/COLOR]
END_VAR

[COLOR="red"]Testvar := '';[/COLOR]

Var3 := 'AAAAA';
DATA.LocationID := Var3;

[COLOR="red"]Testvar := Var3;
NeueExterneDBvar := Var3;[/COLOR]

END_FUNCTION
Wenn die Zuweisung nur bei DATA.LocationID nicht korrekt ist, dann beschreibt dein restliches Programm irgendwo die DATA.LocationID.
Wenn alle Zuweisungen nicht OK sind, dann wende Dich an die Siemens-Hotline, weil der Zuweisungsoperator := für STRING offensichtlich nicht korrekt funktioniert.
Welche Versionen von Step7 und SCL hast Du eigentlich genau?

Gruß
Harald
 
Nein ich habe alles rausgeworfen bis auf die zeile die ich als letztes gepostet habe und es geht trotzdem nicht.
 
@Grubba:
ich bin mir da nicht sicher, ob du so weiter kommst ...
In verschiedener meiner Projekte habe ich sehr viel SCL-Stringverarbeitung drin - ohne die hier zu sehenden Probleme. Allerdings bleiben die Strings auch i.d.R. in einer Funktion / Prozedur und die Ausgabe ist dann nur den Endwert, der z.B. in einen Global-Speicher zur Anzeige o.ä. geht.
Der String-Header wird nach meiner Erfahrung (wenn einmal richtig angelegt) sauber mit übergeben bzw. auch dann von Bearbeitungsfunktionen (z.B. CONCAT) richtig korrigiert. Auch das Arbeiten mit Strings mit unterschiedlicher Längen-Deklaration birgt (immer unter der Berücksichtigung der richtigen Initialisierung) keine Probleme ...

Gruß
LL
 
@Larry

Da magst Du wohl recht haben...

Habs auch gerade mal nachgebaut. Stringzuweisung im FC unter SCL funktioniert einwandfrei. Inklusive Ist und Maxlänge. Demnach ist diesmal nicht der Siemens schuld....
 
Also folgende Feststellung:

Wenn ich statt des DB Strings einen normalen Definiere stimmt die Länge nach dem Kopieren. Bei verwendung des DB s geht es nicht. kann das nicht mal schnell einer bei sich testen?
 
Zurück
Oben