TIA TIA erzeugt nicht-Standard-Offsets in speziellen SDTs?

LowLevelMahn

Level-1
Beiträge
766
Reaktionspunkte
90
Zuviel Werbung?
-> Hier kostenlos registrieren
Hintergrund:
Ich arbeite an einem (C/C++) Tool mit dem man Absolut-Offsets zu DB-Schema-Beschreibungen erstellen kann
und stütze mich dabei auf Tests mit Step7, TIA V11/12/13, MHJ etc.
mein Tool basiert auf sehr viele manuellen und automatischen Tests und ich kenne das
(nicht unbedingt triviale) Padding und Alignment-Verhalten von Typen in DBs sehr genau

Jetzt habe ich aber doch mal eine komische Ausnahme entdeckt die ich mir aus
Kompiler/Codegenerierung/Hardware-Sicht nicht wirklich erklären kann

layout_difference.png


Software: V12 SP1 Update 4

Standard: Alle Struktur-Typen wie Struct, UDT, STDs werden in unoptimierten DBs auf 16Bit ausgerichtet (aligned)

Es gibt den SDT "IP_V4" der die Daten einer IPv4-Addresse vorhalten/speichern kann:

1. Es ist eine Struktur und SDT -> 16Bit Ausrichtung
2. Er besteht aus einem Array[1..4] of Byte und ist daher (mit/ohne Padding) genau 4 Bytes lang

ein frei stehender "IP_V4" Typ (siehe Bild) wird so in einem Datenblock eingebaut wie in 1. und 2. beschrieben
und das Verhalten gilt für alle Struct-Artigen die ich je (sehr viele) gesehen habe

Jetzt wird es komisch:

Wenn man jetzt aber den Typ "TCON_IP_RFC" verwendet - der einen "IP_V4" beinhaltet wird
dieser "IP_V4" nicht auf eine 16Bit- sondern auf 32Bit-Grenze ausgerichtet - und zwar nur in diesem SDT
wenn ich das gleiche "TCON_IP_RFC"-Layout mit einem normalen Struct bauen kommt wieder
das Standardausrichtung auf 16Bit

Ich hab keine Ahnung ob es den "TCON_IP_RFC" auch in Step7 Classic gibt wenn ja - kann den einer mal benutzten und das Layout zeigen?

Ideen dazu?

Kann mir irgendjemand erklären was der Sinn dahinter sein soll - oder hat Siemens einfach mal das Alignment für
"IP_V4" in dem "TCON_IP_RFC"-Typ unnötig hart von Hand eingestellt? Technisch ist der Unterschied aus Performance-Sicht
unbedeutend, verbraucht (manchmal) einfach ein wenig mehr Speicher, aber warum dann diese Spezialisierung für diese EINE kleine Kombination

Bitte keine Erklärungen wie Alignment/Padding funktioniert oder was Kompiler können/dürfen - das ist mir alles
zu (100+x)% klar - und ja symbolische DBs sind an dieser Stelle nicht komisch - aber um die geht es hier nicht :)
 
Ja, das ist seltsam, eine Erklärung hab ich auch nicht, Strings verhalten sich ja i.Ü. auch anders als bei der Classic.
Trotzdem solltest du das noch einmal in V13 testen, denn selbst die ist eher Beta, von V12 ganz zu schweigen…
Möglich also,dass das nur ein kurzzeitiges Feature war. ;)
 
Ich hätte auch vermutet, daß sich Siemens irgendwas "schickes" ausgedacht hat, um Speicheradressen in der Ansicht auszublenden, wie z.B. als "reserviert" gekennzeichnete Variablen/Adressen. Wen interessieren schon "reservierte" Bytes... die verwirren den normal-doofen 10-Minuten-Klick-Programmierer doch nur ;)

Harald
 
@ChristophD

Die Beschreibung zu TCON_IP_RFC wurde aber schon gelesen oder?
Dort steht doch das Byte 6 und 7 reserviert sind und daher die RemoteAdresse erst ab Byte 8 beginnt.

Das habe ich wohl übersehen (PDF?) - ist aber auch nicht wirklich sauber versteckte Reservierungen zu machen
aber so ist es dann eben und kein Feenstaub oder sonstiges als Erklärung nötig
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ich habe einfach im Informationssystem des TIA Portals bei Suche "TCON_IP_RFC" eingegebn und dann hat er die Beschreibung der SDT Struktur ausgespuckt ;)
wieso nicht sauber? Solche Reservierung sind gar nicht mal so unüblich für zukünftige Erweiterungen der Strukturen und Befehle.
 
wieso nicht sauber? Solche Reservierung sind gar nicht mal so unüblich für zukünftige Erweiterungen der Strukturen und Befehle.

zukünftige Erweiterungen mitten drinn - und nur 2 Bytes Platz? Bei anderen Typen nur am Ende, die meisten haben keine Reserve - ist einfach inhomogen
 
Zurück
Oben