TIA und Step7 erzeugen unterschiedliche Array-Offsets?

Zuviel Werbung?
-> Hier kostenlos registrieren
durch die händische Anpassung des Strings auf Länge 2
Dann muß bei der Migration nicht nur das urprüngliche Array auf Strings mit gerader Anzahl Zeichen händisch geändert werden, sondern auch alle FB/FC und deren Aufrufe, welche diese Strings als Parameter bekommen, müssen angepasst werden. Wenn da vorher z.B. STRING[11] übergeben wurden, dann wären die Aktualparameter nun plötzlich ein STRING[12] - die Symbolik geht kaputt ... (oder der Migrator behält die Symbolik, es wird aber ein längerer String übergeben?)

Nicht zu vergessen: Sobald die STRING[11] als STRING[12] deklariert werden, wird der DB-Editor da auch die Maximallänge mit 12 statt 11 initialisieren ... in all den Strings müßte durch zusätzliche Programmbefehle die Maximallänge auf 11 geschrieben werden, damit vorhandene Programmroutinen und Visu nicht unerwartet 1 Zeichen mehr nutzen/auswerten.

Harald
 
Ich oute mich mal als "Nichtsblicker", naja grob hab ich verstanden worums geht, aber nicht im Detail...

Zusammengefasst bedeutet das jetzt:

1. in V12 funktioniert alles soweit, ich bekomme aber eine Warnmeldung wenn ich ungerade Strings in Arrays verwende?
2. in V11 funktioniert der Move Befehl fehlerhaft, wenn ich ungerade Strings in Arrays verwende. Aber ich bekomme keine Warnmeldung?
3. Wenn ich ein Step7 5.x Programm mit ungeraden Strings in Arrays nach V11 konvertiere funktioniert u.U. das Programm fehlerhaft und es gibt keine Warnmeldung?
4. Wenn ich ein Step7 5.x Programm nach V12 konvertiere funktioniert das Programm u.U. fehlerhaft, aber es gibt eine Warnmeldung?

Zumindest wenn ich mal in die Verlegenheit komme, sowas zu machen, behalt ich mal im Hinterkopf, nach solchen Problemen Ausschau zu halten...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1. in V12 funktioniert alles soweit, ich bekomme aber eine Warnmeldung wenn ich ungerade Strings in Arrays verwende?

ja - wobei das nur eine Notlösung für ein vorher eingebauter Fehler ist - es macht keinen Sinn das der Kunde händisch dafür sorgt das die DBs immer schön 300/400 Konform sind
es wurde einfach ein winziger Teil vom Step7 verhalten nicht portiert

2. in V11 funktioniert der Move Befehl fehlerhaft, wenn ich ungerade Strings in Arrays verwende. Aber ich bekomme keine Warnmeldung?

Ungefähr so - aber eher können deine ganzen AnyPointer-Zugriffe die unterhalb dieses falsch Alignten Strings liegen falsch sein - mit 0 Möglichkeit dich zu warnen

3. Wenn ich ein Step7 5.x Programm mit ungeraden Strings in Arrays nach V11 konvertiere funktioniert u.U. das Programm fehlerhaft und es gibt keine Warnmeldung?

Ja

4. Wenn ich ein Step7 5.x Programm nach V12 konvertiere funktioniert das Programm u.U. fehlerhaft, aber es gibt eine Warnmeldung?

Das muss mal jemand testen

Das ägerliche daran - es ist einfach nur bei der Portierung des Step7 Alignments ein kleiner Teil (ich denke ein "If") vergessen worden - und dadurch gibt es diese ganzen unschönen Dingen überhaupt
aber anstatt es richtig zu korrigieren verschiebt Siemens die Lösung komplett auf den Kunden und schafft damit trotzdem keine 100% Lösung

Das diese Problem überhaupt existiert ist Ergebnis schlampiger Arbeit und fehlender Tests (egal ob manuell oder automatisch) und die Lösung zu diesem "neuen" Problem ist Flickschusterei mit entsprechender Ergebnisqualität
 
Zuletzt bearbeitet:
Ich vermute mal, wenn sie's in V12 geändert hätten, wäre die Kompatibilität V11<->V12 auf der Strecke geblieben... Und das war denen wichtiger als die Kompatibilität 5.x<->V12 ... Aber das kann man sehen wie man will...
 
Ich vermute mal, wenn sie's in V12 geändert hätten, wäre die Kompatibilität V11<->V12 auf der Strecke geblieben... Und das war denen wichtiger als die Kompatibilität 5.x<->V12 ... Aber das kann man sehen wie man will...

hab ich mir auch gedacht aber:

1. wenn das Projekt mit diesen Problemen von Step 5.x nach TIA V11 migiriert wurde ist das Problem schon da
-> hier könnte eine Warnmeldung helfen welche einen zwingt ungerade String um 1 zu vergrößern - damit ist aber wie User "PN/DP" schon festgestellt hat die Problematik das
der Inhalt des String plötzlich länger geworden ist (was bedeuten kann das plötzlich 1 Zeichen mehr in der Visu landet d.h. irgendwelche Längenprüfungen usw. verursachen sofort auch Änderung im Visu-Code)
und das gilt ja nur für Strings in Arrays - falls du irgendwo Strings umkopierst muessen diese jetzt auch um 1 Zeichen größer sein usw, usw, usw...

2. wenn man davon ausgeht das V12 das neue bessere TIA ist würde ich eher behaupten das eine 5.x -> V12 Migration so fehlerfrei wie möglich laufen sollte - was jetzt nicht der Fall ist
denn wie im 1. und 2. Fall ist eine händische Anpassung "möglicherweise" nötig

Ich glaube nicht wirklich das die Lösung gut durchdacht wurde - da hat irgendeiner die Aufgabe bekommen das Problem zu lösen und einfach was gemacht...
 
In der Liesmich zum Update 4 von TIA V11 SP2 gab's zu dem Thema auch schon nen Eintrag.

Da aber nur in Zusammenhang mit der S7-1200, und dort besteht das Problem auch noch generell bei Strings, und nicht wie hier bei Strings in Arrays.
Wobei es schon verwundert, einen Fehler als Verbesserung darzustellen. Wenn keine Strings ungerader Länge zuverlässig funktionieren, dürften diese eigentlich nicht angelegt werden.
Eigentlich die gleiche Vorgehensweise wie in diesem Fall bei der 300/400er. Der Fehler wird nicht behoben sondern nur auf den Anwender verschoben.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Aus dem Liesmich zum TIA Update für V11 SP2 unter Update 4:
Hantierung von String-Arrays in S7-1200
Bei CPUs der S7-1200-Baureihe wird dringend empfohlen, ausschließlich eine geradzahlige
Stringlänge in Arrays zu verwenden. Ansonsten können bei der Verwendung der Anweisung
"Move: Wert kopieren" Werte überschrieben werden.

Mfg
Manuel
 
Das sieht doch schon besser aus.

Vielleicht wurde es bei der 1200 nicht korrigiert weil da schon zu viele Geräte von auf dem Markt sind.

Wobei die 1200er noch ein paar andere Merkwürdigkeiten aufweist. Wenn man z.B. einen Taktimpuls mit dem TON erzeugen will, kann man nicht mehr wie bei der 300/400er einfach den Q negiert auf IN legen. Der Timer läuft dann zwar, aber danach kann man Q nicht mehr als Flanke abfragen. Mal gucken ob da bei V12 auch was korrigiert wurde.
 
Zurück
Oben