# 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.
> ...





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.
> ...


----------



## 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:
> ...



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:

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

```
#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.
> 
> ...



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)
> ...



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...
> ...



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.


----------



## kafiphai (24 September 2018)

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.



In der Geräteansicht der CU ist die HW-Kennung der Module ersichtlich:




Als AxisNo verwendest du die jeweilige Komponentennummer.(in den Eigenschaften des Antriebsobjekts.

Lg
Peter


----------



## L4s3r73k (24 September 2018)

ChristophD schrieb:


> 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.





TheLevel schrieb:


> 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.
> In beiden Fällen muss die ID vom Telegramm dran.



Schade, dass die Doku wohl nicht mehr online ist. 
Wenn der Puffer wesentlich größer ist, bedeutet das doch, ich könnte mit einem umgeschriebenen DEC_FLT4  auch z.B. 16 Fehler lesen?
Danke für den Schreibtisch Test. Ich weiss gerade nicht wirklich, was man von mir will. 
Eben sagte man mir, ich solle mir ein altes Step7 Projekt ansehen, da habe man das schonmal gemacht.
Einen UDT für Fehler hab ich gefunden, aber dass der benutzt wurde irgendwo nicht. Da stehen in 8er Arrays drin:

Stoerzeit DINT
Stoerwert DINT
Stoernummer INT
Stoercode INT
Leider kann mir keiner sagen, wer den Baustein konstruiert hat. 
Nach einer kurzen Rücksprache soll aber ErrorVal und ErrorNo aus dem DEC_FLT4 ausreichend sein.


----------



## ChristophD (24 September 2018)

Die Doku ist bei Siemens nicht mehr online.
Gib bei Google einfach mal DEV_FLT4 ein und dann findest du sie 

es gibt aber pro DO nur maximal 8 aktuell anstehende Störungen.
Danach kommen die schon quittierten Störmeldungen, die brauchst ja gar nicht auslesen.

Gruß
Christoph


----------



## kafiphai (24 September 2018)

Doku (Seite 43):
https://docplayer.net/22453097-Driv...vdps7-function-description-edition-04-06.html


----------



## L4s3r73k (24 September 2018)

kafiphai schrieb:


> In der Geräteansicht der CU ist die HW-Kennung der Module ersichtlich:
> 
> Anhang anzeigen 42756
> 
> ...



Also ich halte fest:
Bei dem Sina_Para Baustein ist die HWID, von der Achse. Beim DEV_FLT4 ist es die Nummer vom Telegramm3.
Beide wollen darüber hinaus eine Achsnummer haben. Gehe ich recht der Annahme, dass es entweder gelb oder blau der folgenden ist?




Bedankt nochmal/schonmal. Das Bild fügt sich langsam.


----------



## ChristophD (24 September 2018)

Hi,

es ist die Gelbe.
Wo ist der Unterschied zwischen HWID der Achse (Was auch immer du damit meint) und der Nummer vom Telegram3?


----------



## L4s3r73k (24 September 2018)

ChristophD schrieb:


> Hi,
> 
> es ist die Gelbe.
> Wo ist der Unterschied zwischen HWID der Achse (Was auch immer du damit meint) und der Nummer vom Telegram3?



Ich sage zur HW Kennung immer HWID, sorry für die Verwirrung, wobei Kennung = Identifikationsnummer = ID, oder? Ich meine das so ähnlich im englischen TIA gesehen zu haben.
Die HW-Kennung vom Telegramm ist jeweils bei mir die HW Kennung der Achse plus 1. 
Wenn wir dabei bleiben, dass der DEV_FLT4 Baustein die ID des Telegramms bekommt, dann ist das folglich eine andere ID als die die der Sina_Para Baustein braucht.


----------



## TheLevel (24 September 2018)

Bei meinem S210 funktionieren sowohl DEV_FLT4 als auch SINA_PARA mit der Hardware-ID vom Telegramm. Und das lässt sich auch symbolisch anbinden.


----------



## L4s3r73k (24 September 2018)

TheLevel schrieb:


> Bei meinem S210 funktionieren sowohl DEV_FLT4 als auch SINA_PARA mit der Hardware-ID vom Telegramm. Und das lässt sich auch symbolisch anbinden.



Wenn ich das richtig sehe, geht das mit der HWID die unter HW-Kennung steht (Telegramm -1) nicht. Right?
Frage ist jetzt nach Vor- & Nachteilen sowie, was richtig ist.


----------



## ChristophD (24 September 2018)

Hi,

auch damit sollte es gehen.
es sind alle Adressen nutzbar da sie intern alle auf das gleiche Objekt zeigen und damit der Zugriff erfolgt.
Vor und Nachteile gibt es da auch nicht.

Gruß
Christoph


----------



## L4s3r73k (24 September 2018)

Okay gut. Also sofern die Axis Nummern in gelb (oben in meinem Screenshot) tatsächlich die richtigen sind, dann sind tatsächlich bald alle Fragen geklärt.
Mich interessiert noch, warum ich ihm die Achse noch geben muss, wenn das über das Telegramm doch eindeutig geklärt ist (dev_flt4)?
Und wofür ist das DS_NO? Gebe ich die nur an, wenn ich anstatt allen 8 Datensätzen nur den xsten Fehler haben will?

Edit:
Ich muss die viele Fragerei ein wenig entschuldigen, aber heute morgen sagte man mir, dass das in eine Standardmaschine kommen soll, die bald ausgeliefert werden soll.
Viel Zeit für Inhouse IBN ist nicht geplant und Testantrieb hab ich hier auch nicht.

Von Siemens habe ich ein "lists_man" heruntergeladen. Da ist doch bestimmt die Übersetzung für die Fehlernummern und Werte drin, oder?


----------



## TheLevel (24 September 2018)

L4s3r73k schrieb:


> Wenn ich das richtig sehe, geht das mit der HWID die unter HW-Kennung steht (Telegramm -1) nicht. Right?
> Frage ist jetzt nach Vor- & Nachteilen sowie, was richtig ist.


Vorteil ist für mich, wenn in einem Baustein zyklische (Telegramm) und azyklische (SINA_PARA, DEV_FLT4) zusammen benutzt werden, muss man als Adresse nur einen Wert übergeben.



L4s3r73k schrieb:


> Mich interessiert noch, warum ich ihm die Achse noch geben muss, wenn das über das Telegramm doch eindeutig geklärt ist (dev_flt4)?


Nur weil es für uns von "außen" über das Telegramm klar ist, muss es das für den FU von "innen" auf Grund der verwendeten Kommunikationstechnik ja nicht auch klar sein.
Auch wenn die ID vom Telegramm benutzt wird, funktioniert es nur dann, wenn auch die Achs-Nummer passt. Selbst bei einem Ein-Ach-Umrichter wie dem S210.



L4s3r73k schrieb:


> Und wofür ist das DS_NO? Gebe ich die nur an, wenn ich anstatt allen 8 Datensätzen nur den xsten Fehler haben will?


Das ist nicht die Anzahl, sondern die Datensatznummer. Die wird intern auf 47 (für azyklische Kommunikation) gesetzt, wenn du von außen nichts änderst. Warum hier andere Nummern angegeben werden können, kann ich jetzt auch nicht sagen....



L4s3r73k schrieb:


> Von Siemens habe ich ein "lists_man" heruntergeladen. Da ist doch bestimmt die Übersetzung für die Fehlernummern und Werte drin, oder?


Ja, das "Telefonbuch" von Siemens....


----------



## L4s3r73k (24 September 2018)

TheLevel schrieb:


> Ja, das "Telefonbuch" von Siemens....



Also ich habe bei Siemens dieses Handbuch heruntergeladen. Auf Seite 2447 beginnen die Fehlernummern.
Wie ich diese Fehlernummern mit der Fehlernummer (Word=16Bit) und dem Fault Wert (DWord=32Bit) in Einklang bringe, weiss ich nicht.
Da stehen so lustige Codes wie "F01000". Einzig, wenn ich diese 6 Ziffern als Chars bzw. Ascii Codes interpretiere, komme ich wenigstens wieder auf 48Bit.
Ich denke, das ist noch nicht das yellow from the egg.


----------



## ChristophD (24 September 2018)

Hi,

was genau ist Dein Problem damit?
Du liest die Störnummer aus über die Parameter und fertig.
Die gibst du dann der HMI und die soll sie verwurschteln.

Was ist da jetzt das Problem?

Gruß
Christoph


----------



## TheLevel (24 September 2018)

L4s3r73k schrieb:


> Wie ich diese Fehlernummern mit der Fehlernummer (Word=16Bit) und dem Fault Wert (DWord=32Bit) in Einklang bringe, weiss ich nicht.
> Da stehen so lustige Codes wie "F01000". Einzig, wenn ich diese 6 Ziffern als Chars bzw. Ascii Codes interpretiere, komme ich wenigstens wieder auf 48Bit.
> Ich denke, das ist noch nicht das yellow from the egg.


Du denkst zu kompliziert. Wenn aus deinem Baustein als Fehlernummer ne 1000 kommt, dann schaust du im Listenhandbuch unter F01000.

Edit:
und wie ChristophD sagt, die Nummer gibst du ans HMI weiter, dort wird die als nummer angezeigt oder jemand macht sich mehr mühe und zaubert aus der Nummer und der passenden .xml gleich den richtigen Text: https://support.industry.siemens.co...-s120-firmware-version-4-8-hf5?dti=0&lc=de-DE


----------



## L4s3r73k (24 September 2018)

@Christoph
Mein Problem ist a, dass ich das gerne recht umfassend verstehen würde und b, dass ich die Softwareker etwas umfassender beliefern muss.

@TheLevel
Danke, das hilft schonmal, dann reiche ich die xml einfach weiter. Was mich noch interessiert ist der value. Wie lese ich den als Mensch oder macht die xml das auch?


----------



## ChristophD (24 September 2018)

Hi,

ich hatte ziemlich zu beginn Links geschickt wo es erklärt ist wie man es machen kann mit HMI.
Das was dort für TIA erklärt ist muss für eure HMI gemacht werden, wie das geht müssen die HMI Leute bei auch wissen.

Die XML liest gar nix!
Die XML ist ne liste wor du nachschauen kannst welcher Text zu welcher Stör/Warnnummer gehört und eben Text statt Nummer anzeigen könntest.

Gruß
Christoph


----------



## L4s3r73k (24 September 2018)

ChristophD schrieb:


> ich hatte ziemlich zu beginn Links geschickt wo es erklärt ist wie man es machen kann mit HMI.
> Das was dort für TIA erklärt ist muss für eure HMI gemacht werden, wie das geht müssen die HMI Leute bei auch wissen.



Gut okay, ich sammle die Informationen und geb die ggf. weiter. 
Da man von mir in mittelfristiger Zukunft auch den Einstieg in die Visuprogrammierung erwartet, sollte ich den Herrschaften auch ein wenig entgegenkommend die Daten und Erkenntnisse servieren.
Wie gesagt, die Visu hat bei der SPS nur etwas im HMI DB zu suchen, das sind Firmenstandards, die kann man gut finden, muss man aber nicht.




ChristophD schrieb:


> Die XML liest gar nix!
> Die XML ist ne liste wor du nachschauen kannst welcher Text zu welcher Stör/Warnnummer gehört und eben Text statt Nummer anzeigen könntest.


Weiss ich doch, dass die nichts liest. Dass die aber als Übersetzungstabelle dient, weiss ich schon.


Edit:
Für mich ist aber immer noch nicht ganz geklärt, was mit dem Störwert (ERR_VAL) ist. 
Oder sind das die? 

```
<ReactionOrder>      
      <Reaction value="1" name="AUS1"/>
      <Reaction value="2" name="AUS2"/>
      <Reaction value="4" name="AUS3"/>
      <Reaction value="8" name="AUS1_VERZÖGERT"/>
      <Reaction value="16" name="IASC/DCBRK"/>
      <Reaction value="32" name="STOP2"/>
      <Reaction value="256" name="GEBER"/>
      <Reaction value="1024" name="KEINE"/>
