Nervende Folgefehler 20005 bei Simotion

S

Superkater

Level-2
Beiträge
176
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hätte mal eine Frage an alle Simotionbenutzer:

Wir verwenden seit 4 Jahren die Simotion D4x5 Serie mit den Sinamics S120 Reglern. Was mich nervt sind die vielen unnötigen blöden Fehlermeldungender Simotion, die es eigentlich gar nicht gibt:

Ein Beispiel aus der Praxis:
Bei einen RBG habe ich auf der Fahrachse drei Motoren über Sinamics zusammmengeschaltet (Sollwert Drehzahlregler kommt vom Master). Der Mastermotor positioniert über einen Laser (Leuze AMS 200). Wenn nun der Leuze ausfällt (z.B. Laserstrahl ist ausserhalb des Reflektors), dann kommt nicht ein Drivecklickfehler 20005 für den Laser, sondern sage und schreibe vier 20005 Fehler innerhalb von 200ms.

Zuerst 20005 für den Laser und dann zeitlich gestaffelt für die Meldung 20005 für die Resolver aller drei Motoren (Master, slave und Antipendel) und das obwohl diese ALLE drei in Ordnung sind.

Ich habe aber die drei Achsen NICHT über die Simotion verschaltet, sondern nur mit dem Drehzahlsollwert in der Sinamics.

Hat jemand eine Idee, warum Siemens diese FALSCHEN Fehlermeldungen ausgibt, oder wie man die unterdrücken kann?
 
Hallo,

wo genau kommt der Fehler 20005 und welche Begleitwert hat er?
Sinamics kennt keinen Alarm/Warnung/Fehler/Störung mit der Nummer 20005.
Bei SIMOTION gibt es einen technologischen Alarm mit der Nummer 20005 und der lautet sinngemäß "Gerät gestört (Adresse) (Begleitwert).

Sollte es sich also um den techn. Alarm 20005 im SIMOTION handeln so hat der erst mal gar nichts mit DRIVECLiQ zu tun sondern mit der Schnittstelle TO -> DO.
Wenn der Alarm mehrmals auftritt dann weil es unterschiedliche Schnittstellen des TO's betrifft und die Meldung für jede Schnittstelle ausgegeben werden muss.

Wenn Du für die Antriebe jeweils eine Achse im SIMOTION angelegt hast und dann noch nebenbei im SINAMCIS ein BICO Beziehung hergestellt hast dann kann ich mir gut vorstellen was da passiert.

Ausgangsbasis:
3 Achsen (TO) im SIMOTION (Master, Slave und Antipendel)
3 Antriebe (DO) im SINAMICS (drvMaster, drvSlave und drvAntipendel)
Zwischen drvMaster, drvSlave und drvAntipendel sind per BICO Sollwertverschaltungen angelegt, von denen wissen aber Master, Slave und Antipendel im SIMOTION nichts.
Die Anlage läuft es gibt keine Fehler alles ist gut.
Jetzt tritt am drvMaster ein Fehler auf welcher zu einer Störung 20005 am Master in SIMOTION führt, soweit klar.
Durch die BICO- Verknüpfungen zwischen drvMaster, drvSlave und drvAntipendel kommt es jetzt zu dem Effekt der Störungspropagierung.
Wenn zwischen zwei Antrieben BICO-Verschaltungen gemacht werden so müssen alle Störungen die an Antrieb A auftreten auch von Antrieb B gemeldet werden, auch wenn Antrieb B die Störungsursache gar nicht hat,das ist eine Sicherheitsrichtlinie innerhalb des Systems SINAMICS.
Übertragen auf unseren Fall ergibt das also bei einer Störung von drvMaster die gleiche Störung an drvSlave und drvAntipendel wodurch es zu dem Alarm 20005 an den entsprechenden SIMOTION TO's (Master, Slave, Antipendel) kommt.
Das kann der von Dir beschrieben Effekt sein.
Um das genauer beurteilen zu können bräuchte ich allerdings eine komplette Liste welche Alarme/Störungen anstehen, sowohl an SIMOTION als auch an SINAMICS.

und immer daran denken:
Es gibt keine unnötigen, blöden oder gar falschen Fehlermeldungen, das hat alles schon seinen tieferen Sinn.;)

Gruß
Christoph
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Folgefehler 20005 nerven doch

Hier ist ein Auszug aus dem Logbuch.

Ereignis 21 ist der Störauslöser und ist in Ordnung, denn er ist der Lasersensor auf der Masterachse. Aber das Ereignis 19 und 20 sind schlichtweg FALSCHMELDUNGEN.

................................................................................
Details zum Ereignis: 19 von 405 : 10:20:13:234 23.10.09

