CU320 Sinamics S120 - Beziehung von Fehler- & Statuscodes in der SPS

L4s3r73k · 21 September 2018

Hallo zusammen,

ich bin ganz neu hier und komme, wie wahrscheinlich die Meisten, durch ein Problem hier rein.
Wie dem auch sei, ich mache SPS noch nicht lange, brauche jetzt aber Hilfestellung bei einer kleinen Aufgabenstellung.
Ein funktionierendes Maschinenprojekt in TIA V15 mit Startdrive Advances mit zwei CU320-2 PN und insgesamt 7 Achsen besteht bereits.

Meine Aufgabe ist nun der SPS seitige Bezug und Ablage und Weitergabe der Fehlercodes im Fehlerfall.
Bisher hatte ich wenig bis gar keine Berührungspunkte mit den Funktionen WRREC und RDREC sowie Siemens antrieben.
Ich habe ein paar Screenshots gemacht, um nach meinem Verständnis mögliche Angriffspunkte zu liefern und um die aktuelle Config ein wenig festzuhalten.

Was ich im Laufe meiner Recherchen wohl schon gelernt habe (oder glaube zu haben):

1. Es gibt Stör- (p0945) und Warnpuffer (r2122) die über SFC52 und SFC53 (WRREC & RDREC) ausgelesen werden können sollen.
2. Gleiches gilt für den aktuellen Warncode r2132.
3. Fehler sind in Bitfeldern angegeben, jedes Bit hat eine eigene Bedeutung, oder sind es doch Codes!?

Zu
1: Wenn dem so ist, welche HW Nummer gebe ich dann den SFCs?
3: Man ging hier davon aus, dass Siemens Codes hat anstatt einzelne Bits in einem Bitfeld die eigene Bedeutungen haben.
Wenn es ein Code ist, wo finde ich die Übersetzung?

Es ist ja nicht so, als hätte ich noch nie Motoren programmiert. Bisher reichte es aber mit dem PAA und dem PAE der SPS zu arbeiten.

Viele Grüße,

Dennis

ChristophD · 21 September 2018

Hi,

mit HW Nummer meinst Du die HW ID als input zum SFB?
Wenn ja must du die HW ID Des Antriebs nehmen der die Störung hat (bei dir der jeweilige Telegram 2 Slot).
Fehler sind als Code abgelegt, ebenso die Alarmparameter, gleiches gilt für Warnungen.

Die Frage ist jetzt:
Was willst Du im PLC Program damit machen?
Wenn Du die Antriebe mit technologiobjekten verschaltest dann machen die das Fehlerhandling entsprechend.
Oder geht es um Anzeige an HMI?

Gruß
Christoph

TheLevel · 21 September 2018

Hallo Dennis,

wenn du nicht den ganzen Puffer, sondern nur die aktuell anstehende Warnung und/oder Störung je Achse auslesen musst, geht das am komfortabelsten mit einem Standard-Telegramm wie z.B 352 bei einfachen Drehzahl-Anwendungen oder 111 beim Einfachpositionierer. Wie machst du denn die Ansteuerung der Achsen?

Es gibt zunächst die Warn- oder Fehlernummer, die du auch als Nummer bekommst. Bei einigen Meldungen gibt es zusätzlich noch weitere Informationen, die ihrerseits ein numerischer Wert oder ein Bitfeld sein können. Für die Fehlernummern gibt es auch passende XML-Dateien, mit denen du in der Visu wieder den passenden Text zum Fehler anzeigen kannst.

L4s3r73k · 21 September 2018

Vielen Dank für die schnellen Antworten.

Der Einfachheit halber kommentiere ich in rot in euren Text hinein.

ChristophD schrieb:
Hi,

mit HW Nummer meinst Du die HW ID als input zum SFB?
Genau.
Wenn ja must du die HW ID Des Antriebs nehmen der die Störung hat (bei dir der jeweilige Telegram 2 Slot).
Telegramm 2 Slot? Wo? Wie? Kannst du das markieren?
Fehler sind als Code abgelegt, ebenso die Alarmparameter, gleiches gilt für Warnungen.
Okay, und wo bekomme ich eine Liste mit den Bedeutungen?

Die Frage ist jetzt:
Was willst Du im PLC Program damit machen?
Ganz einfach, die Codes sollen an eine HMI weiter geschleust werden und in Sprache übersetzt werden.
Wenn Du die Antriebe mit technologiobjekten verschaltest dann machen die das Fehlerhandling entsprechend.
Oder geht es um Anzeige an HMI? Genau.

