24. April 2019, 00:01:42
Roboterforum.de - Die Industrieroboter- Anwender und Experten Community

[gelöst] KSS 8.3 und 8.2; Kommunikationsfehler sicheres Gerät ProfiNet Device


normal_post Autor Thema: [gelöst] KSS 8.3 und 8.2; Kommunikationsfehler sicheres Gerät ProfiNet Device  (Gelesen 1405 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

06. Februar 2019, 08:23:56
Gelesen 1405 mal
Offline

AndreM2012


Hallo werte Gemeinde,

ich hab mal wieder ein Problem.
Heute mal mit PNet Device. Es ist ein Fehler, der schon lang in der Linie vorhanden ist.
Bei Aus- und Einschalten der Anlage habe ich nach und nach das Problem, das der eine oder andere Roboter mit der Fehlermeldung hochfährt "QuittStopp: Kommunikationsfehler sicheres Gerät ProfiNet Device". Ich kann allerdings nichts richtiges finden. Die SPS-ler sagen, das meine Festo CPX ihre Adresse ändern würde. Hab allerdings eine feste IP vergeben(???).
Hat jemand eine Idee? Kann es evtl. an der GSDML liegen???

Danke euch schon mal im Voraus!

Update:
Es betrifft doch die ganze Linie. Wenn ich eine Steuerung ausblende und neu starte, kann es passieren, dass es die Festo CPX eines anderen Roboters abschießt. Kann es mir nicht erklären.

Gruß André :D
« Letzte Änderung: 21. Februar 2019, 21:02:03 von Roland Keller »
  • gefällt mir    Danke

Heute um 00:01:42
Antwort #1

Werbung

Gast

06. Februar 2019, 12:53:12
Antwort #1
Offline

Vincent42


Hast du eine VKRC?
Hast du es schon mal mit einem an- und abkoppeln des Gerätea probiert?
  • gefällt mir    Danke

06. Februar 2019, 13:22:34
Antwort #2
Offline

AndreM2012


Nein. KRC4. Habe ich schon mehrmals versucht. Aber diesen Zustand kann ich nur so wie beschrieben reproduzieren.
Deswegen ist es mir schleierhaft. :denk:
  • gefällt mir    Danke

06. Februar 2019, 13:28:46
Antwort #3
Offline

Vincent42


Hängen diese Teilnehmer alle an einer einzigen 24 Volt Spannungsquelle?
  • gefällt mir    Danke

06. Februar 2019, 13:44:27
Antwort #4
Offline

AndreM2012


Nein. Jede hat für sich eine eigene Spannungsversorgung. :huh:
  • gefällt mir    Danke

Heute um 00:01:42
Antwort #5

Werbung

Gast

06. Februar 2019, 14:51:47
Antwort #5
Offline

Vincent42


Wir hatten ebenfalls mal ein solches Problem. Die Lösung des Problems war, das aufgrund der Teilnehmeranzahl die Spannungsquelle zu niedrig eingestellt war.
  • gefällt mir    Danke

06. Februar 2019, 18:00:33
Antwort #6
Offline

WolfHenk


Klingt nach "Brummschleife". Die Funk- und Radio-Techniker kennen sowas.
Nur rein nach Gefühl...
Sorry, aber das zu erklären ist in der Eisenbahn etwas ... Schwierig.
Wolfram (Cat) Henkel

never forget Asimov's Laws at the programming of robots...

"Safety is an integral part of function. No safety, no production. I don't buy a car without brakes."

https://www.xing.com/go/invite/5634410.eb15e5

PMs und Mails mit Anfragen wie "Wie geht das..." werden nicht beantwortet. Diese Fragen und die Antworten interessieren jeden hier im Forum.

07. Februar 2019, 16:18:42
Antwort #7
Offline

Roboformer


Bei mir lag es mal daran, dass die SPS beim Signalverlust durch das Herunterfahren und neu Starten die Robotersteuerung passiviert hat.
  • gefällt mir    Danke

07. Februar 2019, 17:26:45
Antwort #8
Offline

zteve


Ich hatte mal einen ähnlichen Fall mit 2 Schweisssteuerungen (SST), deren Controller je eine KRC4 war (im gleichen Netz):
Waren beide KRC4 und ein Device (SST) ausgeschaltet und wurde der Controller (KRC4) zuerst hochgefahren, dessen Device ausgeschaltet war, wurden die Kommunikationsparameter (IP, PN-Name) der aktiven Schweisssteuerung mit den Werten vom "falschen Controller" überschrieben. Der Rob hat sich sozusagen die nächst beste SST gekrallt.

Die wahrscheinliche Ursache war die Profinet-Funktionalität "Gerätetausch ohne Wechselmedium". Die ermöglicht, dass ein Gerät - in einer bekannten Topologie - ersetzt werden kann ohne die Parameter IP + Name konfigurieren zu müssen. Die werden dabei vom Controller zugewiesen.
Allerdings müssen dafür einige Bedingungen erfüllt sein!

Ich habe nie 100% herausgefunden, ob das der Grund war, die Anlage wurde später nur noch komplett an-/ausgeschaltet und dabei gab es dieses Problem nicht.

Deshalb nur mal eine Sensibilisierung für diese Möglichkeit.
Prüfen kannst du es recht einfach: Wenn es wieder passiert und ein CPX-Modul hat die Adresse /den Namen eines anderen Moduls kann es nur durch diese Funktionalität passiert sein.
In diesem Fall hilft dann vielleicht die Auswahl des Parameters "Systemstart mit... gespeicherten Parametern"  in der CPX-Konfig UND in der WV-Konfig für das Modul.

Ist alles nichts handfestes, aber vielleicht bringt es dich irgendwie weiter.
« Letzte Änderung: 07. Februar 2019, 17:33:11 von zteve »
  • gefällt mir    Danke

Heute um 00:01:42
Antwort #9

Werbung

Gast

07. Februar 2019, 19:18:50
Antwort #9
Offline

Otto Sieben



Moin,
das "sichere Gerät ProfinetDevice" ist der SafeTreiber im Profinet.
Hintergrund: Die Robotersteuerung ist grundsätzlich der Slave der Sicherheits-SPS. Beim Hochlauf der Steuerungen initiert der Master (SPS) die Verbindungsaufnahme zum Slave (Roboter). (Ich weiss, im Profinet heißt es Controller und Device, Master und Slave ist aber imho einleuchtender) . Heisst also, die SPS triggert den Roboter an, worauf er die Kommunikation auf dem SafeKanal aufnimmt. Daher kommt die besagte Quitt-Meldung.
Ich habe bisher noch keine Anlage gesehen, wo das ohne Quittieren nach Hochlauf funktioniert. Kann eigentlich auch nicht. VW-Kenner kennen diesen Quittiervorgang SPS-seitig als Depassivieren, dort muss sogar dieser Vorgang von Hand ausgelöst werden. In der restlichen Welt versucht die SPS selbstständig zyklisch den Verbindungsvorgang einzuleiten.
Wenn ein CPX Modul eine andere Adresse bekommt, ist es vielleicht unzulässigerweise auf Roboter und SPS in der Hardware konfiguriert. Geht meines Wissens aber eigentlich überhaupt nicht. (2 Master auf ein Modul ?)
  • gefällt mir    Danke
never touch a running system

07. Februar 2019, 22:39:46
Antwort #10
Offline

zteve



Hallo Otto
Es ist erlaubt Profinet-Geräte auf zwei Controller/Master als Hardware zu konfigurieren - wenn das PN-Gerät das unterstützt. Die einzelnen Module des Geräts könnnen dabei den beiden Mastern zugeordnet werden, z.B. könnte konfiguriert werden, dass die SPS auf ein Ausgangsmodul einer CPX zugreift und der Roboter auf ein Eingangsmodul der selben CPX.
Die Funktionalität nennt sich Shared-Device.


08. Februar 2019, 17:00:31
Antwort #11
Offline

Otto Sieben


@zteve SharedDevice, wieder was gelernt. Danke  :danke:

Was die eigentliche Fragestellung der TO anbetrifft, vermute ich bei seinem "verschwindenen" CPX _ Modul nun nochmehr ein Konfigurationsproblem. Unabhängig davon, ob das Device den Modus nun unterstützt.
  • gefällt mir    Danke
never touch a running system

14. Februar 2019, 11:58:17
Antwort #12
Offline

AndreM2012


Hi an alle,

erstmal möchte ich euch für die zahlreichen Anregungen danken.  :danke: Ich denke jedoch, dass sich das Problem anders aufgelöst hat.
Im Switch der SPS ist eine Option standardmäßig aktiviert, die sich "Passive Listening Enabled" nennt.
Nun wurden diese Optionen deaktiviert und der Fehler tritt nicht mehr auf.

Ich hoffe, dass es somit diesen Fehler nicht mehr gibt.  :) Jedenfalls nach mehreren Tests.
Sollte dieser Fehler erneut auftauchen, würde ich den Beitrag nochmal erweitern.

In diesem Sinne euch allen eine schöne Restwoche.

Gruß André


  • gefällt mir    Danke

Heute um 00:01:42
Antwort #13

Werbung

Gast

21. Februar 2019, 21:01:43
Antwort #13
Online

Roland Keller

Administrator
Warum wird dann das Thema nicht als gelöst markiert?
  • gefällt mir    Danke
-------------
Gruß
Roland

Wie poste ich falsch?
Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.

Ich bin wie ich bin. Die Einen kennen mich, die Anderen können mich.
Konrad Adenauer

22. Februar 2019, 08:35:59
Antwort #14
Offline

AndreM2012


Hallo ihr Lieben,

also nach mehreren Testphasen kann ich sag, dass letzt alles dauerhaft stabil läuft.
Ich würde somit dieses Thema als gelöst markieren wollen.
Nur...wie geht das??? :huh:

Wenn mir da mal einer kurz ne Info geben könnte wäre ich dankbar.

Viele Grüße
  • gefällt mir    Danke


Teile per facebook Teile per linkedin Teile per pinterest Teile per reddit Teile per twitter
 

über das Roboterforum

Nutzungsbedingungen Impressum Datenschutzerklärung

Sponsoren des Roboterforums

ROBTEC GmbH