# Probleme mit Euchner MGB



## Lipperlandstern (23 April 2015)

Hallo Kollegen.

Ich habe hier an einer Anlage 4 Euchner MGB im Einsatz.  Diese Geräte sind am Profinet angeschlossen und haben einen Not.Halt, div. Tasten und eine Türverriegelung.  2 von diesen Geräten arbeiten problemlos. Bei den anderen beiden fällt ständig das Bit für Not-Halt aus. Bis zu 90 mal in 24 Stunden und immer kürzer als 250ms. Und nur Not-Halt. Die Bits für die Türverriegelung sind problemlos.  Ich habe im Sicheren Programm das Not-Halt- Signal mit 250ms Verzögerung programmiert damit ich nicht ständig quittieren muss. 

Was mich aber am meisten nervt ist der Support von Euchner. Die haben keine Ahnung woran das liegt und auch keine richtiges Interesse den Fehler zu lokalisieren. Euchner schiebt die Verantwortung ab. Überprüfen sie ihr Netz, Überprüfen Sie ihr Programm bla bla bla. Auf eine Ersatzbox muss ich sage und schreibe 4 Wochen warten und sogar bezahlen wenn sie im Labor an der Orginalbox keinen Fehler feststellen können. 

Hat jemand Erfahrungen mit dieser Box und evtl. das selbe Problem ?


----------



## RogerSchw85 (23 April 2015)

Wir waren bis jetzt immer sehr Vorsichtig mit diesen Schaltern und Profinet. Wir haben sie bis jetzt nur herkömmlich verwendet. Und schon da starten sie ab und zu nicht auf oder haben komische Fehler...

Laut Euchner jedoch haben nur wir das Problem


----------



## Blockmove (23 April 2015)

Das Fehlerbild deutet schon auf Netzprobleme hin.
Diese sporadischen kurzen Ausfälle hatte ein Kollege diese Woche auch. Allerdings mit einem Murrelektronik Busknoten an einer 317er CPU.
Wir haben den Profinet-Sendetakt von 1ms auf 2ms hochgesetzt und der Spuk war vorbei.

Irgendwie sind die Profinet-Einstellungen  von Siemens zu optimistisch

Gruß
Dieter


----------



## Lipperlandstern (23 April 2015)

Ja... Netzprobleme. ABER warum nur an diesen 2 Teilnehmern von Euchner. Das ganze Netz hat an die 100 Teilnehmer inkl. WLAN und alles funzt und warum nur das Not-Halt-Signal und nicht die Türsignale. 

Wo hast du den Sendetakt eingestellt ?  Da wo man das für jeden Teilnehmer einzeln auswählen kann ? Das kann ich natürlich nochmal versuchen.


----------



## Blockmove (23 April 2015)

Ich hab den Sendetakt in den Profinet-Einstellungen der CPU hochgesetzt.

Ausserdem hab ich die Erfahrung gemacht, dass Profinet empfindlich auf Schirmströme reagiert.
Wir legen bei unseren Maschinen sehr viel Wert auf vernünftige Erdung und Potentialausgleich. Aber trotzdem erlebt man immer wieder mal eine Überraschung wenn man mit der Schirmstrommesszange nachmisst.
Bei den ganzen Servos, Umrichtern und Schaltnetzteilen hat man jede Menge hochfrequente Schweinereien rumschwirren. Und denen ist halt manchmal der Schirm eines Netzwerkkabels lieber als die 25mm² Potetialausgleichsleitung.

Gruß
Dieter


----------



## marlob (23 April 2015)

Lipperlandstern schrieb:


> Ja... Netzprobleme. ABER warum nur an diesen 2 Teilnehmern von Euchner. Das ganze Netz hat an die 100 Teilnehmer inkl. WLAN und alles funzt und warum nur das Not-Halt-Signal und nicht die Türsignale.
> 
> Wo hast du den Sendetakt eingestellt ?  Da wo man das für jeden Teilnehmer einzeln auswählen kann ? Das kann ich natürlich nochmal versuchen.





