TIA - i-DEVICE kein Datenaustausch (2024)

  • Steuerungssysteme
  • SIEMENS - PLC
  • ErstellerMFreiberger
  • Erstellt am2 Juni 2022

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #1
Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Zusammen,

nach langem rumprobieren, Anleitung lesen, Beispiele testen, usw. komme ich einfach nicht darauf, was ich falsch mache.
Jedenfall funktioniert meine i-Device-Kommunikation nicht, wie es eigentlich funktionieren sollte.

Umgebung:
IO-Controller: 1516F-3 PN/DP V2.9.2 (Konfiguriert: V2.8)
i-Device: 1515F-2 PN V2.8.3 (Konfiguriert: V2.8)
Entwicklungsumgebung: TIA V16 Upd 5

Aufbau:
Beim i-Device wird die X2 verwendet, beim IO-Controller die X1.

Dem i-Device wurde der entsprechende IO-Controller zugewiesen und die Transferbereiche wurden definiert:

Die Hardware wurde geladen und die Profinet-Namen vergeben:

Trotzdem funktioniert der Datenaustausch nicht:

Anscheinend mache ich grundsätzlich etwas falsch oder habe etwas vergessen. Allerdings meine ich mich an die Anleitung gehalten zu haben (PDF angehängt).

Hat Jemand eine Idee, woran es liegen kann?

VG

MFreiberger

Anhänge

  • 109478798_config_idevice_standard_DOCU_V20_de(4).pdf

    2,8 MB· Aufrufe: 14

Zuletzt bearbeitet:

ChristophD

Level-3

Power-User

Beiträge
6.305
Reaktionspunkte
1.641
  • 2 Juni 2022
  • #2

und was sagen die gerätediagnosen
an der i-device cpu scheint ja ein Fehler anzustehen?

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #3
Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ja, am i-Device steht ein Fehler an. Allerdings ist das "nur" ein Bereichslängenfehler in einer FC. Das liegt an einem Array, bei dem außerhalb der definierten Grenzen zugegriffen wird. Das wird noch behoben, hat aber eigentlich mit der i-Device-Kommunikation nichts zu tun.

Dazu kommen noch Profinetfehler, da der reale Hardwareausbau nicht vorhanden ist. Allerdings bezieht sich das auf die X1, über die die Steuerung als IO-Controller und nicht als i-Device arbeitet.

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

FAQ-Team

Power-User

Beiträge
23.244
Reaktionspunkte
7.245
  • 2 Juni 2022
  • #4

Die Eingangsdaten sind jeweils 0 - vermutlich ist die Profinet-IO-Kommunikation nicht aufgebaut.
Sind wirklich die projektierten Profinet-Namen an die CPUs zugewiesen?? Warum steht in den Dialogen "Gerätename ist unterschiedlich"?
Hast Du eine Topologie projektiert?

Harald

ChristophD

Level-3

Power-User

Beiträge
6.305
Reaktionspunkte
1.641
  • 2 Juni 2022
  • #5

geht die cpu nicht in stop beim bereichslängenfehler?

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #6
Zuviel Werbung?
-> Hier kostenlos registrieren

PN/DP schrieb:

Die Eingangsdaten sind jeweils 0 - vermutlich ist die Profinet-IO-Kommunikation nicht aufgebaut.
Sind wirklich die projektierten Profinet-Namen an die CPUs zugewiesen?? Warum steht in den Dialogen "Gerätename ist unterschiedlich"?
Hast Du eine Topologie projektiert?

Harald

"Gerätename ist unterschiedlich" steht aber nur an dem Gerät an, das gefunden wird, aber nicht zu dem ausgewählten Namen passt.

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #7

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

FAQ-Team

Power-User

Beiträge
23.244
Reaktionspunkte
7.245
  • 2 Juni 2022
  • #8

MFreiberger schrieb:

Allerdings bezieht sich das auf die X1, über die die Steuerung als IO-Controller und nicht als i-Device arbeitet.

In Deiner Gerätekonfig ist die Steuerung i-Device am X1
Was passiert wenn Du testweise die Kabel an X1 und X2 tauschst?

