im151-3 pn wird nicht erkannt

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

hallo

habe ihr ein problem mit einer et200s im151-3

ich habe der im einen namen und eine ip-adresse vergeben und das ganze auf die im übertragen.
die im ist unter erreichbare teilnehmer zu sehen und reagiert auch auf einen ping.
in der diagnose ist die im projektiert aber nicht vorhanden.
ein blinktest an der im funktioniert.

aufbau:
cpu 315-2pn/dp <-> scalance x208 <-> im151

ist meine erste im über profinet.

im anhang mal ein paar bilder

 

[volker]

noch ein bild

 

[ChristophD]

Zuviel Werbung?
-> Hier kostenlos registrieren

gib der IM doch mal den Namen "SP-IM151-3PN"

 

[rostiger Nagel]

Vielleicht hilft dir auch das neue Tool von Siemens:

http://support.automation.siemens.com/WW/view/de/67460624

 

[MSB]

*ACK* an ChristophD
Das einzige was wirklich zählt ist der Name, dieser muss 100 Prozentig mit der HW-Konfig übereinstimmen.

Alles andere wie Topologie und IP-Adresse ist reiner Luxus und im Anfang Ballast.

 

[sps-concept]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

also ich würde erstmal auf Umlaute bei den Namen verzichten... ÜGS

André

 

[volker]

@rn
nettes tool

@msb
ja das mit dem namen war es

danke

 

[Pipboy]

Alles andere wie Topologie und IP-Adresse ist reiner Luxus und im Anfang Ballast.

Vorsicht. Es stimmt, dass die reine IO Kommunkation auf MAC Ebene läuft (die MAC wird über den PN Namen ermittelt).
Aber die anfängliche Parametrierung läuft über UDP/IP. Das mag/kann noch funktionieren, wenn die Device IP im selben Subnetz ist und der Controller mit der empfangenen (statt der projektierten) IP weiterarbeitet.
Spätestens wenn die Device IP in einem anderen Subnetz liegt, funktioniert das nicht mehr.

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vorsicht. Es stimmt, dass die reine IO Kommunkation auf MAC Ebene läuft (die MAC wird über den PN Namen ermittelt).
Aber die anfängliche Parametrierung läuft über UDP/IP. Das mag/kann noch funktionieren, wenn die Device IP im selben Subnetz ist und der Controller mit der empfangenen (statt der projektierten) IP weiterarbeitet.
Spätestens wenn die Device IP in einem anderen Subnetz liegt, funktioniert das nicht mehr.

Das ist aber so auch nicht richtig ... oder wenigstens genau so unvollständig wie mein Statement.
Das "Suchen" des Namens, sowie die Vergabe der IP-Adresse werden normalerweise ja von der CPU (basierend auf der HW-Konfig erledigt) mit dem DCP Protocol, welches jeder PN IO RT Teilnehmer beherrschen muss,
insofern ist es vollkommen unnötig, dem Device sozusagen Initial neben dem Namen auch noch eine IP zu verpassen.
In Step7 wiederum ist es nich möglich, dem IO Device eine nicht zum Subnetz der CPU passende Adresse zu verpassen.
Der Rest der Kommunikation ab dem Zuweisen der IP wird dann wohl mit UDP erfolgen.
Bleibt also noch ein kleiner Rest an Devices, welche feste IP-Adressen, oder DHCP-IPs akzeptiert (wozu die IM151-3 m.W. aber nicht gehört).

Heißt also:
Die initiale Parametrierung, Device <-> CPU ist DCP-Multicast-Basiert, der Rest ist dann ganz normaler IP-Verkehr.

Mfg
Manuel

 

[Pipboy]

Das stimmt schon, was oben steht kann nur bei Geräten passieren, die selbst noch eine Projektierung unabhängig vom Controller haben.