hier, nicht die Aktualisierungszeit die du wahrscheinlich meinst.


----------



## Lipperlandstern (23 April 2015)

Blockmove schrieb:


> Ich hab den Sendetakt in den Profinet-Einstellungen der CPU hochgesetzt.
> 
> Ausserdem hab ich die Erfahrung gemacht, dass Profinet empfindlich auf Schirmströme reagiert.
> Wir legen bei unseren Maschinen sehr viel Wert auf vernünftige Erdung und Potentialausgleich. Aber trotzdem erlebt man immer wieder mal eine Überraschung wenn man mit der Schirmstrommesszange nachmisst.
> ...




Das hatte ich auch gedacht aber die Teile fallen auch aus wenn die Anlage quasi steht und alles an Servos abgeschaltet ist. Wir haben auch drahtlose Spannungsübertragung in der Anlage aber auch die hat keinen Einfluss.


----------



## Lipperlandstern (23 April 2015)

marlob schrieb:


> Anhang anzeigen 28342
> 
> hier, nicht die Aktualisierungszeit die du wahrscheinlich meinst.




Das Bild kommt mir sehr bekannt vor  .... ich werde das morgen mal hochsetzen. Mal sehen was passiert


----------



## Lipperlandstern (24 April 2015)

Ich habe die Zeit auf 2ms erhöht und die Fehler sind tatsächlich weniger geworden aber immer noch vorhanden. Wie hoch kann man das denn einstellen ????


----------



## RogerSchw85 (24 April 2015)

Das kommt auf deine Anwendung an... 5ms sollten jedoch gut reichen


----------



## Blockmove (24 April 2015)

Ich stell die Zeit so Pi mal Daumen auf 1/4 Zykluszeit. Du kannst die Zeit natürlich auch länger machen, aber das hängt dann eben von der Anwendung ab.
Wieviele Switche / Teilnehmer hängen im Netz vor den gestörten Teilnehmern?
Hast du die Profinet-Topologie richtig eingetragen?
Welche Switche verwendest du?

Da es bei dir wohl immer die gleichen Teilnehmer sind, solltest du mal evtl. probieren einen zusätzlichen Netzwerkstrang aufzubauen und die Netzwerklast gleichmässiger aufzuteilen.

Gruß
Dieter


----------



## Lipperlandstern (24 April 2015)

Blockmove schrieb:


> Ich stell die Zeit so Pi mal Daumen auf 1/4 Zykluszeit. Du kannst die Zeit natürlich auch länger machen, aber das hängt dann eben von der Anwendung ab.
> Wieviele Switche / Teilnehmer hängen im Netz vor den gestörten Teilnehmern?
> Hast du die Profinet-Topologie richtig eingetragen?
> Welche Switche verwendest du?
> ...



Zumindestens einer der Sorgenkinder hängt direkt am Switche. Bei dem anderen weiss ich es grad nicht aber viele Teilnehmer sind es sicher nicht.  Wir haben Switche von Phönix im Einsatz. Das Netzwerk ist nicht grade klein und es sind insgesamt 3 CPUs mit drin. Aber alles läuft super bis auf diese 2 Mistkerle.  Ich hab noch nicht viel Erfahrung mit Profinet. Was meinst du mit Topologie eintragen ?


----------



## Blockmove (25 April 2015)

Lipperlandstern schrieb:


> Zumindestens einer der Sorgenkinder hängt direkt am Switche. Bei dem anderen weiss ich es grad nicht aber viele Teilnehmer sind es sicher nicht.  Wir haben Switche von Phönix im Einsatz. Das Netzwerk ist nicht grade klein und es sind insgesamt 3 CPUs mit drin. Aber alles läuft super bis auf diese 2 Mistkerle.  Ich hab noch nicht viel Erfahrung mit Profinet. Was meinst du mit Topologie eintragen ?



