TIA und Step7 erzeugen unterschiedliche Array-Offsets?

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

FIXED in V12 für 300/400: TIA und Step7 erzeugen unterschiedliche Array-Offsets?

ich beschäftige mich gerade mit der automatischen Offset-Erstellung in S7 Structs dabei ist mir aufgefallen das TIA und Step7 andere Offsets erzeugen

Wenn ich einen ARRAY[1..2,1..4] of String[1] erstelle bekommt der Nachfolger in Step7 Lite 3 SP1 eine groessere Bitadresse als im TIA V11 SP5
in Step 7 wird der String auf Word-teilbare Größe erweitert, beim TIA nicht (bei 400er, 1200er)

array_string1 array[1..2,1..4] of string[1]

ist in Step7 32 Byte und im TIA nur 24 Bytes lang

Mir ist schon klar das es nicht per se falsch ist aber kann das nicht sehr leicht zu komischen Problemen fuehren?
was passiert z.B. wenn man ein Step7 Projekt konvertiert und dieses dann auf die SPS bringt - aber z.B. per BSEND + Anypointer
von einer bestimmten Stelle Daten überträgt?

und die 300/400 Kompatibel-Auswahl bei der Datablock Erzeugung bedeutet dann auch nur 98% Kompatibel - darum denke ich das es ein TIA-Fehler ist

Dieser Fehler wurde in TIA-V12 für die 300/400 korrigiert, die 1500 ist konform zum Step7 alignment

http://www.sps-forum.de/showthread....schiedliche-Array-Offsets?p=435694#post435694

 

[RobiHerb]

Ausrichtung