Ereignis-ID: 16# F360:BF80
Zusatzinfo 4 / 5: 16# 00 53
Zusatzinfo1 / 2 / 3: 16# 4E25 0000 094A
Technologischer Alarm
DriveAxisTop : Alarm Fehler 20005 : Geraet Typ:1, log. Adresse:472 gestoert. (Bit:0, Gebernummer:0, Grund: 0x4h)
kommendes Ereignis
................................................................................
Details zum Ereignis: 20 von 405 : 10:20:13:234 23.10.09

Ereignis-ID: 16# F360:BF80
Zusatzinfo 4 / 5: 16# 00 53
Zusatzinfo1 / 2 / 3: 16# 4E25 0000 0949
Technologischer Alarm
DriveAxisSlave : Alarm Fehler 20005 : Geraet Typ:1, log. Adresse:408 gestoert. (Bit:0, Gebernummer:0, Grund: 0x4h)
kommendes Ereignis
................................................................................
Details zum Ereignis: 21 von 405 : 10:20:13:230 23.10.09

Ereignis-ID: 16# F360:BF80
Zusatzinfo 4 / 5: 16# 00 53
Zusatzinfo1 / 2 / 3: 16# 4E25 0000 0948
Technologischer Alarm
DriveAxisMaster : Alarm Fehler 20005 : Geraet Typ:1, log. Adresse:322 gestoert. (Bit:0, Gebernummer:0, Grund: 0x5h)
kommendes Ereignis
................................................................................


In der Simotion Hilfe wird eindeutig gesagt, der Fehler 20005 kommt nur dann wenn die Sinmaics erkannt hat, das die Kommunikation zum SMI10 Modul oderr SMC30 Modul gestört ist, oder der externe Geber einen Fehler meldet.

Es gab aber keine Störung an den beiden Achsen "DriveAxisSlave" und "DriveAxisTop". Die beiden Achsen haben nur ein SMI10 Modul mit einem Resolver anseschlossen, und die Inkrementwerte der Resolver sind SUPER und einwandfrei im Trace dargestellt.

Warum zeigt mir die blöde Simotion die Folgefehler 20005 auf der Achse "DriveAxisSlave" und "DriveAxisTop" obwohl dort kein EINZIGER Geber gestört ist oder gestört wurde?
 
Hallo,

aha wie ichs mir dachte.
Die Meldungen haben nichts mit irgendwelchen Gebern zu tun.
Die Meldungen sind alle vom Typ 1, der Aktorschnittstelle, Geber wäre
Typ 2.
Grund 5h ist eine Zusammensetzung aus Grund 1h(Störung am Antrieb) und als Folge davon Grund 4h(Antrieb hat sich abgeschaltet).
Die beiden anderen Alarme kommen aufgrund der von Dir vorgenommenen BICO-Verschaltung, deswegen kommt da auch nur Grund 4h und nich 5h, die Antriebe melden also keine eigene Störung nach oben.
Was für eine Störnummer tritt am ersten Antrieb in SINAMICS auf (Lasersensor)?
Die anderen beiden 20005 Meldungen bekommst Du weg wenn du die BICO- Verschaltung zwischen den Antrieben wieder löscht.

In der Hilfe von SIMOTION zu 20005 werden aber weder SINAMICS noch SMI10 noch SMC30 erwähnt.

Gruß
Christoph
 
Simotion Hilfetext für Fehler 20005

Folgendes steht in der Simotion HILFE unter 20005 (V4.1.2.4)


Ursache

Der Treiber eines physischen Geraetes oder das Geraet selbst ist ausgefallen bzw. gestoert.
Wenn dieser Alarm auftritt, muss die Fehlerursache im externen Geraet (Antrieb bzw. Geber) ausgewertet werden.






Das physische Gerät hinter dem Driveclickkabel ist nun mal ein SMI10 Modul oder ein SMC30 Modul, oder liege ich da falsch?


Nur ist aber im physischen Gerät KEIN Alarm aufgetreten. Das kann ich mit Traces beweisen.


Ich weiß schon, dass ich selbst schuld bin, weil ich die BICO Verdrahtung so gemacht habe, wenn eine der drei Achsen auf Störung geht, die Sinamics das AUS2 auf den anderen Achsen wegnimmt.


Ich muss das aber so machen, weil sonst die Mechanik des RBG kaputt wird wen ein Motor WIRKLICH ausfällt (durch die immense Schräglage des RBG Mast).


Was soll ich jetzt unserem Kunden sagen, wenn EINE Störung auf einer Masterachse kommt aber 4 FEHLERMELDUNGEN anstehen.