Topologie:
In der Hardwarekonfig kannst du die Netzwerktopologie (Aufbau) eintragen.
Es gibt dafür ein recht gutes grafisches Tool. Du definierst damit welcher Netzwerkanschluss eines Gerätes mit welchem Partner verbunden ist.
Bei Profinet gibt es die sogenannte Nachbarschaftserkennung (LLDP). Wenn jedes Gerät seinen Nachbarn kennt, so ist darüber ein Gerätetausch ohne Noteboök möglich.
Du holst ein neues, nicht konfiguriertes Gerät aus dem Lager und schliesst es an. Die Nachbarn sind Antrieb 4 und Antrieb 6. Somit ist das neue Gerät Antrieb 5 und wird entsprechend konfiguriert.
Ausserdem ist die Onlineansicht der grafischen Topologieübersicht bei der Fehlersuche manchmal ganz nützlich.

Switche:
Bei Profinet setzten wir generell Siemens Scalance-Switche ein.
Diese werden über die Hardwarekonfig entsprechend parametriert. Ich weiss nicht ob dies bei Phönix auch der Fall ist.
Wenn nicht, dann musst die Switche entsprechend kofigurieren. Profinet sollte priorisiert werden.
Wenn du viele Panels, Kameras oder sonstigen "Kram" am Netz hast, dann muss sich Profinet "in die Schlange stellen".
Da aber Profinet quasi Echtzeit sein soll, muss die Priorität für Profinet erhöht sein und Profinet kann sich vorbei drängeln.
Eure 100 Teilnehmer sind schon eine Hausnummer. Da kann schon der ein oder andere Flaschenhals auftreten und dies äussert sich in "seltsamen" Verhalten einzelner Teilnehmer.

Wenn du die Probleme nicht in Griff bekommst, kannst du ja mal das Netz testen lassen. Es gibt eiige Dienstleister auf dem Markt.
Bei entsprechend guter Netzwerkdoku (Topologie) hält sich der Zeitaufwand und somit die Kosten in Grenzen.

Gruß
Dieter


----------



## Thomas_v2.1 (25 April 2015)

Bei Profinet-IO gibt es nicht viele Gründe für ein "falsches" bzw. nicht erwartetes Signal:

1) Der PN-Teilnehmer schickt wirklich ein falsches Signal, d.h. Fehler im Teilnehmer
2) Der PN-Teilnehmer fällt aus, die SPS setzt den Signalzustand die Eingänge auf Null, der PN-Teilnehmer seine Ausgänge ggf. auf einen sicheren Zustand.

Fällt ein PN-Teilnehmer wegen ansprechen der Überwachungszeit aus, gibt es normalerweise im Diagnosepuffer der SPS einen Eintrag. Da würde ich als erstes mal nach Auffälligkeiten schauen.
Wenn du die Aktualisierungszeit heraufsetzt, erhöht sich auch die Ansprechüberwachungszeit.

Wenn du keinen Eintrag im Diagnosepuffer der SPS hast, bleibt eigentlich nur noch Problem 1).

Die Ursache für Fehler 2) kann diverse Ursachen haben, wie von Blockmove aufgeführt. Aber erstmal muss festgestellt werden ob 2) überhaupt auftritt (Diagnosepuffer der SPS prüfen).

Zur Not muss man am Netzwerk den Verkehr mitschneiden und nachprüfen was dort vor sich geht, und damit dann auf den Hersteller zugehen. Zum "Glück" tritt das Problem ja häufig auf, sodass man darauf warten kann.


----------



## Blockmove (25 April 2015)

Thomas_v2.1 schrieb:


> Die Ursache für Fehler 2) kann diverse Ursachen haben, wie von Blockmove aufgeführt. Aber erstmal muss festgestellt werden ob 2) überhaupt auftritt (Diagnosepuffer der SPS prüfen).
> 
> Zur Not muss man am Netzwerk den Verkehr mitschneiden und nachprüfen was dort vor sich geht, und damit dann auf den Hersteller zugehen. Zum "Glück" tritt das Problem ja häufig auf, sodass man darauf warten kann.