Gruß
Christoph

TheLevel schrieb:
Hallo Dennis,

wenn du nicht den ganzen Puffer, sondern nur die aktuell anstehende Warnung und/oder Störung je Achse auslesen musst, geht das am komfortabelsten mit einem Standard-Telegramm wie z.B 352 bei einfachen Drehzahl-Anwendungen oder 111 beim Einfachpositionierer. Wie machst du denn die Ansteuerung der Achsen?
Bezieht die die 352 auf eine Zahl aus meinen Screenies oder ist das eine Zahl die in jedem Projekt gleich ist? Die Ansteuerung der Achsen ist nicht mein Werk.
Hier ist Siemens nicht so beliebt, deswegen soll ich jetzt schauen, wie man aussagekräftige Fehler und Statuscodes ans HMI bekommt um dem Kunden mehr als "Fehler Antrieb" anzeigen zu können.

Es gibt zunächst die Warn- oder Fehlernummer, die du auch als Nummer bekommst. Bei einigen Meldungen gibt es zusätzlich noch weitere Informationen, die ihrerseits ein numerischer Wert oder ein Bitfeld sein können. Für die Fehlernummern gibt es auch passende XML-Dateien, mit denen du in der Visu wieder den passenden Text zum Fehler anzeigen kannst.
Exakt sowas ist angedacht.

TheLevel · 21 September 2018

Hätte ich mal auf dem Bild richtig gelesen, hätte ich die Telegramm-Nummer gesehen

Also, es wird in deinem Programm das Standard-Telegramm 3 benutzt, da steht tatsächlich keine Nummer von Warnungen oder Fehlern drin. Den dazu gehörigen Slot meinte ChristopD auch in seinem Post (also z.B. bei deiner T1 X-Achse gehört zum Telegramm 3 die ID 386).
Ohne jetzt zu wissen, was wie und wo mit dem Telegramm passiert, würde ich jetzt natürlich davon Abstand nehmen, dieses durch ein anderes zu ersetzen.

Unabhängig vom Telegramm gibt es noch andere Möglichkeiten, an die gewünschte Information zu kommen, z.B. über den Parameterkanal mit dem SINA_PARA oder SINA_PARA_S aus der Drive_Lib in deiner globalen Bibliothek. Damit kommst du dann auch an die Historie.

ChristophD · 21 September 2018

Hi,

genau der Slot mit Telegramm 3 war gemeint.
Also ich würde da gar nix im PLC Programm machen um das an die HMI zu melden, da kann schön die HMI selber machen:

https://support.industry.siemens.com/cs/ww/de/view/47520881
https://support.industry.siemens.com/cs/ww/de/view/109481157
https://support.industry.siemens.com/cs/ww/de/view/74875007

Gruß
Christoph

L4s3r73k · 21 September 2018

ChristophD schrieb:
Hi,

genau der Slot mit Telegramm 3 war gemeint.
Also ich würde da gar nix im PLC Programm machen um das an die HMI zu melden, da kann schön die HMI selber machen:

https://support.industry.siemens.com/cs/ww/de/view/47520881
https://support.industry.siemens.com/cs/ww/de/view/109481157
https://support.industry.siemens.com/cs/ww/de/view/74875007

Gruß
Christoph