Bitte öffne den Scout und schau dir genau den Grund im Paramter X an, bevor du die Hotline anrufst?



Was haben sich eingentlich die Chefentwickler bei Siemens bei diesem Alarmsystem gedacht? Jeder Nutzer ist immer ONLINE mit dem Scout, ODER?


Ich werde jetzt einfach im ExecutionFaultTask mein ST Programm dementsprechend ändern.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Simotion Hilfetext für Fehler 20005

Folgendes steht in der Simotion HILFE unter 20005 (V4.1.2.4)


Ursache

Der Treiber eines physischen Geraetes oder das Geraet selbst ist ausgefallen bzw. gestoert.
Wenn dieser Alarm auftritt, muss die Fehlerursache im externen Geraet (Antrieb bzw. Geber) ausgewertet werden.






Das physische Gerät hinter dem Driveclickkabel ist nun mal ein SMI10 Modul oder ein SMC30 Modul, oder liege ich da falsch?


Nur ist aber im physischen Gerät KEIN Alarm aufgetreten. Das kann ich mit Traces beweisen.


Ich weiß schon, dass ich selbst schuld bin, weil ich die BICO Verdrahtung so gemacht habe, wenn eine der drei Achsen auf Störung geht, die Sinamics das AUS2 auf den anderen Achsen wegnimmt.


Ich muss das aber so machen, weil sonst die Mechanik des RBG kaputt wird wen ein Motor WIRKLICH ausfällt (durch die immense Schräglage des RBG Mast).


Was soll ich jetzt unserem Kunden sagen, wenn EINE Störung auf einer Masterachse kommt aber 4 FEHLERMELDUNGEN anstehen.



Bitte öffne den Scout und schau dir genau den Grund im Paramter X an, bevor du die Hotline anrufst?



Was haben sich eingentlich die Chefentwickler bei Siemens bei diesem Alarmsystem gedacht? Jeder Nutzer ist immer ONLINE mit dem Scout, ODER?


Ich werde jetzt einfach im ExecutionFaultTask mein ST Programm dementsprechend ändern.
 
Hallo,

Das physische Gerät hinter dem Driveclickkabel ist nun mal ein SMI10 Modul oder ein SMC30 Modul, oder liege ich da falsch?

Das ist falsch. Da es sich hier um einen Typ 1 handelt ist es der Antrieb selber welcher eine Störung anstehen hat, nicht der Geber das wäre dann Typ 2. Trace mal das Zustandwort 2 Bit 3 des Antriebs dort wirst du sehen das es von 0 auf 1 geht, der Antrieb also die Störung meldet und nicht der Geber. Externes Gerät ist nicht zwangsläufig auch ein physikalisches Gerät was am DRIVECLiQ hängt, gerade bei SINAMICS mit dem modularen Aufbau ist das nicht immer so leicht nachzuvollziehen.

Warum löst Du die Aufgabe nicht über einen Sollwert Gleichlauf im SIMOTION? Damit sollte das Ganze auch ohne BICO Verschaltung realisierbar sein.

Das Alarmsystem ist gut überlegt.
Du must bedenken das an einer SIMOTION nicht nur ein SINAMICS mit seinem Antriebsmodell dranhängen kann sondern auch noch andere Antriebe deswegen ist ist dies Schnittstelle streng nach dem PROFIDrive Norm implementiert welches eine definierte State-Maschine mit definierten Reaktionen hat und eine davon führt zum Alarm 20005 (Grund 4h), egal ob die jetzt von einem SINAMCIS, SIMODRIVE, MasterDrive, Lenze, Bosch oder sonstwas Antrieb kommt.
Auch die Alarmpropagierung im SINAMICS ist begründet.
Wenn eine Störung am Master nicht zum Slave und Antipendel weitergemeldet werden würde dann würden die noch immer meinen gültige Sollwerte zu bekommen und diese verwenden.
Das kann dann aber ganz böse Folgen habe bis hin zum Anlagenschaden.

Am Besten ist Du sagst eurem Kunden die Wahrheit und setzt ihn über den technischen Zusammenhang in Kenntnis.
Normalerweise liest man sich bei einer Störung die ganzen Informationen aus und speichert sie in einem Log, egal ob man die Hotline anrufen will oder nicht, die Hotline wird sowieso in diesem Falle fragen was für eine Störung im SINAMICS ansteht.
Für sowas verwende ich z.B. immer die Funktion _getDriveFaults, damit protokolliere ich nicht nur die Störmeldungen von SIMOTION sondern auch die aufgetretenen Störungen am Antriebsgerät.