Bei Profinet gibt es auch Telegramm-Wiederholungen. Damit etwas im Diagnosepuffer auftaucht muss das Netzwerk schon heftig gestört sein.
Du kannst ein absolut grenzwertiges Netzwerk haben und bekommst vielleicht einmal pro Woche eine Meldung. Schön sind diese Dinge dann beim F-Programm 

Aber laut den ganzen Marketing-Kaspern ist ja Profinet sooo einfach und viel viel besser als Profibus.

Es gibt einige Anbieter (Indu-Sol, Softing, ...) die entsprechende Testgeräte anbieten. Aufgrund der Freiheit bei der Topologie sind Netzwerkfehler manchmal aber sehr schwer zu lokalisieren.

Gruß
Dieter


----------



## Thomas_v2.1 (25 April 2015)

Solange die eingestellte Anzahl der Wiederholungen nicht überschritten wird, ist der Teilnehmer aber nicht gestört. Gab es bei Profibus in Form des Retry-Limit aber auch schon, nur dass dieser dort auf 1 steht solange man die Einstellungen nicht verändern muss.
Bei Profinet kann ich die Anzahl Wiederholungen nur beim Device einstellen, ich weiß momentan nicht ob die Anzahl dann genauso für den Controller gilt.

Solange nicht eindeutig festgestellt wurde ob die Ansprechüberwachung ausgelöst hat, braucht man sich noch keine Gedanken um Topologien, Switche oder Erdungen zu machen.


----------



## Lipperlandstern (25 April 2015)

Thomas_v2.1 schrieb:


> Bei Profinet-IO gibt es nicht viele Gründe für ein "falsches" bzw. nicht erwartetes Signal:
> 
> 1) Der PN-Teilnehmer schickt wirklich ein falsches Signal, d.h. Fehler im Teilnehmer
> 2) Der PN-Teilnehmer fällt aus, die SPS setzt den Signalzustand die Eingänge auf Null, der PN-Teilnehmer seine Ausgänge ggf. auf einen sicheren Zustand.
> ...




Es gibt keine Eintrag im Diagnosepuffer. Die Geräte gehen ja auch nicht auf "Störung". Und es fällt nur das Not-Halt-Signal aus. Und das immer kürzer als 250 ms. Das Tür-Signal welches im selben Block übertragen wird macht keine Probleme. Also doch (1) ? Allerdings wird das Verhalten besser wenn die Aktualisierungzeit erhöht wird. Das spricht für (2).  

Ich warte jetzt erstmal auf das Austauschgerät......


----------



## Thomas_v2.1 (25 April 2015)

Lipperlandstern schrieb:


> Es gibt keine Eintrag im Diagnosepuffer. Die Geräte gehen ja auch nicht auf "Störung". Und es fällt nur das Not-Halt-Signal aus. Und das immer kürzer als 250 ms. Das Tür-Signal welches im selben Block übertragen wird macht keine Probleme. Also doch (1) ? Allerdings wird das Verhalten besser wenn die Aktualisierungzeit erhöht wird. Das spricht für (2).



Durch heraufsetzen der Aktualisierungszeit bekommst du vielleicht nicht jedes Signal mit das von dem Gerät falsch erfasst wird.

Beispiel: Es gibt auf einem Eingang kurze Spitzen von 10ms Dauer. Wird der Eingang mit 50 ms abgetastet bekommst du nicht jede Spitze mit. Wird mit 1ms abgetastet dann schon (Shannon Theorem).

Dass du die Störung mit dem 250ms Timer unterdrücken kannst spricht auch gegen einen ausfallenden Teilnehmer. Was ich so festgestellt habe, dauert es nach einem Ausfall eines Devices nach dem Wiederanmelden meist so 2-3 Sekunden bis der zyklische Datenaustausch wieder aufgenommen wird.