Danke Christoph, aber ich denke das wird nichts, da wir keine HMI's von Siemens benutzen hier.
Die Kollegen der Hochsprachenprogrammierung machen die Visualisierungen (C# und .NET) die auf Industrie PCs (IPCs) laufen.
WinCC und Siemens Lösungen fallen da wohl weg.

TheLevel schrieb:
Hätte ich mal auf dem Bild richtig gelesen, hätte ich die Telegramm-Nummer gesehen
Also, es wird in deinem Programm das Standard-Telegramm 3 benutzt, da steht tatsächlich keine Nummer von Warnungen oder Fehlern drin. Den dazu gehörigen Slot meinte ChristopD auch in seinem Post (also z.B. bei deiner T1 X-Achse gehört zum Telegramm 3 die ID 386).
Ohne jetzt zu wissen, was wie und wo mit dem Telegramm passiert, würde ich jetzt natürlich davon Abstand nehmen, dieses durch ein anderes zu ersetzen.

Unabhängig vom Telegramm gibt es noch andere Möglichkeiten, an die gewünschte Information zu kommen, z.B. über den Parameterkanal mit dem SINA_PARA oder SINA_PARA_S aus der Drive_Lib in deiner globalen Bibliothek. Damit kommst du dann auch an die Historie.

Dieses beispielhaft genannte Telegramm ID 386 lese ich mit RDREC aus? Was steht dann genau da drin?
Ich habe den Nachmittag damit verbracht erst einmal die grundsätzliche Motoransteuerung zu checken.
Also die typischen FBs von Siemens wie MC_HALT, MC_POWER, MC_HOME etc pp werden verwendet, die ja auch schon Errors ausgeben. Wobei ich nicht glaube, dass die jetzt hier gefragt sind.

Bitte helf(t) mir ein wenig laufen. Bisher reichte es, nicht Siemens Motoren mit vorgegebener Geschwindigkeit, vor- oder rückwärts laufen zu lassen.

TheLevel · 21 September 2018

Die Variante mit dem HMI direkt auf den FU zuzugreifen war mit bisher unbekannt, ist gar nicht uninteressant. Und wenn die Kollegen ihren HMI Zugriff per S7-kommunikation machen, könnte der Weg von Christoph auch mit nicht-Siemens HMIs funktionieren....

Ich denke, in deinem Fall werden die Achsen als Technologie-Objekte benutzt, dabei kommuniziert die SPS mit dem FU mit Hilfe von besagtem Telegramm 3. Die Error-Nummern, die aus den MC_xxxx Bausteinen kommen sind die vom Technologie-Regler, nicht die von der Achse selbst.

Also entweder den Kollegen von der HMI-Abteilung den Auftrag zuschieben und ab ins Wochenende oder mal einen Blick auf den von mir genannten SINA_PARA werfen (der ist auch gut dokumentiert).

Oder jemand anders hat noch eine ganz andere Idee..?

kafiphai · 21 September 2018

HMI Direktzugriff:

S7-Verbindung zu CU320
Variable: DB Nummer=Parameter Nummer(21510)
Adresse: 1024*Antriebs Obj. Nummer + Index(Parameter, bei CFC immer 0)
--> zB.: r25230: %DB25230.DBD2048 (absoluter Zugriff)

Stör- und Meldepuffer(verwendet intern auch WRREC & RDREC):

FB DEV_FLT4: Störungspuffer eines SINAMICS G/S auslesen

und für die Warnungen kopierst du den FB und änderst darin:

Code:

#sx_SEND_FA.si_PARA_NO1 := 947;                                  // Parameternummer: 947 (Stoernummer)

auf

Code:

#sx_SEND_FA.si_PARA_NO1 := 2110;                                // Parameternummer: 2110 (Warnnummer)

Busy und Done bei Abfrage verwenden...
Und bei der Verarbeitung die Bits für Fault/Error aktiv beachten.
Der Meldepuffer wird "seltsam" aktualisiert, kann also sein , dass im Puffer noch eine Meldung steht, aber keine mehr aktiv ist.

Ein Weg....

Lg
Peter

L4s3r73k · 24 September 2018

TheLevel schrieb:
Die Variante mit dem HMI direkt auf den FU zuzugreifen war mit bisher unbekannt, ist gar nicht uninteressant. Und wenn die Kollegen ihren HMI Zugriff per S7-kommunikation machen, könnte der Weg von Christoph auch mit nicht-Siemens HMIs funktionieren....

Ich denke, in deinem Fall werden die Achsen als Technologie-Objekte benutzt, dabei kommuniziert die SPS mit dem FU mit Hilfe von besagtem Telegramm 3. Die Error-Nummern, die aus den MC_xxxx Bausteinen kommen sind die vom Technologie-Regler, nicht die von der Achse selbst.

Also entweder den Kollegen von der HMI-Abteilung den Auftrag zuschieben und ab ins Wochenende oder mal einen Blick auf den von mir genannten SINA_PARA werfen (der ist auch gut dokumentiert).

Oder jemand anders hat noch eine ganz andere Idee..?

Danke, dir. Ich bin tatsächlich ins Wochenende gegangen und hatte dann auch keine Zeit mehr gefunden nachzusehen, obwohl mich das Thema natürlich interessiert.

kafiphai schrieb:
HMI Direktzugriff:

S7-Verbindung zu CU320

Variable: DB Nummer=Parameter Nummer(21510)

Adresse: 1024*Antriebs Obj. Nummer + Index(Parameter, bei CFC immer 0)

--> zB.: r25230: %DB25230.DBD2048 (absoluter Zugriff)

Stör- und Meldepuffer(verwendet intern auch WRREC & RDREC):

FB DEV_FLT4: Störungspuffer eines SINAMICS G/S auslesen

und für die Warnungen kopierst du den FB und änderst darin:

Code:

#sx_SEND_FA.si_PARA_NO1 := 947; // Parameternummer: 947 (Stoernummer)

auf

Code:

#sx_SEND_FA.si_PARA_NO1 := 2110; // Parameternummer: 2110 (Warnnummer)

Busy und Done bei Abfrage verwenden...
Und bei der Verarbeitung die Bits für Fault/Error aktiv beachten.
Der Meldepuffer wird "seltsam" aktualisiert, kann also sein , dass im Puffer noch eine Meldung steht, aber keine mehr aktiv ist.

Ein Weg....

Lg
Peter

Vielen Dank Peter für deinen Lösungsansatz.
Ich hab zwar noch nicht so alles verstanden, was da zu tun ist, aber ich denke du hat "den richtigen Weg" aufgezeigt.
Grundsätzlich: Die IPCs sind via Ethernet/Profinet an der SPS angeschlossen und "saugen" sich die Daten im firmennormierten Normalfall aus einem bestimmten DB.
Natürlich ist und muss die PLC dafür entsprechend parametriert sein. Auf anderen Speicherbereichen der SPS hat der Visu PC nichts zu suchen.
Fehler und Status-Nummern müssen also von der SPS auf diesen DB kopiert werden.
Um auf deinen Lösungsansatz zu kommen Peter, ich finde diesen FB DEV_FLT4 nicht. Wird der von Siemens nicht mitgeliefert?

Dein Beispiel von ganz oben verstehe ich nicht ganz. Du sagst DB Nummer = Parameter Nummer 21510 und zwei Zeilen tiefer r25230 -> DB25230, ein Versehen?

Grüße

Edit #1: Gefunden

Edit #2: Ernsthaft? Siemens PW für den KnowHow Schutz ist 1234?

ChristophD · 24 September 2018

Hi,

dev_FLT4 wird mit startdrive installiert.
Unter bibliotheken findest du dort die DriveLib und darin dann diesen FB

Gruß
Christoph

L4s3r73k · 24 September 2018

ChristophD schrieb:
dev_FLT4 wird mit startdrive installiert.
Unter bibliotheken findest du dort die DriveLib und darin dann diesen FB

Moin. Es ist Montag Morgen und ich bin noch nicht ganz wach. Hatte das kurz nach meinem Post auch gefunden. :roll:
Hab jetzt mit dem FB gemacht, was Peter meinte. Sprich, kopiert und umgebaut für die Warnungen auch.
War kurz davor schon einen nächsten Post auf zumachen für das PW von dem Siemens KnowHow Schutz. Aber 1234 hat geholfen.

Edit:

Eingang LADDR bzw. HW_IO von diesen Bausteinen wären dann also jeweils die "Telegramm 3" IDs?

L4s3r73k · 24 September 2018

Der Siemens Guru ist gerade im Büro eingetroffen und hat mir neuen Input zu der Aufgabenstellung gegeben.
Laut Ihm hat im Störungsfall der Sinamics Baustein immer mehrere Fehler gleichzeitig anstehen.
Das entspricht so ein bisschen der Logik, die ich diesem Thread hier entnehme.
Vielleicht doch mit dem Sina_Para Baustein arbeiten. Arrays anstatt Einzeldate auslesen und in den HMI DB schieben?

TheLevel · 24 September 2018

L4s3r73k schrieb:
Eingang LADDR bzw. HW_IO von diesen Bausteinen wären dann also jeweils die "Telegramm 3" IDs?

Jawohl.

L4s3r73k schrieb:
Der Siemens Guru ist gerade im Büro eingetroffen und hat mir neuen Input zu der Aufgabenstellung gegeben.
Laut Ihm hat im Störungsfall der Sinamics Baustein immer mehrere Fehler gleichzeitig anstehen.
Das entspricht so ein bisschen der Logik, die ich diesem Thread hier entnehme.
Vielleicht doch mit dem Sina_Para Baustein arbeiten. Arrays anstatt Einzeldate auslesen und in den HMI DB schieben?

Ich würde sagen nicht immer, aber natürlich kann das passieren.
Aber insbesondere dann ist der DEV_FLT4 hilfreich (Danke übrigens an kafiphai, den Baustein kannte ich noch nicht). Dieser gibt dir, wie ich das sehe, die letzten 8 Meldungen inclusive der erweiterten Fehlerinfo.

ChristophD · 24 September 2018

was meint er damit das der Baustein mehrere Fehler anstehen hat?

kafiphai · 24 September 2018

Dein Beispiel von ganz oben verstehe ich nicht ganz. Du sagst DB Nummer = Parameter Nummer 21510 und zwei Zeilen tiefer r25230 -> DB25230, ein Versehen?

Ja, ein versehen...

Habe aktuell gerade ein Projekt mit SINA_PARA, wie von TheLevel in #5 beeschrieben gelöst.
Auch schön...

TheLevel · 24 September 2018

kafiphai schrieb:
Habe aktuell gerade ein Projekt mit SINA_PARA, wie von TheLevel in #5 beeschrieben gelöst.
Auch schön...

Viele Wege

Aber gibt es zu dem DEV_FLT4 auch eine "richtige" Doku? Ich habe ein Handbuch zu der Drive-Lib, da stehen aber nur die SINA_???? beschrieben....

L4s3r73k · 24 September 2018

TheLevel schrieb:
Ich würde sagen nicht immer, aber natürlich kann das passieren.
Aber insbesondere dann ist der DEV_FLT4 hilfreich (Danke übrigens an kafiphai, den Baustein kannte ich noch nicht). Dieser gibt dir, wie ich das sehe, die letzten 8 Meldungen inclusive der erweiterten Fehlerinfo.

Also seine Aussage war, dass wenn eine Störung kommt, die selten alleine kommt, sondern ein ganzer Schwall von Störnummern.
Sofern ich das richtig sehe, ist der Fehlerpuffer einer jeden Achse 8 Elemente lang und die Fehler stehen dort chronologisch sortiert an, richtig?

ChristophD schrieb:
was meint er damit das der Baustein mehrere Fehler anstehen hat?

Siehe erste Antwort. Pauschalisieren mag ich nicht. Da ich aber neu hier bin, will ich mich auch nicht streiten.
Vor allem, da ich nun wirklich von Siemens Antrieben keine Ahnung habe.

kafiphai schrieb:
Ja, ein versehen...

Habe aktuell gerade ein Projekt mit SINA_PARA, wie von TheLevel in #5 beeschrieben gelöst.
Auch schön...

Anhang anzeigen 42754 Anhang anzeigen 42755

An den Sina_Para schreibst du dann aber die HW_ID von der übergeordneten Controllerbaugruppe, oder? Oder kann eine Achse noch Unterachsen haben.
Auch dem DEV_FLT4 kann ich ne Axis Nummer geben. Ist das nicht schon genau genug mit der HWID definiert. Gerade ist es so, habe ich eine Frage geklärt, kommt die nächste auf

ChristophD · 24 September 2018

Hi,

der Fehlerpuffer ist wesentlich größer, in den 8 ersten Elementen stehen die aktuellen Störcodes, danach die quittierten Störcodes usw.
Für den DEV_FLT4 gab es mal bei PCS7 ne Doku aber die scheint nicht mehr online zu sein, aber eigentlich ist er selbsterklärend.

Gruß
Christoph

TheLevel · 24 September 2018

L4s3r73k schrieb:
Also seine Aussage war, dass wenn eine Störung kommt, die selten alleine kommt, sondern ein ganzer Schwall von Störnummern.
Sofern ich das richtig sehe, ist der Fehlerpuffer einer jeden Achse 8 Elemente lang und die Fehler stehen dort chronologisch sortiert an, richtig?

Ich würde nach einem kurzen Test mit meinem S210 auf dem Schreibtisch sagen, dass es bis zu 8 aktuell anstehenden Störmeldungen sind, chronologisch geordnet.

L4s3r73k schrieb:
An den Sina_Para schreibst du dann aber die HW_ID von der übergeordneten Controllerbaugruppe, oder? Oder kann eine Achse noch Unterachsen haben.
Auch dem DEV_FLT4 kann ich ne Axis Nummer geben. Ist das nicht schon genau genug mit der HWID definiert. Gerade ist es so, habe ich eine Frage geklärt, kommt die nächste auf

In beiden Fällen muss die ID vom Telegramm dran.

CU320 Sinamics S120 - Beziehung von Fehler- & Statuscodes in der SPS

Level-2

Level-3

Level-2

Level-2

Level-2

Level-3

Level-2

Level-2

Level-2

Level-2

Level-3

Level-2

Level-2

Level-2

Level-3

Level-2

Level-2

Level-2

Level-3

Level-2

Similar threads

Wir schützen deine Privatsphäre