TIA TIA V17 "Peripheriezugriff stimmt nicht mit der Kanalstruktur der F-Peripherie überein"

[derkleinefrank]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich darf nach wenig Erfahrung mit S7 Classic nun eine Anlage mit TIA V17 Save programmierren.
Dazu muss ich eine Lastmesseinrichtung von BROSA, gekoppelt über Profinet/Profisave im F-Teil der Steuerung auswerten.
Die Lastmesseinrichtung sendet 16 Bytes:
0-1: High-Bytes Messwert
2-3: Low-Bytes Messwert
(...)

In der Hardware habe ich die GSD-Datei des Sensors eingebunden und die folgenden Adressen eingestellt:
Safety E/A: E-Adresse: 700..715
A-Adresse: 700..703
In den PLC-Variablen habe ich die Variable 76PS01_SW11_X als DINT mit der Adresse %ED700 definiert.
Will ich nun im Sicherheitsprogramm auf diese Variable zugreifen, erhalte ich die Meldung "Peripheriezugriff '76PS01_SW11_X' stimmt nicht mit der Kanalstruktur der F-Peripherie überein".
Definiere ich die Variable in der PLC-Variablentebelle als INT mit der Adresse %EW700, kommt kein Fehler. Scheint also damit zusammenzuhängen, das ich DINT zwar in der PLC-Variablentabelle mit Peripheriezugriff definieren, im Sicherheitsprogramm aber nicht damit arbeiten kann?

Wenn das tatsächlich so ist und ich nicht nur irgendeinen blöden Fehler mache, wie bekomme ich dann aus den vier Low- und High-Bytes, in denen die Lastmessung den Istwert sendet, einen richtigen Wert als DINT?

Gibt da zwar den Baustein "Convert", aber der wandelt nur einen INT-Wert nach DINT, etwas anderes habe ich nicht gefunden.

Bin ich da ganz falsch unterwegs? Bitte um Hilfe

dkf

 

[Glasesba]

Hast du mal versucht die ganze Nutzdatenstruktur als F-PLC-Datentyp anzulegen und dann diesen Datentyp in der Variablentabelle als ganzes über den Datenbereich zu legen anstelle einzelner Variablen?

 

