• Aktuell gibt es hier im Forum Spam von langjährigen Usern.

    Vermutlich wurden die Zugangsdaten dieser User irgendwo geleakt.

    Die Beiträge enthalten alle einen einen Link zu Schadsoftware. Bisher lassen sich diese Beiträge recht einfch erkennen. Sie sind in englisch und haben nichts mit dem Thema zu tun. Seid hier bitte sehr vorsichtig.

    1. Nicht auf solche Links klicken
    2. Bitte solche Dinge sofort melden (Button unten am Beitrag)
    3. Wenn jemand Private Nachrichten mit solchen Inhalten bekommt, bitte auch melden!

    Die betroffenn User haben wir gesperrt, Wenn du betroffen bist, dann melde dich gerne bei uns über das Kontaktformular. Wir setzen dann dein Passwort zurück und du kannst dir ein neues vergeben.

    Danke für eure Mithilfe!
    Markus

TIA Profinet-Teilnehmer An/Abmelden

fbrue

Active member
Beiträge
32
Reaktionspunkte
6
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

CPU ist eine 1512SP
TIA V15.1

Ich habe einen Gerät, welches nur zur Prüfung an meine Anlage angesteckt wird. Dies wird in der Visu angewählt und angeschlossen. Ich aktiviere und deaktiviere den Teilnehmer via D_ACT_DP. Das funktioniert soweit auch, sobald der Teilnehmer angemeldet ist läuft die Kommunikation problemlos.
Melde ich den Teilnehmer wieder ab, ist auch alles soweit in Ordnung. Ziehe ich nun das Profinet-Kabel ab, zeigt meine PLC Error mit der Meldung im Diagnosepuffer "Fehler: Fehler beim Partner - Es konnte kein Nachbar erkannt werden". Der Teilnehmer ist doch abgemeldet - da sollte das doch eben nicht passieren, oder?
Oder liegt es daran, dass ich für diesen Teilnehmer eine feste Topologie vorgegeben habe? Aus der Siemens Bausteindoku konnte ich dazu keine weitere Info ziehen.
 
Moin fbrue,

ich melde unser KTP700F mobile mit D_ACT_DP ab. Das funktioniert tadellos. Auch, wenn man das Panel abzieht.

Möglich, dass es an der Topologie liegt (für das mobile Panel habe ich keine Topologie projektiert). Kannst Du das nicht einfach einmal ausprobieren und Deine Erfahrung hier posten?

VG

MFreiberger
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es liegt an der Topologie. Das hat mir der Siemens Support eben auch noch einmal bestätigt.
Hier die Antwort, falls jemand das Problem auch mal haben sollte:

Wie von Ihnen bereits vermutet ist in diesem Fall die konfigurierte Topologie der auslösende Faktor.

D_ACT_DP kann als solches nur für Devices genutzt werden für die keine topologische Verschaltung projektiert wurde.

Die Anweisung deaktivert nur den Teilnehmer als solches. Wird dieser jedoch abgesteckt, stimmt jedoch die in der Hardware konfigurierte Topologie nicht mehr überein was die Meldung verursacht.

In diesem Fall muss die Anweisung "ReconfigIOSystem" verwendet werden. Hier ist es möglich auch die neue Portverschaltung über einen entsprechenden Datensatz zu übernehmen.

Informationen dazu finden Sie nachfolgend.

SIMATIC STEP 7 Basic/Professional V15.1 und SIMATIC WinCC V15.1

ReconfigIOSystem: IO-System umkonfigurieren (S7-1500)

https://support.industry.siemens.com/cs/ww/de/view/109755202/105014071563

Programmbeispiel für ReconfigIOSystem (S7-1200, S7-1500)

https://support.industry.siemens.com/cs/ww/de/view/109755202/94079085579
 
Hi!

Interesanter Beitrag, mal eine kurze Rückfrage: Wenn Ihr eine Topologie projektiert, dann aber auch über einen managebaren Switch, oder? Ein Standard-Switch erkennt diese Topologie ja nicht, bzw. wertet keine "gesteckt" oder "nicht gesteckt" Signale aus, bzw. erkennt wie in diesem Fall nur dass ein Bussteilnehmer fehlt. Lässt sich sowas nicht umgehen, indem man einen managebaren Switch verwendet, bei dem sich einzelne Ports abschalten lassen?

Denn wenn ich richtig weiß, wird ja mit "ReconfigIOSystem" quasi die HW-Config umgestrickt, oder? Das ist jetzt ja auch nicht grade ein Klacks sowas einzurichten...

Gruß Christian
 
Sehr informativer Beitrag, aber warum verwendet ihr da überhaupt Topologie? Braucht der Prüfling IRT? Oder gehts um PN-Namen zuweisen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir verwendet Topologie auf 2 Grunden.
1. Die Teilnehmer brauchen nicht 'getauft' zu werden. (Mir gefällt es nicht, ist aber Firmenpolitik).
2. Man bekommt genauere Diagnoseinformationen. Dass wäre viel Wert wenn das Anlage steht und man wird erzählt ziemlich genau wo es meckert. Ist nicht 100%, aber ich finde es ist den Aufwand wert.

edit: Eine Nachteil der eigentlich die Vorteil von Nr. 2 verringert. Mit konfigurierte Topologie kann man nicht mehr einfach Kabeln auf andere Ports stecken um zu sehen ob ein Fehler beseitigt wird oder mitfolgt. Darüber muss man auch denken wenn man vor oder gegen Topologie übelegt.
 
Sehr informativer Beitrag, aber warum verwendet ihr da überhaupt Topologie? Braucht der Prüfling IRT? Oder gehts um PN-Namen zuweisen?

Genau, der PN-Gerätename wird zugewiesen.
Hi!

Interesanter Beitrag, mal eine kurze Rückfrage: Wenn Ihr eine Topologie projektiert, dann aber auch über einen managebaren Switch, oder? Ein Standard-Switch erkennt diese Topologie ja nicht, bzw. wertet keine "gesteckt" oder "nicht gesteckt" Signale aus, bzw. erkennt wie in diesem Fall nur dass ein Bussteilnehmer fehlt. Lässt sich sowas nicht umgehen, indem man einen managebaren Switch verwendet, bei dem sich einzelne Ports abschalten lassen?

Denn wenn ich richtig weiß, wird ja mit "ReconfigIOSystem" quasi die HW-Config umgestrickt, oder? Das ist jetzt ja auch nicht grade ein Klacks sowas einzurichten...

Gruß Christian

Der Switch ist ein Managed Switch, genau.

Das ist richtig, hält sich aber bei mir noch in Grenzen, bei größeren/komplexeren Anlagen macht das natürlich enormen Aufwand. Leider wird auf dieses Problem nirgends in der Bausteindoku hingewiesen..
 
Zurück
Oben