----------



## Blockmove (25 April 2015)

Eigentlich müsstestdu den Fehler durch Tausch von 2 Geräten eingrenzen können.
Tausch deinen Schalter gegen einen funktionierenden.
Netzwerkfehler sind in den meisten Fällen Standort treu. Wandert der Fehler mit, dann liegt der Fehler am Schalter.
Zeigt der bislang funktionierende Schalter Störungen, dann liegt es am Netz.

Gruß
Dieter


----------



## Thomas_v2.1 (26 April 2015)

Ich habe gerade noch mal etwas Doku gelesen.
Wie schon geschrieben, gibt es bei Profinet eigentlich nur zwei Fehler: entweder das Device schickt falsche Daten oder das Device fällt aus, d.h. schickt keine Daten im eingestellten Überwachungsintervall mit entsprechendem Eintrag im Diagnosepuffer. Nicht erkannte Telegrammfehler seien hier aufgrund der Hamming-Distanz von imho 4 (wie bei Profibus) mal ausgeschlossen.

Fällt ein Device aus dauert es einige Zeit bis zum Hochlaufen. Ich konnte jetzt nicht aus der Beschreibung herauslesen wie lange diese Zeit mindestens ist. Auf jeden Fall ist nur mit besonderen Controllern und Devices ein sogenannter "priorisierter Hochlauf" möglich. Damit kommt man unter bestimmten Umständen auf eine Hochlaufzeit von 500ms. Ich habe an "normalen" Geräten eine Hochlaufzeit von 2-3 Sekunden festgestellt.
Ich würde darum mal behaupten, bei allen Störungen kürzer als 500ms ist es garantiert kein Netzproblem.

Der Vorteil bei Profinet ist, dass es mit im Vergleich zu Profibus relativ günstigem Equipment diagnostizierbar ist. Ein Switch mit Monitor-Port oder besser noch ein TAP und Wireshark reicht völlig aus. Und die Diagnose-Software für Profibus von Trebing&Himstedt ist im Vergleich zu Wireshark ein schlechter Witz.


----------



## Lipperlandstern (26 April 2015)

Blockmove schrieb:


> Eigentlich müsstestdu den Fehler durch Tausch von 2 Geräten eingrenzen können.
> Tausch deinen Schalter gegen einen funktionierenden.
> Netzwerkfehler sind in den meisten Fällen Standort treu. Wandert der Fehler mit, dann liegt der Fehler am Schalter.
> Zeigt der bislang funktionierende Schalter Störungen, dann liegt es am Netz.
> ...




Das mit dem Tausch ist leider gar nicht so einfach da wir die MGBs in 2 verschiedenen Varianten haben (linker bzw. rechter Türanschlag) Und natürlich sind 2 linken kaputt  ..... Ich warte mal auf das Ersatzteil... dauert ja nur noch 3 Wochen bis es kommt....


----------



## Lipperlandstern (26 April 2015)

Thomas_v2.1 schrieb:


> Ich habe gerade noch mal etwas Doku gelesen.
> Wie schon geschrieben, gibt es bei Profinet eigentlich nur zwei Fehler: entweder das Device schickt falsche Daten oder das Device fällt aus, d.h. schickt keine Daten im eingestellten Überwachungsintervall mit entsprechendem Eintrag im Diagnosepuffer. Nicht erkannte Telegrammfehler seien hier aufgrund der Hamming-Distanz von imho 4 (wie bei Profibus) mal ausgeschlossen.
> 
> Fällt ein Device aus dauert es einige Zeit bis zum Hochlaufen. Ich konnte jetzt nicht aus der Beschreibung herauslesen wie lange diese Zeit mindestens ist. Auf jeden Fall ist nur mit besonderen Controllern und Devices ein sogenannter "priorisierter Hochlauf" möglich. Damit kommt man unter bestimmten Umständen auf eine Hochlaufzeit von 500ms. Ich habe an "normalen" Geräten eine Hochlaufzeit von 2-3 Sekunden festgestellt.
> ...




