Sew movidrive - profibusauswertung

[ebstiele]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Zusammen,

ich steuere einen SEW Umrichter mittels Profibus an.
Steht im Umrichter ein Fehler an, so wird im Statuswort das 5. Bit gesetzt.
Wird danach der Umrichter, über das 6. Bit im Steuerwort, "resetet" - wird ein Kommunikationsfehler ausgegeben.

Hier ein Auszug von der Kommunikation mit dem Umrichter:

Steuerwort:

U #Reset // ALARMS RESET
= L 47.6 // ALARM RESET BIT FROM COMMAND WORD

U #Start //START INVERTER
= L 47.1
= L 47.2

L LW 46 // AUX COMMAND WORD
T #PAW_Command_Word

Statuswort:


L #PEW_Status_Word // INVERTER STATUS WORD
T LW 48 // AUX STATUS WORD

U L 49.5 // ALARM BIT FROM STATUS WORD
= #Inverter_Alarm // FAUL ALARM INVERTER

L #PEW_Status_Word //PROFIBUS NODE OK
L 0
<>I
= #Node_DP_ok
UN #Node_DP_ok
= #Profibus_Alarm //PROFIBUS NODE ALARM

U #Node_DP_ok
UN L 49.1
UN L 49.5
= #Inverter_not_supply //INVERTER NOT SUPPLY


Kann es sein, dass das Steuerwort nach dem "reseten" kurz auf 0 geht und dadurch die Kommunikationsstörung generiert wird?
Das Auffällige ist, dass diese Kommunikationsstörung immer nach einem Reset bzw. nach einem quittierten Fehler im Umrichter auftritt.

Der Umrichter wird über direkte Perepherieworte angesteuert bzw. ausgelesen.


MfG
Eric

 

[Aventinus]

Prinzipiell sollte das so funktionieren...

Woher weißt du dass es sich um einen Kommunikationsfehler handelt? SEW Fehlernummer?

PS: du solltest dir angewohnen, symbolisch zu programmieren. Dadurch wird das Programm lesbarer...

 

[ebstiele]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die rasche Rückmeldung!

Das Programm wurde von einer externen Firma geliefert - deshalb nicht symblisch programmiert.

Im Prinzip weiß ich nicht ob es sich um einen Kommunikationsfehler handelt, aber ist zu 99% auszuschließen. (Im Diagnosepuffer der CPU ist kein Ausfall eines Teilnehmers zu erkennen)
Das Bit "#Profibus_Alarm" wird ja gesetzt wenn das Statuswort 0 ist.
Beim reseten müsste es so sein, dass das Statuswort kurzfristig 0 wird und so der "#Profibus_Alarm" gesetzt wird. Anders kann ich es mir nicht erklären.

Danke für deine Hilfe.
Eric

 

[Larry Laffer]

Vielleicht wird dein Fehler ja auch durch das ausgelösst, was in dem Lokalwort sonst noch so drin steht - beachte bitte : LW = unbestimmter Grundinhalt.
Schreib doch mal vor deiner Zuweisung hin :

L 0
T LW 46

Gruß
Larry

 

[Blockmove]

Wenn ich es recht im Kopf hab, dann ist dieses Verhalten normal.

Je nach Fehler führt der Umrichter einen Reset durch. In dieser Zeit ist kein Statusbit gesetzt.

Gruß
Dieter

 

[ebstiele]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die Antworten.

Dann könnte ich die Kommunikationsstörung besser mit dem sfc14 auswerten oder?
Wenn "RET_VAL" <> 0 = Kommunikationsfehler oder lieg ich da falsch?
Somit kann ich beim Reset im Fehlerfall ausschließen, dass die Kommunikationsstörung gesetzt wird.

Gruß
Eric

 

[Verpolt]

[Einklink]

SFC14 liest konsistente Daten vom Teilnehmer.
Der kann auch eine Woche lang Nullen lesen.

Beim Reset des Reglers wird womöglich (wie bei einigen anderen Herstellern) die Kommunikationsbaugruppe DP kurz "gestoppt".
Danach ist die wieder da.

Im OB86 kann das ausgewertet werden. (kommen/gehen)

 

[ebstiele]

Liegt aber ein Kommunikationsproblem mit dem Umrichter vor, so kann der sfc14 keine Daten mehr lessen und RET_VAL ist ungleich 0 oder?
Ok das mit dem OB86 würde auch gehen, wenn möglich ware mir die Variante mit dem SFC14 lieber, aber danke für den Hinweis.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für die Profibus-Diagnose war mir immer der FC125 von Siemens am liebsten.
Damit bekommst du für jeden Slave je ein Bit für "ausgefallen" und "gestört".

Gruß
Dieter

 

[Aventinus]

Für die Profibus-Diagnose war mir immer der FC125 von Siemens am liebsten.
Damit bekommst du für jeden Slave je ein Bit für "ausgefallen" und "gestört".

Gruß
Dieter

Wohl dem, der noch einen FC125 hat
Soweit ich weiß gibts den nicht mehr zum Download.

 

[Ralle]

Doch gibts noch

http://www.sps-prog.de/component/jdownloads/viewcategory/5-siemens.html?Itemid=56

 

[Aventinus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da kann aber Siemens nix dafür

 

[maxder2te]

Wenn ich es recht im Kopf hab, dann ist dieses Verhalten normal.

Je nach Fehler führt der Umrichter einen Reset durch. In dieser Zeit ist kein Statusbit gesetzt.

Gruß
Dieter

Exakt!
Dass ein Umrichter nur Nullen liefert muss ansich kein Fehler sein. Beim SEW ist es nunmal so, dass der Umrichter während dem Reset nur Nullen ausgibt. Das Problem ist die schlampig programmierte Fehlermeldung. Die sinnvollste und einfachste Lösung ist das Benutzen des SFC14. Erstens werden damit die Daten konsistent (d.h. "am Stück") eingelesen, zweitens erhält man über den RetVal Ausgang einen Status des Lesevorgangs. Wenn diese Status <> 0 ist, dann ist ein Fehler aufgereten.