TIA Profinet IO Statuswort CIA402 High und Low Byte vertauscht

Sona_the_witch

Level-2
Beiträge
13
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

ich möchte in einer S7-1511PN Steuerung das Statuswort eines Frequenzumrichters (Schneider Altivar) (CIA402) in Einzelbits "zerlegen", um so beispielsweise die Betriebsrückmeldung oder das Fehlerbit auszulesen.

Nun ist aber das Problem, dass beim Statuswort jeweils das High und Low Byte vertauscht eingelesen werden (wohl aufgrund des Little Endian Formats der 1500er). Wenn man das Statuswort mit dem Umrichter als Hex Zahl vergleicht, passt es, aber die Bitfolge wird bytemäßig vertauscht umgerechnet.

Daher wollte ich mal fragen, ob jemand von euch eine Funktion oder einen Baustein kennt, mit dem man solche Profinet IO Eingangswords wieder "entdrehen" kann?
 
Daher wollte ich mal fragen, ob jemand von euch eine Funktion oder einen Baustein kennt, mit dem man solche Profinet IO Eingangswords wieder "entdrehen" kann?
Ich würde mal in der Hardwarekonfig direkt an dem Teilnehmer prüfen, ob du das Übertragungsformat von Intel auf Motorola umstellen kannst ( oder in der Geräteparametrierung selbst ). Viele Geräte können das und dies wäre der sauberste Weg.

Hier mal ein Beispiel eines Beckhoff EK9300 Kopplers. Ist zwar in Step7 Classic aber in TIA sieht es ähnlich aus:
1726490480670.png
 
Falls es gar nicht anders geht, wäre der Befehl "SWAP" für dich interessant:
Siemens Webseite: SWAP: Anordnung ändern (S7-1200, S7-1500)

Beispiel​

Das folgende Beispiel zeigt die Funktionsweise der Anweisung:

SCL
"Tag_Result" := SWAP("Tag_Value");

Das Ergebnis der Anweisung wird als Funktionswert zurückgeliefert.
Die folgende Tabelle zeigt die Funktionsweise der Anweisung anhand konkreter Operandenwerte:

OperandWert
Tag_Value0000 1111 0101 0101
Tag_Result0101 0101 0000 1111


Geht aber nur für 1200/1500ér. Bei 300/400ér ROL 8x oder die AWL Variante "TAW".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Leg doch einfach eine Struktur von 16 Bool über das Word oder kopiere das Eingangsword auf die Struktur. Noch besser: erstelle einen Datentyp mit der Bitstruktur des FU-Statuswortes und deklariere direkt die Eingangsadresse als dieser Datentyp. Dann brauchst du keine Bytes tauschen.
Die Struktur darf natürlich kein faules Array [0..15] of Bool sein, weil dann scheint es so, als wären die Bytes vertauscht, weil in einem Bool-Array das niederwertigste Bit im ersten Byte liegt, in einem Word von Profinet aber im zweiten Byte.
 
Falls es gar nicht anders geht, wäre der Befehl "SWAP" für dich interessant:
Siemens Webseite: SWAP: Anordnung ändern (S7-1200, S7-1500)

Beispiel​

Das folgende Beispiel zeigt die Funktionsweise der Anweisung:

SCL
"Tag_Result" := SWAP("Tag_Value");

Das Ergebnis der Anweisung wird als Funktionswert zurückgeliefert.
Die folgende Tabelle zeigt die Funktionsweise der Anweisung anhand konkreter Operandenwerte:

OperandWert
Tag_Value0000 1111 0101 0101
Tag_Result0101 0101 0000 1111


Geht aber nur für 1200/1500ér. Bei 300/400ér ROL 8x oder die AWL Variante "TAW".

Vielen Dank! Das klärt bereits meine Frage, habe es auch getestet und nun wird es richtig eingelesen.

Ich würde mal in der Hardwarekonfig direkt an dem Teilnehmer prüfen, ob du das Übertragungsformat von Intel auf Motorola umstellen kannst ( oder in der Geräteparametrierung selbst ). Viele Geräte können das und dies wäre der sauberste Weg.

Hier mal ein Beispiel eines Beckhoff EK9300 Kopplers. Ist zwar in Step7 Classic aber in TIA sieht es ähnlich aus:
Anhang anzeigen 81348

Dazu habe ich jetzt bei mir in der Hardwarekonfiguration nichts gefunden...wo befindet sich die Einstellung denn bei solchen Geräten normalerweise in TIA?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Erstell doch einen Datentyp aus 16 bit die von der Benamung her zu dem passen wie die Bits ankommen, dann brauchst du nichts vertauschen und kannst auch symbolisch auf die Daten zugreifen.
 