Wenn ich mal den Netzwerkstecker von dem Gerät ziehe und wieder draufstecke dauert es bestimmt 3-4 Sekunden bis die Signale wieder da sind. Also eine "richtigen" Netzwerkfehler gibt es bei diesen Geräten sicher nicht.


----------



## rostiger Nagel (26 April 2015)

Lipperlandstern schrieb:


> Das mit dem Tausch ist leider gar nicht so einfach da wir die MGBs in 2 verschiedenen Varianten haben (linker bzw. rechter Türanschlag) Und natürlich sind 2 linken kaputt  ..... Ich warte mal auf das Ersatzteil... dauert ja nur noch 3 Wochen bis es kommt....



Kannst du nicht trotzdem tauschen, vielleicht kannst du dann den Spieß mit dem Lieferanten
umdrehen, anscheinend setzt der dich mit Lieferfristen und überprüfungskosten unter Druck. 

Grundsätzlich würde ich über einen Wechsel nachdenken, solche  Unkooperative Lieferanten
kann man im Industrielken Umfeld nicht gebrauchen. Da kostet jeder Ausfall oder Stillstand
Geld.


----------



## Blockmove (26 April 2015)

rostiger Nagel schrieb:


> Grundsätzlich würde ich über einen Wechsel nachdenken, solche  Unkooperative Lieferanten
> kann man im Industrielken Umfeld nicht gebrauchen. Da kostet jeder Ausfall oder Stillstand
> Geld.



Das Problem ist nur, dass es - meines Wissens - keine Alternative gibt.
Ich kenne zumindest kein weiteres Schutztürschalter-System mit integrierter Profi-Net-Schnittstelle.

Wir setzen Pilz PSENsgate ein und der Verdrahtungsaufwand ist grausig.
Wenn Euchner MGB mechanisch besser zu uneren Schutztüren passen würde, dann hätten wir dieses System im Einsatz.
Aber dann hätte ich vielleicht die selben Probleme wie Lipperlandstern 

Gruß
Dieter


----------



## Lipperlandstern (26 April 2015)

rostiger Nagel schrieb:


> Kannst du nicht trotzdem tauschen, vielleicht kannst du dann den Spieß mit dem Lieferanten
> umdrehen, anscheinend setzt der dich mit Lieferfristen und überprüfungskosten unter Druck.
> 
> Grundsätzlich würde ich über einen Wechsel nachdenken, solche  Unkooperative Lieferanten
> ...



Da hast du recht. Über den Support bin ich mehr als entäuscht. Die Antworten die ich hier bekommen habe hätte ich eigentlich von Euchner erwartet. Ich weiß schon genau was passiert wenn das Ersatzgerät eintrifft : Das funktioniert, ich schicke das defekte zur Überprüfung ein : Ergebnis : Kein Fehler feststellbar...  ..

Ansonsten muss ich Blockmove recht geben. Die Teile sind schon genial....


----------



## Thomas_v2.1 (27 April 2015)

Lipperlandstern schrieb:


> Wenn ich mal den Netzwerkstecker von dem Gerät ziehe und wieder draufstecke dauert es bestimmt 3-4 Sekunden bis die Signale wieder da sind. Also eine "richtigen" Netzwerkfehler gibt es bei diesen Geräten sicher nicht.



