Seltsames Phänomen mit VIPA 315/SN und MP277

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute!

Bin grade am tüfteln mit einer VIPA 315/SN.
Bin dabei jetzt auf ein hochinteressantes Phänomen gestoßen.

Vorgeschichte:
Hab heute am morgen eine Siemens 315 2PN/DP durch eine VIPA 315/SN ersetzt (einfach mal zum testen), die HW-Konfig angepasst und das Programm geladen. funktionierte soweit 1A

Später hab ich dann das Projekt des MP277 geändert und eingespielt - siehe da: just zu dem Zeitpunkt, als am Panel die WinCCflexible RT startet, stürzt an der VIPA-CPU der DP-Master ab und startet neu (sprich: Profibus steht für ca. 5 sek).

Zur genauen Konfiguration:
- VIPA 315-4NE12-0110 Firmware 3.4.1
- MP277, WinCCflexible 2005 + SP1 + HF7, Loader V01.00.00.05_01.03
- Panel hängt am Profibus (Adresse 6), Baudrate 1.5 MBit/s, Häkchen "Einziger Master am Bus" ist deaktiviert
- zusätzlich hängen noch 14 DP-Slaves am Profibus
- MPI ist nicht verwendet

Interessanterweise tritt das Phänomen auch dann auf, wenn ich die Online-Kommunikation des Panels mit der CPU auf Ethernet umschalte (Panel bleibt zwar dann am Profibus, allerdings läuft der Datenaustausch mit der CPU über Ethernet).
Im Diagnosepuffer erfolgen die Einträge "STOP wegen Dauer-Prozessalarm" (Ereignis-ID 16#4949) 2 mal hintereinader binnen 2 ms, anschließend "Dezentrale Peripherie: Mastersystemausfall" (Ereignis-ID 16#39C3)

Ach ja: mit der 315-2PN/DP tritt das nicht auf
Hat hier Siemens in sein MP277 was eingebaut zum VIPA-CPU ärgern?

Vielleicht hat ja schon mal jemand ein ähnliches Phänomen gehabt, oder die Leute von VIPA wissen mehr dazu.
Kurzfristig kann ich mir behelfen, indem ich die Online-Kommunikation auf Ethernet umstelle und das Panel physikalisch vom Profibus trennen, allerdings brauche ich eine Lösung, da in ca. 3-4 Wochen die ersten Tests mit OP177 fällig sind, und da hängt das Panel definitiv am Profibus.


Danke schon mal im voraus.

mfg Maxl

 

[Ralle]

Für die VIPA wird ja eine 318 in der Hardwarekonfig projektiert. Ich hatte ähnliche Probleme nach einem CPU-Tausch, Ursache war in diesem Fall das PNOZMULTI. Außerdem wurde ein DP-Manufacture-Alarm ausgelöst, welcher dann zum Stop führte. Bei meinem letzten Projekt habe ich dann die 318 mit V3.0 in der Hardwarekonfig installiert und bei den DP-Eigenschaften des Profibusses unter Betriebsart/DP-Mode "S7-kompatibel" gewählt. Außerdem OB57 und OB122 in die SPS-übertragen. Zumindest gab es keine Probleme mehr, allerdings kann ich jetzt nicht aus dem Stehgreif sagen, ob die Alarme weg waren, oder nur keinen "Schaden" mehr angerichtet haben.

PS: Vermute, es liegt eher an einer neueren VIPA-FW, die einfach mehr kann, als die Vorversion.

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für die VIPA wird ja eine 318 in der Hardwarekonfig projektiert. Ich hatte ähnliche Probleme nach einem CPU-Tausch, Ursache war in diesem Fall das PNOZMULTI. Außerdem wurde ein DP-Manufacture-Alarm ausgelöst, welcher dann zum Stop führte. Bei meinem letzten Projekt habe ich dann die 318 mit V3.0 in der Hardwarekonfig installiert und bei den DP-Eigenschaften des Profibusses unter Betriebsart/DP-Mode "S7-kompatibel" gewählt. Außerdem OB57 und OB122 in die SPS-übertragen. Zumindest gab es keine Probleme mehr, allerdings kann ich jetzt nicht aus dem Stehgreif sagen, ob die Alarme weg waren, oder nur keinen "Schaden" mehr angerichtet haben.

PS: Vermute, es liegt eher an einer neueren VIPA-FW, die einfach mehr kann, als die Vorversion.

Also, in der HW-Config ist das Ding als 318 V3.0 projektiert - wie im Handbuch von VIPA vorgegeben. Ein PnozMulti ist ebenfalls am Profibus dran (ist übrigens das einzige Teil, welches ich noch nicht abgekoppelt hatte). Das Umstellen auf S7-kompatibel hatte ich auch schon probiert, allerdings ohne Unterschied (außerdem möchte ich die DPV1-Funktion nutzen). OB122 und OB57 (den kenne ich gar nicht) hab ich nicht drin, kann ich aber morgen testen. Ansonsten muss ich mich wohl mit VIPA in Verbindung setzen.

mfg Maxl

 

[Maxl]

VIPA ist schon an der Sache dran..........

 

[Ralle]

Ah, gut, ich hatte das bereits im Dez. 2007 an VIPA (na ja, über unseren Vertreter) gemeldet, aber nie eine Antwort bekommen. Irgendwie hab ich das dann nicht konsequent verfolgt, weil es (zumindest bei mir) mit den OBs, keine Probleme mehr gab. Halt uns mal bitte auf dem Laufenden.

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ah, gut, ich hatte das bereits im Dez. 2007 an VIPA (na ja, über unseren Vertreter) gemeldet, aber nie eine Antwort bekommen

Ich habe ich mir angewohnt, mich bei solchen Problemen direkt mit dem Support der Herstellerfirma in Verbindung zu setzen. Das klappt in der Regel sehr gut und die Reaktionszeiten sind meist auch so am schnellsten. Einzige Ausnahme ist hier Siemens - einerseits weil unser Vertreter Top drauf ist - andererseits weil er wesentlich schneller Lösungen präsentiert als die Hotline.


zurück zum Thema:

VIPA hat auf jeden Fall zu erkennen gegeben, dass man die Ursache des Problems in jedem Fall so schnell wie möglich finden möchte. Im Moment wird die Problemkonstellation nachgebaut.

Das von mir als "Abstürzen" beschriebene Phänomen dürfte ein gezieltes Herunterfahren des Profibus-Controllers aufgrund eines schwerwiegenden (physikalischen) Fehlers am Bus. Es scheint so, als ob das Siemens-Panel beim Hochlaufen der Runtime irgendwelchen Unsinn am Profibus anstellt (Kurzschluss erzeugt oder irgendsowas). Durch Deaktivieren der Token-Überwachung (sprich: die Kurzschlusserkennung die man ohnehin nicht braucht) ließ sich zumindest das Herunterfahren des Profibus-Master unterbinden - dennoch kommt es am Profibus zu so massiven Störungen, dass einige Slaves ausfallen.

Mit einem neueren Image des Siemens-Panels ließ sich der Fehler nicht reproduzieren - dürfte wohl ein neuerer Profibus-Treiber zum Einsatz kommen.
Wie gesagt, VIPA baut die Konstellation (mit genau den Versionen und derselben Software) derzeit auf. Ich rechne in den nächsten Tagen mit Neuigkeiten.
Wie gesagt, es sieht eher nach einem Treiberproblem des Panels aus.

mfg Maxl


PS: also eins muss man den Vipanern lassen - Reaktionszeit: 1A

 

[Ralle]

Ja, ich hätte auch besser direkt den Support kontaktieren sollen. Hast du die Sache mit dem Manufacture_Alarm auch mal abgefragt? Der kommt bei mir definitiv vom PNOZMULTI, kann man an der angegebenen Diagnoseadresse erkennen.

 

[Maxl]

Manufacture_Alarm kommt bei mir keiner an. Habs zwar den OB reingespielt, machte aber keinen Unterschied.

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

So, Neuigkeiten von VIPA:
Bei VIPA im Labor ist die Konfiguration (mit original Software auf CPU) nachgestellt worden, da tritt der Effekt nicht auf.

Hatte dann noch kurz Zeit (bzw. mein Kollege), dem Tipp von Ralle nachzugehen. Also: Auch das PnozMulti vom Bus weggenommen (war der einzige Slave bei meinen letzten Tests, der physikalisch noch am Bus war) und siehe da: der Effekt tritt nicht auf. Für weitere Tests reichte die Zeit heute nicht, musste kurzfristig zu einem Kunden.

Weitere News wirds morgen oder am Donnerstag geben.

mfg Maxl


PS: Die Theorie mit den PnozMulti kriegt insofern relevanz, da wir anfang des jahres schon mit einem Profibus-Master von B&R massive Probleme hatten. Hier wurden Daten eines Slaves verfälscht - das Tauschen des betroffenen Slaves und auch des Masters brachten keinen Erfolg. Erst als wir die Profibus-Karte des PnozMulti abgestöpselt hatten, war das Problem weg. Nach dem Austausch der Profibus-Baugruppe am PnozMulti war das Problem endgültig weg.
PPS: werd mir auch die Geschichte mit dem Manufacture_Alarm nochmals genauer ansehen.

 

[Maxl]

Also..............

Am PnozMulti liegts definitiv nicht. Auch wenn ich das PronzMulti ausstecke und alle anderen Slaves am Bus belasse, tritt das Problem nach wie vor auf.

ABER:
Hab jetzt das MP277 mit Flash-Version 1.0.0.0 (vorher wars 1.0.0.5) geflasht - jetzt tritt das Phänomen nicht mehr auf.
Jetzt gibts also nur noch 2 Möglichkeiten:
- entweder ist beim Flashen des Panels was schiefgelaufen
- oder: der Profibus-Treiber in Version 1.0.0.5 ist fehlerhaft.

Werd (wenn's die Zeit erlaubt) morgen nochmal 1.0.0.5 raufladen und nochmal testen. Außerdem möchte ich mir noch mal das Zusammenspiel mit der Siemens-CPU ansehen. Zuletzt wäre noch (auf Telegrammebene) interessant, was da am Profibus wirklich abgeht.

mfg Maxl

 

[Ralle]

Ok, in diesem Zusammenhang bekam ich gestern eine Mail:

...

wir hatten im Dezember 2007 mal das Thema, dass die VIPA 315SB CPU einen Dauerprozessalarm auslöst.

Nun kann ich Ihnen mitteilen, dass dieser Fehler auf eine falsche Interpretation eines Profibusteilnehmers zurück zu führen ist. Hier lag das Übel im Bereich vom DP-V1 Protokoll.

Mit der neuesten Firmware:

CPU Firmware Version 3.41
DP-Master Firmware 3.19 (wichtig!!)

Sollte das Problem behoben sein.

...

Es geht also nichts verloren, kann halt mal etwas dauern, war ja nicht so dramatisch. Muß ich unserem Vertreter wohl doch etwas Abbitte leisten.

Leider komme ich in nächster Zeit nicht an die Anlage, aber die läuft eh volle Pulle.


PS: @Maxl

Kann sein, daß der Manufacture_Alarm kam, wenn am PNOZMULTI ein Fehler auftrat, z.Bsp. die Gleichzeitigkeitsüberwachung von Sicherheitskontakten. Das ist ja im Prinzip ok so, aber ohne den OB57 ... Vielleicht kannst du das einmal nachstellen, ich kann mich dunkel erinnern, daß da die SPS in Stop ging.

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS: @Maxl

Kann sein, daß der Manufacture_Alarm kam, wenn am PNOZMULTI ein Fehler auftrat, z.Bsp. die Gleichzeitigkeitsüberwachung von Sicherheitskontakten. Das ist ja im Prinzip ok so, aber ohne den OB57 ... Vielleicht kannst du das einmal nachstellen, ich kann mich dunkel erinnern, daß da die SPS in Stop ging.

Wir setzen viele PnozMultis ein, bei keiner SPS ist der OB57 vorhanden. Gleichzeitigkeitsfehler und andere Fehler sind schon häufig aufgetreten (bzw. provoziert worden) - die CPU ging nie in Stop. Ich vermute also einfach eine defekte PnozMulti Anschaltung.


Zurück zum Thema:

VIPA hat mir zugesagt, mir eine Profibus-Analyzer Software leihweise zuzuschicken. Dann werde ich mir mal ansehen, was auf dem Bus wirklich abgeht.



[OT]Vielleicht kann mir jemand von VIPA ein kurzes Statement dazu geben: Ab wann (und in welcher Form) darf ich mit EtherCat-Unterstützung durch die Speed7 CPUs rechnen. Im Jänner war ja schon in den News davon zu lesen, nur konkretes finde ich bis jetzt nicht auf der Homepage[/OT]



mfg Maxl

 

[Maxl]

So, hab mich heute mit dem Telegramm-Analyzer an den Bus gehängt. Einige Erkenntnisse konnte ich dabei schon sammeln.

1. War am Panel die Image-Version 1.0.0.0 installiert, so tritt das Problem nicht auf.
2. Hab nun das Panel wieder auf Image-Version 1.0.0.5 geflasht und das komplette Projekt draufgespielt. Interessanterweise war der Fehler auch hier nicht mehr reproduzierbar.
3. Hab daher wieder das 2. Panel (welches ich letzte Woche schon mal kurz an den Bus gehängt hatte um zu sehen, obs am Panel liegt) an den Bus gehängt: siehe da - Fehler lässt sich reproduzieren.

So, nun Fehlerhafte Telegramme gesucht. Hier bin ich dann mit meinem Know-How ziemlich am Ende. Der Analyzer liefert zwar "Fehlertelegramme" und ein paar Details dazu, allerdings kann ich mit den Daten nicht ganz vo viel anfangen.
Es sieht aber so aus, als ob tatsächlich ein Teilnehmer hier ungefragt, komplett außerhalb des Protokolls einfach was auf den Bus legt. Ob das nun ein Kurzschluss ist, oder sinnlose Datenpakete lässt sich nicht sagen. Am besten werde ich diese Daten morgen mal weitergeben.

mfg Maxl

 

[Maxl]

Um die Geschichte nun zum Abschluss zu bringen (vorweg: ich bin bei den Profibus-Internas kein Profi):

Die Telegrammaufzeichnung wurde bei VIPA analysiert. Es sieht also so aus, als ob das MP277 am Profibus einen Kurschluss erzeugt bzw. einfach Sch.... auf den Bus wirft. Die "Telegramme" haben unterschiedliche längen - der Sniffer kann damit nichts anfangen - somit der profibus-Master auch nicht. Die Fehler am Bus sind auch bei Einsatz einer Siemens-CPU messbar.
Der wesentliche Unterschied liegt hier in der Erkennung und Behandlung des Fehlers.

Der VIPA Master setzt dabei eine Funktion Names "Tokenwatch" ein. Diese prüft, ob der Token korrekt zwischen den Teilnehmern hin und hergegeben wird. Tritt dabei ein Fehler auf (z.B. Kurzschluss), wird der Master Not-heruntergefahren und neu gestartet. --> diese Funktion sind die von mir beobachteten "Abstürze".
Die Funktion "Tokenwatch" bietet die Siemens-CPU offenbar nicht - bei VIPA ist sie per Default eingeschaltet.

Wird der Tokenwatch nun abgeschaltet (sprich: Annäherung an das Verhalten der Siemens-CPU), tritt dieses Not-Herunterfahren nicht mehr auf. Allerdings bleibt das Phänomen, dass 3-4 DP-Slaves kurz "Station Ausfall" und kurz danach "Station Wiederkehr" melden. Der Unterschied dürfte in einer unterschiedlichen Fehlerbehandlung liegen. Die VIPA-CPU trägt sofort, nachdem ein Teilnehmer auf einen Data-Request nicht antwortet, einen Fehler ein - die Siemens-CPU hingegen schweigt sich über einzelne Fehler aus und macht knallhart weiter.


Fazit:

Die Ursache ist mit ziemlicher Sicherheit in einem fehlerhaften Treiber am MP277 zu suchen. Es sieht so aus, als ob die Panels, wenn sie ausgeliefert werden, andere Treiber mitbringen als wenn man nachträglich ein Betriebssystem-Image lädt. Der Fehler ist nach wie vor nur mit "neuen" Panels mit Image-Version 1.0.0.5 reproduzierbar, auf die nach dem Einbau noch kein "neues" Image geladen wurde.

Die Siemens-CPU "verschluckt" kurze Fehler am Profibus. Das mag zwar augenscheinlich toll sein wenn die BUSF-LED nicht aufflackert, allerdings tritt nachweislich ein Fehler auf und ein oder mehrere DP-Slaves liefern kurrzeitig (im ms-Bereich) keine gültigen Daten. (was das bedeutet, darf jeder für sich selber interpretieren).

Dass die VIPA-CPU hier so schnell reagiert und einen Fehler meldet, ist zwar lästig - aber es wird wieder mal vorgeführt, dass am Profibus doch nicht alles so glatt läuft. Die Geschichte mit dem Tokenwatch macht die Sache noch etwas verwirrender. Hier hilft schlicht und einfach abschalten! (optimal wäre es, wenn der Tokenwatch per Default abgeschaltet ist).

Danke an Vipaner_112 und das VIPA-Team für die rasche Unterstützung.


Auswirkungen:

Bis VIPA-CPUs bei uns bei Projekten zum Einsatz kommen könnten, werden wohl alle Siemens-Panels mit Image-Versionen für WinCCflex 2007 ausgeliefert werden. Ich bin guter Hoffnung, dass das Treiberproblem bei diesen Images nicht mehr besteht. Da wir noch immer Flex 2005 einsetzen, werden wir ohnehin zum Image-Downgrade gezwungen, womit dann auch immer eine fehlerfreie 1.0.0.5-Version geladen wird.
Abgesehen davon spricht bei einer VIPA-CPU auch nichts dagegen, die MP277 generell per Ethernet an die CPU zu koppeln.

Meine Empfehlung an die Projektleiter lautet in jedem Fall, bei geeigneten Projekten (wo der Kunde es zulässt) VIPA-CPUs einzusetzen, denn die Fakten sprechen für sich (hab schließlich neben den Profibus-Messungen auch einige Maschinen-Programme auf der CPU laufen lassen).

1. S7 315-2PN/DP durch 315SN ersetzt
vorher 18-20 ms Zykluszeit
nachher 3-4 ms Zykluszeit

2. weitere 315-2PN/DP durch 315SN ersetzt
vorher 38-40 ms Zykluszeit
nachher 5 ms Zykluszeit

3. probeweise das Programm eines Bearbeitungszentrums (319-3PN/DP) auf die CPU geladen (Hardware-Umbau ging nicht, da bei 319 2 Profibus-Stränge genutzt werden)
Zykluszeit S7 319: 6 ms
Zykluszeit VIPA 315-SN: 7 ms

Die CPU kann sich also problemlos mit einer 319 messen - zumindest bei der Geschwindigkeit. Mir ist noch aufgefallen, dass die VIPA ihren Geschwindigkeitsvorteil aber nur dann richtig ausspielen kann, wenn die Siemens-CPU bereits sehr hohe Zykluszeiten > 10 ms hat. Eine Anwendung, bei der die Siemens-CPU eine Zykluszeit von 2-3 ms schafft, kann durch die VIPA kaum noch beschleunigt werden.


Also dan, schönes Wochenende.

mfg Maxl