TIA i-DEVICE kein Datenaustausch

[MFreiberger]

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

 

[ChristophD]

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

 

[MFreiberger]

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]

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]

geht die cpu nicht in stop beim bereichslängenfehler?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

 

[MFreiberger]

geht die cpu nicht in stop beim bereichslängenfehler?

Der OB121 ist geladen.

 

[PN/DP]

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

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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".

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

???

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

Harald

 

[MFreiberger]

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

???

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

 

[MFreiberger]

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.

 

[MFreiberger]

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

 

[PN/DP]

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?

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

 

[MFreiberger]

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.

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.

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

Nein. Ich habe keine gesehen.

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.