So wie ich das sehe, ist das Ganze eine STRUCT und die Ausrichtung der STRUCT legt der Compiler (wenn nicht ausdrücklich anders eingestellt! (Pragma pack()) frei fest.

Ob er aus einem Bool ein Bit oder ein Byte oder Word oder sonst etwas macht, steht dem Compiler frei. Wenn ich auf ein einzelnes Element der STRUCT zugreife, dann mit Namen des Elements und .Punkt Operator.

Wenn das bisher anders ging, ist das keine Garantie für die Zukunft und schon gar nicht guter Stil sondern Hacker Mentalität.

Übrigens ist damit auch Siemens früher (vor etwa 20 Jahren) flott auf die Nase gefallen, als sie in der Firmware ihrer Slot PLC davon ausgingen, dass ein Windows Handle eine bestimmte Ausrichtung hat und als dann Microsoft in Win NT
auf andere Handle umstieg, konnte Siemens die Firmware der Slot PLC teuerst nachbessern.

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lustige Antwort...

und die Ausrichtung der STRUCT legt der Compiler (wenn nicht ausdrücklich anders eingestellt! (Pragma pack()) frei fest.

jetzt nenne mir auch ganz schnell den Siemens-Standard aus dem du hier zitierst dann weiss ich wenigstens das es kein Blabla-ich-weiss-was-über-Compiler-Geschnatter ist
und wo diese Einstellung im TIA sein soll? Klar kennen die meisten Kompiler ein erzwungenes Alignment - aber TIA?

wir reden hier auch nicht von allgemeinen Zugriffsaligment sondern nur von einem einzige winzigen Fall der jetzt plötzlich anders ist
und zwar nur wenn du Strings mit ungerader Größe in Arrays verwendest - sonst in keiner Situation egal welche Typen/Verschachtelung/Tiefe

Aus welchem Grund denkst du für diese Situation nur im entferntesten allgemein C/C++/Konsorten-Alignmentregeln anwenden zu können???

noch dazu bin ich mir 100% Sicher das da einfach nur geschlampt wurde - alle komplexen Typen sind im Datenblock word-aligned - auch der String
nur nicht mehr in String-Arrays - d.h. entweder hat man beim String-Arrays diese Step7 Spezialität vergessen oder vergessen das Einzel-String Aligment auf Byte zu stellen
weil einmal String-Zugriff mit Byte-Alignment und einmal mit Word-Alignment macht keinen Sinn

 

[vollmi]

Wenn du dir 100% Sicher bist dass da geschlampt wurde, wieso fragst du dann hier noch? Nur Siemens kann dir sagen ob es ein Bug oder Feature ist. Denn Einfluss aufs Programm hat dieser Umstand ja nicht.

mfG René

 

[LowLevelMahn]

sagen wir 97,5% Sicher

gut sagen wir 97,5% sicher - primär auch nur wegen dem Umstand das einmal Byte- und einmal Word-Alignment benutzt wird, was noch eine SPS Spezialität sein könnte
und mit Siemens-Fehler-Melden habe ich Gefühlt schon Jahre verbracht, meine Hoffnung ist das es hier Auffällt und dann genau geklärt wird

Denn Einfluss aufs Programm hat dieser Umstand ja nicht

es zeigt mir auch eher wie gut die neue Software getestet wird - speziell was Siemens unter "Kompatibilität" versteht

ich frage mich nur ob hart kodierte Anypointer bei einem Import von Step7 nach TIA automatisch nachgezogen werden
oder ob dann einfach die Adressen/Daten falsch sind (falls irgendwo über dem Zugriff ein Array mit Strings ungerader Größe existiert) und
wie lange es dauert bis man nach einer Migration auf das Problem stösst - hab leider kein Step7 hier (nur Lite) sonst würde ich es testen

Was ist deine Meinung zu der Sache?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hehe, grade mal getestet. Wenn man einen so mit dem TIA erstellten Baustein versucht mit Step7 aus der SPS zu laden, lässt sich dieser nicht mehr öffnen.
Fehlermeldung "Compilerinformation. Ungültiger Parameter im Aufruf" und "Datenbaustein konnte nicht geöffnet werden".
Passt dann wohl nicht mehr mit der Step7 Datenhaltung zusammen.

 

[LowLevelMahn]

kannst du auch die Anypointer-Sache testen?

Passt dann wohl nicht mehr mit der Step7 Datenhaltung zusammen.

sollte das denn funktionieren?

und könntest du auch die Anypointer-Sache testen?

also einfach ein Step7 Projekt mit

DB1
davor BOOL
array_string1[1..2,1..4] of STRING[1]
danach BOOL

plus einen hartkodierten AnyPointer Zugriff auf "array_string1[2,1]" und "danach"

dann das Projekt nach TIA migrieren und schauen ob die Offsets noch passen?

mein Maximaldank wäre dir stets Gewiss

 

[IBFS]

Es gibt m.E. nur zwei Varianten, wie ein DB-Offset sich ergibt:

Variante 1 (TIA-DB-Optimiert): Gar kein "sichtbarer" Offset, weil symbolische Ablage in der SPS (nur 1200/1500)

Variante 2 (TIA/CLASSIC-Stile): Da wird immer zum nächsten vollen Wort gesprungen, wenn etwas folgt, was größer als ein Byte ist ODER wenn man ein neues STRUCT beginnt usw.

Alles anderes wäre PFUSCH - und selbst mit der ausgefeiltesten (an den Haaren herbeigezogenen) Erklärung nicht nachzuvollziehen.

So sehe ich das!


EDIT: Ein STRING[1] hat schon mal mind. DREI Byte!!! - --MAXLÄNGE- -AKT_LÄNGE- -DATENBYTE-- ... das ergibt DREI ... aufgerundet VIER .... Bei der TIA-Variante fehlt das aufrunden...

Frank

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

stimmt nicht ganz

Variante 1 (TIA-DB-Optimiert): Gar kein "sichtbarer" Offset, weil symbolische Ablage in der SPS (nur 1200/1500)

so funktioniert es auch

Variante 2 (TIA/CLASSIC-Stile): Da wird immer zum nächsten vollen Wort gesprungen, wenn etwas folgt, was größer als ein Byte ist ODER wenn man ein neues STRUCT beginnt usw.

irgendwie schon richtig - aber die Details sind doch anders, es gibt da Spezialfälle wie Bitarray, Multidimensionale usw.

Alles anderes wäre PFUSCH - und selbst mit der ausgefeiltesten (an den Haaren herbeigezogenen) Erklärung nicht nachzuvollziehen.

mir ist völlig klar wie es funktioniert - nur TIA macht einen winzigen kleinen Unterschied beim Datenalignement zu Step7 - Strings in Arrays werde nicht mehr Word-Aligned, aber ausserhalb von Arrays sind sie immer noch Word-Aligned
was ein wenig verwirrend ist und sich ausser mit "wir habens vergessen Einzubauen" schwer erklären lässt

und ich gehe davon aus das hartkodierte Anypointer in diesem Szenario bei einer Migration von Step7->TIA falsch werden, oder es passiert ein Wunder, oder Warnmeldung

 

[Thomas_v2.1]

sollte das denn funktionieren?

und könntest du auch die Anypointer-Sache testen?

also einfach ein Step7 Projekt mit

DB1
davor BOOL
array_string1[1..2,1..4] of STRING[1]
danach BOOL

plus einen hartkodierten AnyPointer Zugriff auf "array_string1[2,1]" und "danach"

dann das Projekt nach TIA migrieren und schauen ob die Offsets noch passen?

Auweia, das geht ja fast erwartungsgemäß voll in die Hose.

Ich habe zwei Migrationen vorgenommen. Einmal mit Operandenvorrang auf absolut, und ein anderes Mal mit Operandenvorrang auf symbolisch.

In beiden Fällen erfolgt der Zugriff nachher auf die falsche Adresse!

Also wenn vorher "DB1.danach" auf DBX34.0 lag, wird auch nach der Migration auf die Adresse geschrieben. Dort steht dann natürlich etwas ganz anderes.

Wenn man Glück hat ist der Datenbaustein zu kurz, dann kann das Programm nicht übersetzt werden.
Oder man hat Glück und das Bit liegt in einem Int/Word etc. dann gibt es beim Übersetzen zumindest eine Warnung.

Wenn dort irgendwelche anderen Bool-Variablen stehen, wird die Adresse mit dem neuen Symbol angepasst. Keine Warnmeldung, nichts.

 

[LowLevelMahn]

Als nach meiner Meinung - ist das ein sehr sehr schwerer Fehler weil er unentdeckt drauf wartet zu explodieren

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Auweia, das geht ja fast erwartungsgemäß voll in die Hose.

Ich habe zwei Migrationen vorgenommen. Einmal mit Operandenvorrang auf absolut, und ein anderes Mal mit Operandenvorrang auf symbolisch.

In beiden Fällen erfolgt der Zugriff nachher auf die falsche Adresse!

Also wenn vorher "DB1.danach" auf DBX34.0 lag, wird auch nach der Migration auf die Adresse geschrieben. Dort steht dann natürlich etwas ganz anderes.

Wenn man Glück hat ist der Datenbaustein zu kurz, dann kann das Programm nicht übersetzt werden.
Oder man hat Glück und das Bit liegt in einem Int/Word etc. dann gibt es beim Übersetzen zumindest eine Warnung.

Wenn dort irgendwelche anderen Bool-Variablen stehen, wird die Adresse mit dem neuen Symbol angepasst. Keine Warnmeldung, nichts.

MIR SCHWANT SCHLIMMES!

Also SOLCHE Fehler dürfen NICHT passieren.

Da gibt es für mich keinen Verhandlungsspielraum.

Dann kann man die Migration im TIA gleich weglassen wenn man auf so etwas aufpassen muss.

Frank

 

[Thomas_v2.1]

Wenn ich schon ein Projekt migriert hätte, würd ich wohl morgen erstmal einen Bürotag einplanen ;-)
Und wer weiß wo solche Fehler noch eingebaut wurden.

Da ist es ja fast sicherer die Migration über Quellen vorzunehmen, was natürlich nur funktioniert wenn man vorher voll symbolisch programmiert hat.

 

[LowLevelMahn]

Die Migration ist ja OK - aber die Offset-Berechnung ist eben "kaputt" gegangen - oder man sollte "Kompatibilität" besser definieren (mit Warnungen unterfüttern)

Das schlimme ist - ich habe fast schon erwartet das dieses "String wird auf Word-Alignment vergrößert" im TIA fehlt - weil die Jungs bestimmt eine echten String-Abstraktion eingebaut haben
und dabei die Basisklasse String => Array[2+Size] of Byte einfach Weg oder Vergessen-Designed wurde

Und ich erwarte noch viele solcher Fehler - mit den einfachsten Systemtest kommt man auf solche Fehler - und selbst die scheinen zu fehlen

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie gehen wir jetzt weiter vor - Es sollte vermieden werden das wieder nur einer sich mit dem Support rumschlägt: Wie wäre es mit einem Testprojekt + Testbeschreibung + Nicks von allen die das für wichtig
halten als eMail an Siemens - oder was in der Art?

 

[Thomas_v2.1]

Ich mache bei Siemens keine Fälle mehr auf, hab noch 5 offene Fälle zu Pcs7 V8.
Gibt ja noch mehrere Bugs in TIA. Den SCL Compilerfehler mit den Peripherieadressen find ich auch nicht ohne.

 

[Thomas_v2.1]

Vielleicht erstmal als Tip:
Wer ein Programm migriert hat in dem er Arrays of String mit ungeraden Stringlängen verwendet, sollte seine Programme überprüfen.

Kommt wahrscheinlich in der Realität nicht soo oft vor.

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht erstmal als Tip:
Wer ein Programm migriert hat in dem er Arrays of String mit ungeraden Stringlängen verwendet, sollte seine Programme überprüfen.
Kommt wahrscheinlich in der Realität nicht soo oft vor.

Wie stellt du dir denn das vor? So etwas funktioniert nur, wenn es eine offzielle Bugliste gibt, aus der man eine Checkliste erstellen könnte.

Man kann von keinem verlangen den kompletten Code von mehreren hundert FC/FB/DBs Stück für Stück durchzugehen.
Du als PCS7-Programmierer weißt doch wie groß Projekte werden können.

Wir reden hier nicht von Sample-Projekten mit je 10 FB/FC/DB.

Frank

 

[MSB]

Ich würde das Problem ein wenig "erweitern":
Es spielt nämlich (bei mir jedenfalls) überhaupt keine Rolle ob es ein Array of String ist, oder nicht.
Jede ungerade Char Anzahl des Strings führt unweigerlich zu dem Problem.
Siehe Bild ...

Mfg
Manuel

 

[IBFS]

Wieso fällt das denn jetzt erst auf, oder ist das neu mit einem SP hereingekommen?

Frank