Harald

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #9
Zuviel Werbung?
-> Hier kostenlos registrieren

PN/DP schrieb:

In Deiner Gerätekonfig ist die Steuerung i-Device am X1

Harald

Nein.
In der Netzansicht ist die "rechte" Schnittstelle X1 und die "linke" Schnittstelle X2.
Also die i-Device-CPU ("RBG2_CPU") hängt mit der X2 am Subnetz "iDEVICE"; die IO-Controller-CPU ("GW_CPU") hängt mit der X1 am Subnetz "iDEVICE".

DeltaMikeAir

User des Jahres 2018; 2023

Power-User

Beiträge
23.816
Reaktionspunkte
8.239
  • 2 Juni 2022
  • #10

Unterstützt die X2 denn überhaupt das was du vorhast ( es ist ja keine vollwertige Profinet-Schnittstelle ):

Hier mal ein Auszug aus dem Handbuch der 1516 ( Seite 15 )
Dort steht das die X2 keine IO-Device-Rolle unterstützt.

ChristophD

Level-3

Power-User

Beiträge
6.305
Reaktionspunkte
1.641
  • 2 Juni 2022
  • #11

DeltaMikeAir schrieb:

Unterstützt die X2 denn überhaupt das was du vorhast ( es ist ja keine vollwertige Profinet-Schnittstelle ):

Hier mal ein Auszug aus dem Handbuch der 1516 ( Seite 15 )
Dort steht das die X2 keine IO-Device-Rolle unterstützt.
Anhang anzeigen 61457

Update V2.0.1 CPUs und V2.0.0 Displays

S7-1500 CPUs

  • Die PROFINET Schnittstelle X2 (ab CPU 1515 auf jeder CPU vorhanden) kann für PROFINET RT (Controller oder iDevice) genutzt werden.

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

FAQ-Team

Power-User

Beiträge
23.244
Reaktionspunkte
7.245
  • 2 Juni 2022
  • #12
Zuviel Werbung?
-> Hier kostenlos registrieren

MFreiberger schrieb:

Also die i-Device-CPU ("RBG2_CPU") hängt mit der X2 am Subnetz "iDEVICE"; die IO-Controller-CPU ("GW_CPU") hängt mit der X1 am Subnetz "iDEVICE".


MFreiberger schrieb:

Aufbau:
Beim i-Device wird die X1 verwendet, beim IO-Controller die X2.
Anhang anzeigen 61451

??? TIA - i-DEVICE kein Datenaustausch (17)

PN/DP schrieb:

Was passiert wenn Du testweise die Kabel an X1 und X2 tauschst?

Harald

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #13

MFreiberger schrieb:

Beim i-Device wird die X1 verwendet, beim IO-Controller die X2.

PN/DP schrieb:

Die Fragezeichen sind korrekt. Das hatte ich in der ersten Beschreibung tatsächlich durcheinander gewürfelt.
Hab es korrigiert.

Also:
i-Device: X2
IO-Controller: X1

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #14

kurzes Update:

bei einem neuen Projekt hat die i-Device-Kommunikation sofort funktioniert.

Dann habe ich geprüft, welche unterschiede ich zwischem dem "echten" und dem "Test"-Projekt habe.
Dabei hat sich ergeben, dass die erkennbaren Unterschiede im Transferbereich liegen.

Zunächst habe ich die F-Bereiche rausgeschmissen: kein Unterschied
Dann habe ich nur die E/A 3000 drin gelassen: kein Unterschied
Dann habe ich die E/A-Adresse auf 10 geändert: jetzt geht es!!!
Adresse zurück auf 3000 geändert: geht jetzt auch.

Ich vermute, dass es mit den F-Bereichen zu tun hat. Ich werde berichten.

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #15
Zuviel Werbung?
-> Hier kostenlos registrieren

Also, auch die F-Kommunikation funktioniert.

Was nicht gepasst hat, kann ich nicht mehr nachvollziehen.