Ob eine Änderung in der ExecutionFaultTask da was bringt wage ich mal zu bezweifeln, der Alarm 20005 kann in der Alarmkonfig nicht mal ausgeblendet werden.


Gruß
Christoph
 
Das Alarmsystem ist nur für Wissenschaflter

Diese Antwort ist gelinde gesagt ein Witz,

"Das Alarmsystem ist gut überlegt. "

Wir hatten 9 Monate einen Siemens-Antriebstechniker im Haus, der selbst über dieses Alarmsystem geschimpft hat.

Wer kann bitte eine Hauptfehlernummer mit bis zu 5 Zusatzparameter, die auch dazu noch HEX kodiert und VERODERT werden, als gutes alarmsystem verteidigen?

Da muss man doch ein Programmierer und Wissenschaflter sein, um den richtigen Fehlergrund herausfinden zu können?

Unsere Kundentechniker in den Lagern sind aber ELEKTRIKER von Beruf. Warum begreift Siemens nicht, dass ihr Alarmsystem viel zu kompliziert geworden ist.

Und überhapt komplette KAKE finde ich die unterschiedlichen Zeitstempel bei Siemens.

1. SINAMICS hat einen eigenen Zeitstempel und übernimmt nicht die Zeit von der Simotion.

2. SIMOTION hat sogar ein anderes DATE_AND_TIME Format als die ganze S7 Familie. Die beginnt mit 1.1.1992 und nicht wie bei der S7 mit 1.1.1990.

3. Den Uhrzeitsync zwischen unserer CP319F und der Simotion D435 habe ich selber machen müssen.

Und das nennt ihr Total Integrated?

Bitte, warum kommt SEW bei ihrem Mehrachsystem Moviaxis mit einer ganz normalen INT16 Nummer als Fehlernummer bei den Antrieben aus, und Siemens nicht?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

man muss weder Programmierer noch Wissenschaftler sein, es reicht schon wenn man Lesen gelernt hat, ich bin auch kein Programmierer oder Wissenschaftler und trotzdem habe ich es verstanden.
Sämtliche Zusammenhänge sind dokumentiert und wenn man die zugrundeliegenden Normen kennt versteht man auch warum es so komplex erscheint.
Man kann ein System einfach gestalten aber dann fällt es schwer es universell zu machen.
SIMOTION und SINAMICS ist nun mal nicht das einzige auf der Welt und wenn ich noch eine Vielzahl anderer Antriebssysteme anbinden können muss dann bleibt kein anderer Weg als über die in den Normen festgelegten Mechanismen.

zu den einzelnen anderen Punkten:

1.) SINAMICS hat keine interne Uhr und zählt deshalb die Betriebsstunden.
Man kann den Sinamics aber auf UTC umstellen und die Zeitstempel
von z.B. SIMOTION an den Antrieb schicken, dann hat man die gleiche
Zeitbasis. Dasselbe Problem hat man auch mit einer S7 und SINAMICS
dort muss man auch die Zeitstempel explizit von der S7 an den Antrieb
übermitteln.

2.) Es ist kein anderes DATE_AND_TIME. Lediglich der verbaute RTC
Baustein beginnt erst bei 1.1.1992. Das liegt daran, daß SIMOTION
erst seit ca. 9 Jahren gebaut wird und die damals erhältlichen RTC
Bausteine alle bei 1992 anfangen. Die S7 gibt es schon länger (vor
1992) und die haben ältere RTC Bausteine die eben ab 1990 ticken.
So wurde mir das mal erklärt.

3.) Das ist unschön das gebe ich zum, nervt mich auch.


Gruß
Christoph
 
Ich kann lesen

Hallo,

ich kann lesen. Ich arbeite auch seit 2 Jahren intensiv mit Simotion und SEW Antriebstechnik.

Seit 25 Jahren programmiere ich alles mögliche, und kenne daher einige Fehlersysteme (Borland, Microsoft, B&R, Allen Bradley usw.). Aber das von der Simotion ist das bescheuerste das ich je gesehen habe.

Ich kenne NIEMANDEN der den genauen Fehlergrund durch eine HEX-Veroderung von Bits bekanntgibt. Alle haben ein gut priorisiertes Nummersytem und untderdücken so gut es geht unnötige Folgefehler.

Fakt ist :
WENN eine LEITACHSE wegen eines Fehlers stehen bleiben muss, sollten die Folgefehler der untergeordneten Achsen unterdrückt werden.

Zur Uhrzeit:
Warum konnten die Simotion Hardwarentwickler nicht den gleichen RTC Baustein verwenden, wie die Step7 Hardwareentwickler?

Mögen sich die nicht gegenseitig, oder redet nur keiner mit dem anderen?
 
Zurück
Oben