Ca. 3 Sekunden sind auch meine Erfahrung.
Datenverfälschungen durch Störungen auf der Leitung, die als gültige Daten von den Partnern angesehen werden sind extrem unwahrscheinlich. Durch die Ethernet-Prüfsumme müssen mindestens 4 Bits bei der Übertragung gekippt sein, sodass die Prüfsumme trotzdem richtig sein könnte (was zudem recht unwahrscheinlich ist).
Ansonsten wird bei falscher Prüfsumme das Datenpaket verworfen. Wenn zu viele verworfen wurden, bzw. überhaupt keine gültigen Telegramme mehr eintreffen, spricht nach Ablauf der Überwachungszeit der Watchdog-Timer an und der Teilnehmer gilt als gestört.
Leider lassen sich Ethernet-Prüfsummenfehler mit einer handelsüblichen Netzwerkschnittstelle am PC oder Notebook nicht erfassen.


----------



## SW-Mech (18 Mai 2015)

Meine Antwort ist zwar etwas spät...

Könnte es vielleicht sein, dass die MGB-Elektronik bewusst dieses Signal "flackern" lässt (So nach dem Motto: Das ist kein Bug, sondern ein Feature)?
Wenn man ja sonst Sicherheitselemente mit OSSD-Ausgängen hat, dann wird da normalerweise ein Testimpuls generiert um ein Überbrücken der Ausgänge zu erkennen.
Möglicherweise macht das die MGB-Elektronik mit dem Signal auf dem ProfiNet auch so, damit man weiss, dass das NotAus-Signal plausibel ist.
Vielleicht ist das in der ProfiNet-Konfiguration einstellbar.

Gruss SW-Mech


----------



## rostiger Nagel (18 Mai 2015)

Na ja das eine ist Hardware und soll einen Querschluss ermitteln,
das andere ist Software, da wird doch wohl kein Querschluss in
der Profinet Leitung einen Gefährlichen Zustand herbeiführen. 

Da die Auswertung im Schalter selber sitzt, wird da wahrscheinlich 
garnicht getaketet, weil kein Querschluss zu erwarten ist.


----------



## Lipperlandstern (18 Mai 2015)

SW-Mech schrieb:


> Meine Antwort ist zwar etwas spät...
> 
> Könnte es vielleicht sein, dass die MGB-Elektronik bewusst dieses Signal "flackern" lässt (So nach dem Motto: Das ist kein Bug, sondern ein Feature)?
> Wenn man ja sonst Sicherheitselemente mit OSSD-Ausgängen hat, dann wird da normalerweise ein Testimpuls generiert um ein Überbrücken der Ausgänge zu erkennen.
> ...




Dann sollte das der Support Wissen und es an allen MGBs auftauchen und nicht nur an zweien


----------



## SW-Mech (20 Mai 2015)

rostiger Nagel schrieb:


> Na ja das eine ist Hardware und soll einen Querschluss ermitteln,
> das andere ist Software, da wird doch wohl kein Querschluss in
> der Profinet Leitung einen Gefährlichen Zustand herbeiführen.



Ja, ist klar: Eine Querschlusserkennung braucht man auf dem ProfiNet nicht. Ich dachte da mehr an sowas wie eine Livebit-Überwachung. Aber wie gesagt, es war nur eine Vermutung.

@Lipperlandstern
*ACK*    Der Support sollte das wissen, aber es gibt eben Supporter und Supporter.

Gruss SW-Mech


----------



## Max1101 (2 August 2015)

Hallo,

ich hab auch öfter mal was mit den MGB's zu tun von Euchner und da ich nächste Woche wieder eine in betrieb nehmen muss, schau ich vorher immer mal im Internet ob es Probleme mit den Geräten gibt und wie man diese lösen kann (Arbeitsvorbereitung ;-) ). Mich würde mal interessieren was hier raus gekommen ist? Funktioniert die neue MGB oder konntest du den Fehler anders beheben?

Gruß
Max


----------



## Lipperlandstern (2 August 2015)

Zur Zeit ist es so das ich das Not-Halt-Signal um 250ms verzögere. Seit dem gibt es keine Probleme. Ich hab auch ein Ersatzteil da aber ich komme vorläufig nicht an die Anlage da sie schon im vollen Betrieb ist.


----------