Ich vermute Folgendes:
Die F-Bereiche waren ursprünglich als erste Transferbereiche projektiert. Ggf. passte die LADDR an den Bausteinen SENDDP und RCVDP nicht und daraufhin wurden die folgenden Transferbereiche auch nicht bearbeitet.

Bin erstmal froh, dass es läuft TIA - i-DEVICE kein Datenaustausch (19)

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

FAQ-Team

Power-User

Beiträge
23.244
Reaktionspunkte
7.245
  • 2 Juni 2022
  • #16

MFreiberger schrieb:

Dabei hat sich ergeben, dass die erkennbaren Unterschiede im Transferbereich liegen.

Zunächst habe ich die F-Bereiche rausgeschmissen: kein Unterschied
Dann habe ich nur die E/A 3000 drin gelassen: kein Unterschied
Dann habe ich die E/A-Adresse auf 10 geändert: jetzt geht es!!!
Adresse zurück auf 3000 geändert: geht jetzt auch.

Was für Unterschiede konntest Du da "erkennen"? Sah da was im neuen Test-Projekt anders aus als im problematischen Projekt?

Bei der nicht laufenden Kommunikation: Du hattest auch "Hardware komplett übersetzen" ausgeführt vor dem Laden in die CPUs?

Waren da eigentlich auf die i-Device-Kommunikation bezügliche Einträge in den CPU Diagnosepuffern?

MFreiberger schrieb:

Ich vermute Folgendes:
Die F-Bereiche waren ursprünglich als erste Transferbereiche projektiert. Ggf. passte die LADDR an den Bausteinen SENDDP und RCVDP nicht und daraufhin wurden die folgenden Transferbereiche auch nicht bearbeitet.

Hoffen wir mal, daß da nur die Projektierung irgendwie fehlerhaft übersetzt war. Nicht daß bei einem späteren Ausfall der F-Kommunikation zur Laufzeit die nachfolgenden Transferbereiche wieder nicht bearbeitet werden... das würde ich auf jeden Fall testen.

Harald

OP

M

MFreiberger

Level-3
Beiträge
3.101
Reaktionspunkte
844
  • 2 Juni 2022
  • #17

PN/DP schrieb:

Was für Unterschiede konntest Du da "erkennen"? Sah da was im neuen Test-Projekt anders aus als im problematischen Projekt?

Im Testprojekt habe ich erstmal nicht mehrere Bereiche, sondern nur 1 Byte umgeschaufelt. Das war der Unterschied zwischen Test- und "Real"-Projekt.

PN/DP schrieb:

Bei der nicht laufenden Kommunikation: Du hattest auch "Hardware komplett übersetzen" ausgeführt vor dem Laden in die CPUs?

ständig. Deshalb komme ich ja auch nur so langsam voran.

PN/DP schrieb:

Waren da eigentlich auf die i-Device-Kommunikation bezügliche Einträge in den CPU Diagnosepuffern?

Nein. Ich habe keine gesehen.

PN/DP schrieb:

Hoffen wir mal, daß da nur die Projektierung irgendwie fehlerhaft übersetzt war. Nicht daß bei einem späteren Ausfall der F-Kommunikation zur Laufzeit die nachfolgenden Transferbereiche wieder nicht bearbeitet werden... das würde ich auf jeden Fall testen.

Ja, mache ich.

TIA - i-DEVICE kein Datenaustausch (2024)
Top Articles
Latest Posts
Recommended Articles
Article information

Author: Manual Maggio

Last Updated:

Views: 5468

Rating: 4.9 / 5 (49 voted)

Reviews: 80% of readers found this page helpful

Author information

Name: Manual Maggio

Birthday: 1998-01-20

Address: 359 Kelvin Stream, Lake Eldonview, MT 33517-1242

Phone: +577037762465

Job: Product Hospitality Supervisor

Hobby: Gardening, Web surfing, Video gaming, Amateur radio, Flag Football, Reading, Table tennis

Introduction: My name is Manual Maggio, I am a thankful, tender, adventurous, delightful, fantastic, proud, graceful person who loves writing and wants to share my knowledge and understanding with you.