[FBieneke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also an einfachsten wäre es die 2 INT zu lesen beide zu Wandeln vom INT zu DINT den mit den HighByte zu Schieben mit SHR oder SHL und die 2 werte dann zu Addieren dann hast Du deine Messwerte als DINT

 

[derkleinefrank]

Siemens hat diese Lösung vorgeschlagen:



Klappt aber nur bis zur "magischen" Grenze von 32767...

 

[PN/DP]

Meiner Meinung nach ist das schon in der GSD-Datei falsch deklariert. Die zwei Low-Bytes eines DINT sind kein INT16, sondern ein WORD16 (oder notfalls UINT16). Man kann zwar das 16-Bit-Bitmuster der Low-Bytes für die Übertragung kurzerhand als INT16 deklarieren, kann den angeblichen INT aber nicht einfach zu DINT wandeln. Die 16 hinzukommenden höherwertigen Bits müssen auf jeden Fall alle 0 sein.
Die 4 Bytes müssen als DINT deklariert werden oder mit einem DINT überlagert werden (AT), oder man muß die 2 High-Bytes um 16 Bits links schieben, und die 2 Low-Bytes als WORD zu einem DWORD erweitern, und dann die beiden DWORD ver-odern und in einen DINT speichern. Ob und wie das in Safety geht, weiß ich allerdings nicht.

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hatte eben mal kurz in einem Testprojekt rumgespielt. Du kannst in der Safety weder zwei WORDs zu einem DInt machen noch überhaupt mit DWORD arbeiten. Ich sehe als Möglichkeit nur, das der Hersteller seine GSDML anpasst und die Daten direkt als DInt deklariert...

 

[derkleinefrank]

Ist tatsächlich ein Fass ohne Boden...

Habe aber Glück:
Der Lastmess-Sensor hat eine Nennlast von 120kN, in der Konfiguration definiere ich den Messwert als DINT mit einer Nachkommastelle, habe also tatsächlich einen Messwert von max. 1200. Der wird im Low-"Integer16" an die Steuerung gesendet und kann einfach mit CONVERT gewandelt werden.
Würde der Sensor REAL-Werte senden (wäre konfigurierbar, ist für die Safety-Betrachtung aber unbrauchbar) oder Werte > 32767, wäre ich ratlos...

 

[PN/DP]

Darf man in einer Safety-Schaltung einfach behaupten: "die für mich ungünstigen Werte kommen niemals vor" ??

 

[FBieneke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo also die Lösung von Siemens sollte so in der Safety funktionieren da mit dem SHL oder auch SHR nur ein Word verschoben werden kann. Du musst das High-Byte halt auf die oberen 16 Bit bekommen so müsste das auch gehen.

 

[PN/DP]

Die Siemens-Lösung von #4 kann nicht funktionieren, weil sie gar nicht SHL und SHR verwendet, sondern CONV und MUL und ADD, was für die Low-Bytes aber nicht funktioniert.

 

[FBieneke]

Die Siemens-Lösung von #4 kann nicht funktionieren, weil sie gar nicht SHL und SHR verwendet, sondern CONV und MUL und ADD, was für die Low-Bytes aber nicht funktioniert.

Doch müsste funktionieren den das Higbyte wird ja von einem INT in ein DINT gewandelt (max 32767) dann wird der DINT mit 65536 Multipliziert (SHL) damit dieser wert auf das Höhere Byte gesetzt wird. im Anschluss wird das Low Byte gewandelt von INT TO DINT (Convert) im Anschluss wird das Hig-Byte mit dem Low Byte Addiert. (ADD) warum solte das so nicht funktionieren?

 

[Windoze]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo also die Lösung von Siemens sollte so in der Safety funktionieren da mit dem SHL oder auch SHR nur ein Word verschoben werden kann. Du musst das High-Byte halt auf die oberen 16 Bit bekommen so müsste das auch gehen.

Du kannst zwar ein WORD mit SHL / SHR verschieben, aber bekommst es dann nicht zu einem DInt. Und DWORD gibt es in der Safety nicht!

 

[Windoze]

Doch müsste funktionieren den das Higbyte wird ja von einem INT in ein DINT gewandelt (max 32767) dann wird der DINT mit 65536 Multipliziert (SHL) damit dieser wert auf das Höhere Byte gesetzt wird. im Anschluss wird das Low Byte gewandelt von INT TO DINT (Convert) im Anschluss wird das Hig-Byte mit dem Low Byte Addiert. (ADD) warum solte das so nicht funktionieren?

Weil das Low-Word als Int mit Vorzeichen behandelt wird. Wenn das Bit 15 sitzt wird das Ergebnis Negativ...

 

[derkleinefrank]

Habe es abseits aller Theorie jetzt mal simuliert:
Bei Werten bis 32767 für %ED4000 werden korrekte Werte geliefert, bei Werten von 32768 bis 65535 Schrott, danach wieder korrekte Werte.
Wenn ich irgendwann Urlaub (und Lust) habe, versuche ich das zu verstehen, ob das dann gelingt, bevor ich einen spitzen Gegenstand in den Bildschirm stecke, sei mal dahingestellt. Siemens ist ziemlich schräg...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Siemens ist ziemlich schräg...

Das hat nichts mit Siemens zu tun, sondern liegt einfach an der genormten Codierung von vorzeichenbehafteten Ganzzahlen. Das Low-Word enthält kein Vorzeichen, sondern quasi nur einen Teil der "Mantisse". Deshalb darf man das Low-Word auch nicht so behandeln, als würde es ein Vorzeichen beinhalten. (Und da ist noch nichtmal berücksichtigt, daß negative Ganzzahlen als Zweierkomplement codiert werden und gar kein einzelnes Vorzeichenbit haben.)

 

[FBieneke]

Hallo zusammen ich habe das aus#4 mal bei mir in eine PLC gehackt. und das sieht nach meiner meinung garnicht mal so schlecht aus da ja die Eingangsbytes auch als INT kommen sollten die Themen zum Vorzeichen kein Thema sein denn auch das wird natürlich so Übertragen.



Aber Du hattest Doch im August schon mal das Selbe Problem und hast es Doch gelöst mit der Umstellung auf ein Wert von DINT damit sollte das Thema duch erledigt sein oder seh da was Verkehrt.



Un da ist es ja auch ganz klar das der Eingangsbereich als DINT Übertragen werden kann. und auch das High-Byte und das Low-Byte dann so auf geschlüsselt werden wie es in der unteren Tabelle steht damit wird auch im Low-Byte kein Vorzeichen mit Übertragen da es sich ja immer noch um ein INT handelt. Somit sollte das auch funktionieren was Siemens angeboten hat oder sehe ich das echt so Verkehrt.

Anbei auch für alle der Wert aus der Tabelle 76,864t



Gruß Frank

 

[Windoze]

Dadurch, das das Low-Word als INT interpretiert wird, wird das oberste Bit des Low-Words als Vorzeichenbit interpretiert.
Schreibe in dein Low-Word einen Wert grösser 32767 (0x7fff) dann stimmt das ganze nicht mehr!

 

[FBieneke]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Windoze, ja das versteh ich aber der Wert wird ja aufgeteilt in Low und High Byte so das es zu der Gefahr des Überschreitens nicht führen wird. da beide Werte ja immer noch als INT 16 Übertragen werden wird der Wert in diese 2Byte aufgeteilt. als immer den Gesamten wert sehen, und wenn der Messert den INT 32767 Übersteigt so wird der High Wert angepasst. Darum ist das Vorzeichen in diesem Fall völlig uninteressant.

Außerdem müsstest Du 32768 eingeben.

 

[Windoze]

Nein er wird in WORTE aufgeteilt nicht in BYTES. und ich hatte ja geschrieben größer 32767

 

[FBieneke]

Sorry der Messwert wird in 2 INT16 aufgeteilt (Messwert :76,864t) Diser wird in die 2 Int Aufgeteilt nach der definition vom INT16



1 Frage:

Warum sollten also Negative Zahlen auf dem Low Byte kommen?

2. Frage:

wird sich der Sensorhersteller nicht an die Definition eines INT halten?

Das wäre das was ich mal Fragen würde. Und ich bin mir sicher es werden keine negtiven Zahlen oder Zahlen > 32767 als Low Byte übergeben.

Gruß