Erstell doch einen Datentyp aus 16 bit die von der Benamung her zu dem passen wie die Bits ankommen, dann brauchst du nichts vertauschen und kannst auch symbolisch auf die Daten zugreifen.
Und was macht er mit Soll- und Istwerten ( er hat ja einen Umrichter ). Dann lieber einheitlich alles drehen oder ggf. auf Motorola umstellen insofern möglich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und was macht er mit Soll- und Istwerten ( er hat ja einen Umrichter ). Dann lieber einheitlich alles drehen oder ggf. auf Motorola umstellen insofern möglich.
Ich behaupte mal, wenn er die Soll und Istwerte als Word anspricht, dann muss er auch keine Bytes tauschen. Ich habe noch nie gehört, dass alle S7-1500-Anwender bei FU an Profinet Bytes tauschen müssen.
Und bei der Bit-Struktur (besser Datentyp, wie in #6 und #9 empfohlen) von Status- und Befehlsword muss man so und so nicht tauschen, es sei denn, man deklariert die Struktur falsch/vertauscht.
 
Und was macht er mit Soll- und Istwerten ( er hat ja einen Umrichter ). Dann lieber einheitlich alles drehen oder ggf. auf Motorola umstellen insofern möglich.
Also die Option mit dem Umstellen auf Motorola gibt es bei dem Frequenzumrichter (Schneider ATV630) tatsächlich nicht. Bin mittlerweile selber auch eher bei dem Ansatz, das ganze als PLC Datentyp zu deklarieren und dann einfach so von der Struktur her anzulegen, dass es passt. Ist für Programmierer, die in Zukunft was an der SPS machen müssen so denke ich auch am wenigsten verwirrend 🤭

Ich behaupte mal, wenn er die Soll und Istwerte als Word anspricht, dann muss er auch keine Bytes tauschen. Ich habe noch nie gehört, dass alle S7-1500-Anwender bei FU an Profinet Bytes tauschen müssen.
Und bei der Bit-Struktur (besser Datentyp, wie in #6 und #9 empfohlen) von Status- und Befehlsword muss man so und so nicht tauschen, es sei denn, man deklariert die Struktur falsch/vertauscht.
Soll- und Istwert passen auch, da wir die einfach als Hex-Zahl einlesen und beschreiben (in Hexadezimal stimmt das was in der SPS ankommt genau mit dem, was auf dem FU im Status steht, überein). Nur liest die SPS einzelne Bits aus einem Word anders ein als der FU. Das hat mir auch ein Mitarbeiter von Schneider so bestätigt als wir es gemeinsam angeschaut haben (hat sich bei deren Testaufbau in der Firma genau so verhalten). Es sei denn alle Beteiligten machen dabei grundsätzlich etwas falsch.
 
Erstell doch einen Datentyp aus 16 bit die von der Benamung her zu dem passen wie die Bits ankommen, dann brauchst du nichts vertauschen und kannst auch symbolisch auf die Daten zugreifen.
Dann doch den Datentyp und den dann auf die Startadresse des Umrichters, oder einen Kompletten Datentyp für das gesamte Telegram.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Soll- und Istwert passen auch, da wir die einfach als Hex-Zahl einlesen und beschreiben (in Hexadezimal stimmt das was in der SPS ankommt genau mit dem, was auf dem FU im Status steht, überein).
"als Hex-Zahl einlesen" ist ein falscher irreführender Ausdruck. Sicher liest du den Wert eines 16-Bit-WORD, und den Wert des WORD kannst du dann in hexadezimaler Schreibweise anschauen (z.B. 16#3132) oder dezimal +12594 oder als ASCII-Zeichenfolge '12'. Es ist aber immer der gleiche Wert.
Weil das 16-Bit-Word ein Mehrbyte-Wert ist, kommt es bei der Interpretation auf die Byte-Reihenfolge (Indianness) der Byte-Übertragung drauf an. Bei Übertragung per PROFINET IO ist die Byte-Reihenfolge "Network Byte Order" genormt, da kann nicht irgendein FU eine andere Reihenfolge verwenden. Der Prozessor im Gerät kann aber eine beliebige Byte-Reihenfolge verwenden und muss das beim Kopieren der Werte zwischen Programmspeicher und PROFINET IO Telegrammen beachten (im PROFINET-Treiber). Für das Anwenderprogramm sollte es daher nicht nötig sein, zusätzlich nochmal Bytes zu tauschen, wenn man ein PROFINET-WORD als WORD anspricht.

Nur liest die SPS einzelne Bits aus einem Word anders ein als der FU.
Welche Bits in einem Word laut Dokumentation des FU im H-Byte oder im L-Byte des FU-Statuswort liegen, kann in PROFINET-"Network Byte Order" oder in Prozessor-Byteorder gemeint sein, und eventuell auch tatsächlich falsch sein. Für das Anwenderprogramm in der S7-1500 braucht man aber zum Ansprechen der Bits im Statuswort die Bytes nicht tauschen, sondern einfach nur die Bit-Struktur des Statuswort so deklarieren, wie es im Anwenderprogramm ankommt. Weil man die Deklaration meist an mehreren Stellen braucht, deklariert man die Struktur zweckmäßigerweise als Datentyp (UDT) und braucht sie dann nur an einer Stelle detailliert deklarieren.
 
Zurück
Oben