</ReactionOrder>
```


----------



## zako (24 September 2018)

kafiphai schrieb:


> Stör- und Meldepuffer(verwendet intern auch WRREC & RDREC):
> 
> FB DEV_FLT4: Störungspuffer eines  SINAMICS G/S auslesen



... also, da werfe ich jetzt noch die "LAcycCom" in den Ring.   
https://support.industry.siemens.com/cs/ww/en/view/109479553

Und hier speziell
2.2.8 FB LAcycCom_ReadDriveMessagesDateTime (FB 30518 )*

*Da bekommst Du die Fehlercodes nach Uhrzeit sortiert und die Uhrzeit im SINAMICS kannst Du auch setzen (z.B. wichtig wenn Du mehrere CU´s hast).


----------



## ChristophD (25 September 2018)

Hi,

ReactionOrder ist die Reaktion im System wenn der Fehler auftritt, im Handbuch als Störreaktion bezeichnet.

Was genau ist mit der Störwert nicht klar?

Gruß
Christoph


----------



## L4s3r73k (25 September 2018)

zako schrieb:


> ... also, da werfe ich jetzt noch die "LAcycCom" in den Ring.
> https://support.industry.siemens.com/cs/ww/en/view/109479553
> 
> Und hier speziell
> ...



Danke. Ich werde fragen, ob wir das so explizit brauchen. Aktuell ist geplant den Baustein DEV_FLT4 Baustein bzw. Bausteine permanent zu durchlaufen (permanentes Start Signal). 
Ich zweifle zwar, dass das so gut ist, aber das ist jetzt erst einmal die Vorgabe. Time Logging ginge auch über die Visu.



ChristophD schrieb:


> ReactionOrder ist die Reaktion im System wenn der Fehler auftritt, im Handbuch als Störreaktion bezeichnet.
> 
> Was genau ist mit der Störwert nicht klar?



Naja, wir haben geklärt, was die ERR_NOX ist und was ich damit wie anstellen kann, mit der *.xml von Siemens.
Was mir noch nicht klar ist, ist der ERR_VAX. Beides sind die Ausgangswerte von DEV_FLT4. 
Ich bin nicht fertig damit, den Visu Leuten ein paar Variablen an den Kopf zu werfen, erklären muss ich die auch.


----------



## TheLevel (25 September 2018)

zako schrieb:


> ... also, da werfe ich jetzt noch die "LAcycCom" in den Ring. ...
> und die Uhrzeit im SINAMICS kannst Du auch setzen (z.B. wichtig wenn Du mehrere CU´s hast).


Das wird jetzt zwar etwas OT, aber bei dem Thema werfe ich mit NTP zurück - ich habe gesehen, dass einen p3103 (UTC Synchronisationsverfahren) mit der Option NTP gibt. Funktioniert das tatsächlich so einfach, obwohl es von Siemens ist?


----------



## ChristophD (25 September 2018)

Hi,

ERR_VA sind die Begleitwerte der Alarme , insofern der Alarm sowas hat.
Beispiel: F01000 hat 2 Begleitwerte (Modul und Zeile) 
Diese Werte werden dem Alarm mitgegeben um eben die Ursache des Alarms zu melden und die Diagnose zu vereinfachen.

Gruß
Christoph


----------



## ChristophD (25 September 2018)

TheLevel schrieb:


> Das wird jetzt zwar etwas OT, aber bei dem Thema werfe ich mit NTP zurück - ich habe gesehen, dass einen p3103 (UTC Synchronisationsverfahren) mit der Option NTP gibt. Funktioniert das tatsächlich so einfach, obwohl es von Siemens ist?



Ja geht so "einfach" , setzt aber eine neuere FW Version voraus, bei älteren FW Ständen geht das unter umständen nicht.


----------



## L4s3r73k (25 September 2018)

ChristophD schrieb:


> ERR_VA sind die Begleitwerte der Alarme , insofern der Alarm sowas hat.
> Beispiel: F01000 hat 2 Begleitwerte (Modul und Zeile)
> Diese Werte werden dem Alarm mitgegeben um eben die Ursache des Alarms zu melden und die Diagnose zu vereinfachen.



Das wird wahrscheinlich auch erklären, warum der ERR_VAL auch ein DWord ist, anstatt ein WORD wie ERR_NO, oder ist das ein Denkfehler?


----------



## ChristophD (25 September 2018)

Hi,

naja der Begleitwert kann schon ne größere Nummer sein. Deswegen der DWord Datentyp.

Gruß
Christoph


----------



## L4s3r73k (25 September 2018)

So, ich habe jetzt den DEV_FLT4 für unsere Bedürfnisse angepasst. 
Soll heissen, die NOs und VALs kommen nun gebündelt in einen UDT und werden auf den HMI DB gelegt.
Somit ist, was das betrifft, meine Aufgabe fast erledigt.

Allerdings bin ich noch auf das gestoßen:


Die Z-Achse hat kein Telegramm 3, "nur" ein 103. Erfüllt das den gleichen Zweck oder sollte ich den Kollegen fragen, wieso, weshalb warum?
Ausserdem stelle ich mir die Frage, ob es nicht möglich ist, mir die Daten aus den I/O Bereichen direkt holen kann. So rein prakmatisch für die Zukunft gedacht!?

LG Dennis


----------



## ChristophD (25 September 2018)

Hi,

ob 3 oder 103 ist egal.
Die Daten holst du ja nicht darüber sondern eben azykl. und da ist nur erstmel die adresse wichtig (HW ID) egal welches nutzdatentelegram du hast.

Aus dem I/O Bereich lesen? Klar kannst du wenn du das im Antrieb entsprechend konfigurierst das er die Werte dort hinschickt dann kann es dort auch gelesen werden.
Aber Telegram 3 oder 103 geben das nicht her da müsste man z.B Telegram 352 nehmen.

Gruß
Christoph


----------



## TheLevel (25 September 2018)

L4s3r73k schrieb:


> Ausserdem stelle ich mir die Frage, ob es nicht möglich ist, mir die Daten aus den I/O Bereichen direkt holen kann. So rein prakmatisch für die Zukunft gedacht!?





ChristophD schrieb:


> Aus dem I/O Bereich lesen? Klar kannst du wenn du das im Antrieb entsprechend konfigurierst das er die Werte dort hinschickt dann kann es dort auch gelesen werden.
> Aber Telegram 3 oder 103 geben das nicht her da müsste man z.B Telegram 352 nehmen.



Das ist im Prinzip auch meine Standard-Ansteuerung (352). In den Telegrammen, die eine Fehlernummer mit übertragen, steht dann aber nur eine Fehlernummer und keine zusätzliche Information drin. In den meisten Fällen ist diese Nummer (und auf dem HMI über eine Textliste dann der entsprechende Fehlertext) aber für die Fehlersuche schon ausreichend.


----------



## L4s3r73k (25 September 2018)

ChristophD schrieb:


> ob 3 oder 103 ist egal.
> Die Daten holst du ja nicht darüber sondern eben azykl. und da ist nur erstmel die adresse wichtig (HW ID) egal welches nutzdatentelegram du hast.
> 
> Aus dem I/O Bereich lesen? Klar kannst du wenn du das im Antrieb entsprechend konfigurierst das er die Werte dort hinschickt dann kann es dort auch gelesen werden.
> Aber Telegram 3 oder 103 geben das nicht her da müsste man z.B Telegram 352 nehmen.



Also verstehe ich das richtig? Ich gebe Bausteinen wie dem SINA_PARA oder DEV_FLT4 nur die HWID und die Achsnummer, damit er sich daraus auf die eigentliche Zugriffsadresse schließen kann?



TheLevel schrieb:


> Das ist im Prinzip auch meine Standard-Ansteuerung (352). In den Telegrammen, die eine Fehlernummer mit übertragen, steht dann aber nur eine Fehlernummer und keine zusätzliche Information drin. In den meisten Fällen ist diese Nummer (und auf dem HMI über eine Textliste dann der entsprechende Fehlertext) aber für die Fehlersuche schon ausreichend.



Gut zu wissen, wenn das mal gefragt ist, weiß ich, dass ich auf diesen Thread zurück komme.


----------



## ChristophD (25 September 2018)

Nein er schickt an diese Adresse einen Datensatz lesen Auftrag. Das läuft azyklisch neben den nutzdaten, quasi ein paralleler Kanal.
Auf dem Kanal schickt der Antrieb auch die Werte zurück.


----------



## L4s3r73k (25 September 2018)

ChristophD schrieb:


> Nein er schickt an diese Adresse einen Datensatz lesen Auftrag. Das läuft azyklisch neben den nutzdaten, quasi ein paralleler Kanal.
> Auf dem Kanal schickt der Antrieb auch die Werte zurück.



Okay, check, verstanden*ACK*


----------

