TIA HMI - Bitmeldungen

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi zusammen, ich habe ne Frage, auf die ich von Kollegen nur als Antwort bekomme, dass ich es einfach so akzeptieren muss.
Aber meine Neugier bringt mich förmlich um.

Wenn ich im TIA-Portal in einem FB mit dem Befehl "AT" in der Bausteinschnittstelle ein WORD aus einem Array of 16 Bits erzeuge und dieses WORD im HMI als HMI-Meldung nutze, macht es den Anschein, als würden irgendwo High- und Lowbyte verdreht werden. Über ROL (8Bits) ist das Problem schnell behoben, das ist mir klar.

Aber mich würde einfach interessieren, an welcher Stelle der Kommunikation dieses Verdrehen stattfindet.


Liebe Grüße
Silas

 

[Tschoke]

Das verdrehen findet nicht bei der Kommunikation statt.
Deine SPS arbeitet nach dem Big-Endian Prinzip.
Und dein Panel bzw. Windows nach dem Little-Endian.
Little und Big-Endian beschreiben in welcher Reihenfolge die Bytes gespeichert werden.
Bei einem Word z.B. gibt es zwei verschiedene Möglichkeiten.
Das höherwertige Byte zuerst oder das niederwertige Byte zuerst.

Ich weiß aber nicht warum die SPSen Big-Endian benutzen.
Hat man das einfach festgelegt oder gibt es einen Grund dafür?

 

[S.Schleich]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Tschoke

Vielen Vielen Dank !!!

 

[circlehook]

@Tschoke Gibt es dazu auch eine Quelle?

Das Verdrehen kommt durch die AT Überlagerung.

Dabei wird in den optimierten Bausteinen auf Words wie folgt zugegriffen:
Byte 1 Bit 0 | Byte 1 Bit 1 | Byte 1 Bit 2 | Byte 1 Bit 3 | Byte 1 Bit 4 | Byte 1 Bit 5 | Byte 1 Bit 6 | Byte 1 Bit 7
Byte 0 Bit 0 | Byte 0 Bit 1 | Byte 0 Bit 2 | Byte 0 Bit 3 | Byte 0 Bit 4 | Byte 0 Bit 5 | Byte 0 Bit 6 | Byte 0 Bit 7

Dein Array ist aber von 0 bis 15 durchlaufend.

Daher kommt dein Versatz, da eben der Speicher direkt überlagert ist und die Strukur eben nicht passt.

Wenn du mit Scatter/Gather arbeitest, hast du das Verhalten nicht.

Hier der Auszug aus dem Programmier-Guideline von Siemens.


Soweit mein Wissensstand.

 

[S.Schleich]

@Tschoke Gibt es dazu auch eine Quelle?

Das Verdrehen kommt durch die AT Überlagerung.

Dabei wird in den optimierten Bausteinen auf Words wie folgt zugegriffen:
Byte 1 Bit 0 | Byte 1 Bit 1 | Byte 1 Bit 2 | Byte 1 Bit 3 | Byte 1 Bit 4 | Byte 1 Bit 5 | Byte 1 Bit 6 | Byte 1 Bit 7
Byte 0 Bit 0 | Byte 0 Bit 1 | Byte 0 Bit 2 | Byte 0 Bit 3 | Byte 0 Bit 4 | Byte 0 Bit 5 | Byte 0 Bit 6 | Byte 0 Bit 7

Dein Array ist aber von 0 bis 15 durchlaufend.

Daher kommt dein Versatz, da eben der Speicher direkt überlagert ist und die Strukur eben nicht passt.

Danke dafür, so richtig verstehen tue ich es nicht muss ich so verstehen, dass die SPS ja byteweise liest und das array nicht nach Bytes getrennt ist?

An "Gather" habe ich auch gedacht, aber habe eine 1500er CPU unter V2.1, daher habe ich die Möglichkeit nicht.

 

[van]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Problem mit der Byte Reihenfolge bei Bitzugriffen zwischen HMI und PLC gibt es bei Siemens schon seit Jahrzehnten … schon lange vor TIA …

 

[circlehook]

Was soll es zwischen SPS und HMI für ein Problem geben.
Einfach in der Variablenansicht nachschauen, wie das Array per AT das Word überlagert.
Array[0] ist dann einfach nicht Bit0 im Word.

 

[S.Schleich]

Was soll es zwischen SPS und HMI für ein Problem geben.
Einfach in der Variablenansicht nachschauen, wie das Array per AT das Word überlagert.
Array[0] ist dann einfach nicht Bit0 im Word.

Anhang anzeigen 70505

Danke für die Lösung. NICHT.
Wie gesagt, ich erkenne das Problem und habe ja auch Lösungen.
Ich wollte nur versuchen zu verstehen, warum bzw wie… dass es so ist wie es ist, die Antwort spratzt mir schon aus den Ohren

 

[circlehook]

Zuviel Werbung?
-> Hier kostenlos registrieren

Immer der gleiche Kindergarten hier, jeder ist sofort beleidigt und zickt rum.

Meine Antwort war nicht auf dich bezogen, sondern auf die Aussagen der anderen, das es ein Thema zwischen SPS und HMI sei.

Die Bits sind im Speicher anders nummeriert als im Datentyp Word (LSB / MSB).

 

[DeltaMikeAir]

Immer der gleiche Kindergarten hier, jeder ist sofort beleidigt und zickt rum.

Kannst du mal ein anderes Beispiel geben aus den letzten 14 Tagen wo einer beleidigt ist und/oder rum zickt?

 

[circlehook]

Kannst du mal ein anderes Beispiel geben aus den letzten 14 Tagen wo einer beleidigt ist oder um zickt?

Entschuldigt die Pauschalisierung.
War gerade nur etwas genervt.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

