- Steuerungssysteme
- SIEMENS - PLC
- ErstellerMFreiberger
- Erstellt am2 Juni 2022
M
MFreiberger
Level-3
- Beiträge
- 3.101
- Reaktionspunkte
- 844
- 2 Juni 2022
- #1
-> 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
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
-> 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
-> 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
ChristophD schrieb:
geht die cpu nicht in stop beim bereichslängenfehler?
Der OB121 ist geladen.
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
-> 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
-> 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
???
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
-> 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
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.