mich würde einfach interessieren, an welcher Stelle der Kommunikation dieses Verdrehen stattfindet.

Wie schon Tschoke in Beitrag #2 schrieb: Das verdrehen findet nicht bei der Kommunikation statt.

In einem ARRAY (of "Irgendwas") liegen die Elemente aufsteigend im Speicher. Bei einem Array of Bool liegt daher logischerweise das erste (niedrigste) Bit im vom Array belegten Speicher im ersten Byte das Bit.0
In einem WORD liegt das niedrigste Bit.0 im zweiten Byte des Words, weil S7-CPU Mehrbyte-Datentypen standardmässig im Big-Endian speichern - zuerst kommt das Byte mit den höherwertigen Bits und danach kommt das zweite Byte mit den niederwertigen Bits. Wenn man nun ein Word und ein Bool-Array im Speicher ab der selben Anfangsadresse übereinanderlegt (per AT), dann liegt das niederwertigste Bit des Words nicht über dem ersten Bit des Arrays. So einfach ist das. Es hat also gar nichts mit Kommunikation zu tun, sondern nur damit, wie Words im Speicher abgelegt werden (Endianness).

Historisch gesehen musste man bei früheren SPS-Baureihen bei der Kommunikation auf Performance achten, daher holt das HMI die vielen vielen Meldebits nicht jedes Bit einzeln aus der SPS, sondern Wordweise, weil die SPS das früher am performantesten konnten. (Heute macht man das wegen Kompatibilität weiterhin so.) Daher kommt es, das für die HMI-Kommunikation die Bytes in den Words nicht extra (nur für "Schönheit") getauscht werden, sondern kurzerhand so genommen werden, wie sie im Speicher liegen, und man bemerkt die "merkwürdigen" Adressprünge der Meldungs-Triggerbits, wenn man sich die Bitadressen anschaut. Man kann heutzutage im HMI die Bit-Meldungen zwar auch nach streng aufsteigenden Adressen projektieren (also quasi die Bytes nachträglich tauschen) - da das aber nur Kosmetik ist, die auch noch zusätzliche Arbeit macht, macht das kaum ein Programmierer.

Harald

 

[S.Schleich]

Wie schon Tschoke in Beitrag #2 schrieb: Das verdrehen findet nicht bei der Kommunikation statt.

In einem ARRAY (of "Irgendwas") liegen die Elemente aufsteigend im Speicher. Bei einem Array of Bool liegt daher logischerweise das erste (niedrigste) Bit im vom Array belegten Speicher im ersten Byte das Bit.0
In einem WORD liegt das niedrigste Bit.0 im zweiten Byte des Words, weil S7-CPU Mehrbyte-Datentypen standardmässig im Big-Endian speichern - zuerst kommt das Byte mit den höherwertigen Bits und danach kommt das zweite Byte mit den niederwertigen Bits. Wenn man nun ein Word und ein Bool-Array im Speicher ab der selben Anfangsadresse übereinanderlegt (per AT), dann liegt das niederwertigste Bit des Words nicht über dem ersten Bit des Arrays. So einfach ist das. Es hat also gar nichts mit Kommunikation zu tun, sondern nur damit, wie Words im Speicher abgelegt werden (Endianness).

Historisch gesehen musste man bei früheren SPS-Baureihen bei der Kommunikation auf Performance achten, daher holt das HMI die vielen vielen Meldebits nicht jedes Bit einzeln aus der SPS, sondern Wordweise, weil die SPS das früher am performantesten konnten. (Heute macht man das wegen Kompatibilität weiterhin so.) Daher kommt es, das für die HMI-Kommunikation die Bytes in den Words nicht extra (nur für "Schönheit") getauscht werden, sondern kurzerhand so genommen werden, wie sie im Speicher liegen, und man bemerkt die "merkwürdigen" Adressprünge der Meldungs-Triggerbits, wenn man sich die Bitadressen anschaut. Man kann heutzutage im HMI die Bit-Meldungen zwar auch nach streng aufsteigenden Adressen projektieren (also quasi die Bytes nachträglich tauschen) - da das aber nur Kosmetik ist, die auch noch zusätzliche Arbeit macht, macht das kaum ein Programmierer.

Harald

Danke !

 

[Cal_TDI]

Der ganze Ursprung liegt halt in der Prozessor Architektur der älteren SPS Genartionen (Vor S7-1500) und dem Unterschied der Arbeitsweise dieser Prozessoren. Heute läuft alles mehr oder minder auf der gleichen Plattform ab, wird aber wegen der Kompbilität aka "Wir machen das schon immer so!" von Siemens mit der Trennung von Big und Little Endian beibehalten.

 

[Peter Wahlen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe bis jetzt nur mit dem Bitmeldeverfahren gearbeitet (verschiedene Gründe: 1200er SPS, kein Siemens Panel, gleicher Programmaufbau bei 1200/1500,...)

Mir ist klar, dass in den SPS (300/400/1200/1500 <> 1200/1500 optimiert) die Byteablagenart (Big / Low Endian) unterschiedlich ist. Ich verstehe jedoch nicht, warum meine Bitmeldungen am Panel, welche ich bei all diesen Steuerungen (300/400 und 1200/1500 optimiert) auf die gleiche Art verwende, bei all diesen SPSen funktioniert, also dass die Meldungsnummer am Panel richtig angezeigt wird.
Der einzige Unterschied: bei 300 kopiere ich die 112Bit Struktur zu einem Word-Array nicht in einem SCL NW sondern in einem SCL Baustein.

Ich hab das mal in einer pdf (Bitmeldungen.pdf) zusammengefasst:

Ergebnis: Man muss, wenn man keine Berechnungen des Triggerbits machen will, mit der Bit-Struktur arbeiten.