RESET-Baustein für PROFIBUS-DP-SLave?

Supervisor

Level-1
Beiträge
93
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS-Experten,

hab da mal eine Frage:

Gibt es für STEP7 irgendwelche "Standard"-Bausteine in der Bibliothek um einen PROFIBUS-DP-Slave zu reseten oder die Kommunikation zwischen dem Master (SPS) und dem Slave neu anzustoßen?

Habe da ein Problem mit einem CAN/PROFIBUS-Gateway, dass zwar eine Verbindung zum Master (eine S7-313C-2DP SPS) hat, aber irgendwie von der PROFIBUS-Seite her "eingefroren" ist. Das soll heißen, der Slave reagiert auf keine Lese-/Schreibe-Befehle mehr (z.B. in AWL mit L und T), obwohl die Verbindung zum Master besteht. Gibt es in STEP7 nicht irgendwelche Bausteine wie SFC14/14 o.ä. zum "Reinitialisieren" von DP-Slaves??? :confused:

Grüße!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
HILFE!

Kann mir jemand sagen, was ich an den Eingang "LADDR" vom SFC12 anlegen muss, damit ich meinen DP-Slave ansprechen kann?

Laut meiner HW-Konfig hat mein Slave die Stationsadresse "100" in dezimal. Da ich als Eingangsparameter von LADDR ein Datentyp WORD anlegen muss, so muss ich doch also den Wert "W#16#64" in hex eingeben, oder nicht??? :confused:

Egal was ich auch probiere, ich bekomme immer den Fehlercode "8093: Zu der in LADDR angegebenen Adresse gehört kein DP-Slave/PROFINET IO-Device (Es liegt keine Projektierung vor.), oder der Parameter MODE ist nicht bekannt".

Code:
      CALL  "D_ACT_DP"
       REQ    :=E124.0
       MODE   :=B#16#2
       LADDR  :=W#16#64
       RET_VAL:=MW0
       BUSY   :=M10.0

Was mache ich da falsch??? :twisted:
 
Nicht die Profibusadresse ist gemeint, sondern die E-/A-Adresse, die ja für einen Slave in der Hardwarekonfig eingetragen wird.
 
Ah, danke! Warum steht das dann nirgens???

Es funktoniert soweit. Ich kann den Slave abschalten, dafür kann ich den Slave nicht mehr aktivieren. Die SPS geht in den SF-ERROR und der SFC12 zeigt mir folgende Meldung "7002: Zwischenaufruf (REQ irrelevant). Der aktivierte Auftrag ist noch in Bearbeitung; BUSY hat den Wert 1".

Woran könnte das noch liegen?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ah, danke! Warum steht das dann nirgens???
Steht doch in der hilfe
LADDR Beliebige logische Adresse des DP-Slaves/PROFINET IO-Devices
Es funktoniert soweit. Ich kann den Slave abschalten, dafür kann ich den Slave nicht mehr aktivieren. Die SPS geht in den SF-ERROR und der SFC12 zeigt mir folgende Meldung "7002: Zwischenaufruf (REQ irrelevant). Der aktivierte Auftrag ist noch in Bearbeitung; BUSY hat den Wert 1".

Woran könnte das noch liegen?
siehe nächsten beitrag von mir :)
 
Zuletzt bearbeitet:
Aus der Siemens FAQ
FRAGE:
Was passiert, wenn ich einen bereits deaktivierten DP-Slave, der physikalisch vom DP-Bus getrennt ist, mittels SFC 12 aktiviere?
ANTWORT:
Wenn Sie versuchen, einen deaktivierten Slave, der physikalisch vom DP-Bus getrennt ist, mit SFC 12 "D_ACT_DP" zu aktivieren, liefert SFC 12 für ca.1 Minute den Fehlercode W#16#7002 mit BUSY-Bit 1, um anzuzeigen, dass der aktivierte Auftrag noch in Bearbeitung ist. Nach ca. 1 Minute liefert RET_VAL für einen CPU-Zyklus lang den Wert W#16#80A2. Dies bedeutet, dass der angesprochene DP-Slave keine Rückmeldung gibt. Der DP-Slave bleibt nach dieser Prozedur deaktiviert. Die BF-LED des zugehörigen DP-Master bleibt während dieser Prozedur aus.
Hinweis:
Falls der DP-Slave zu einem späteren Zeitpunkt wieder Verbindung zum DP-Bus hat und aktiviert werden soll, müssen Sie SFC 12 erneut anstoßen.
 
Danke für die Info, aber ich habe das so verstanden, dass als logische Adresse die DP-Stationsadresse verwendet werden muss. Etwas verwirrend muss ich sagen.

Ich habe jetzt gesehen, dass mein Slave ganz kurz angeht, wenn ich ihn aktiviere. Danach geht er sofort wieder aus und die SPS geht in den ERROR-Zustand.

Muss ich einfach etwas länger warten, bevor ich den Slave wieder zuschalte? Ich probiere einfach mal eine Zeit abzuwarten!

Soweit tausend Dank für die Infos!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hier noch mal ein Zitat aus der FAQ
FRAGE:
Wie oft kann ich die Systemfunktion SFC12 "D_ACT_DP" gleichzeitig aufrufen?
ANTWORT:
SFC12 "D_ACT_DP" arbeitet asynchron, d.h. diese Systemfunktion arbeitet einen Auftrag über mehrere Zyklen ab. Damit die Abarbeitung über alle notwendigen Zyklen hinweg erfolgen kann, muss der Parameter "REQ" so lange gesetzt sein, wie der Auftrag noch aktiv ist. Sie müssen somit den Parameter "REQ" so lange auf "TRUE" gesetzt lassen, bis der Parameter "BUSY" wieder den "FALSE"-Pegel erreicht hat.
SFC12 kann in den S7-300 CPUs mit interner DP-Schnittstelle bis zu viermal gleichzeitig aufgerufen werden. Bei den S7-400 CPUs kann SFC12 gleichzeitig bis zu viermal pro DP-Strang (interne und externe) aufgerufen werden.
Hinweis:
Bei Verwendung des CP342-5 als DP-Master kann SFC12 nicht zur Aktivierung/Deaktivierung eingesetzt werden.
Das Aktivieren eines DP-Slaves kann geraume Zeit in Anspruch nehmen. Falls Sie einen laufenden Aktivierungsauftrag abbrechen wollen, dann starten Sie die Systemfunktion mit dem gleichen Wert für LADDR und MODE = 2. Sie wiederholen den Aufruf mit MODE = 2 so lange, bis der erfolgreiche Abbruch des Aktivierungsauftrags mit RET_VAL = 0 angezeigt wird. Diese Vorgehensweise ist nur mit CPUs der S7-300 Reihe möglich. Bei S7-400 CPUs können Sie den Auftrag nicht abbrechen.
 
Habe da ein Problem mit einem CAN/PROFIBUS-Gateway, dass zwar eine Verbindung zum Master (eine S7-313C-2DP SPS) hat, aber irgendwie von der PROFIBUS-Seite her "eingefroren" ist. Das soll heißen, der Slave reagiert auf keine Lese-/Schreibe-Befehle mehr (z.B. in AWL mit L und T), obwohl die Verbindung zum Master besteht.

Hi,
sag mal was ist das für ein Gateway?
Ich habe mit einem GW4 von Woodward ein ähnliches Problem. Dort ist es aber so, dass sich das Gateway nichtmal mehr am Bus als Teilnehmer meldet.

Bei mir kommt das vor, wenn wegen Spannungsausfall die SPS ausgeht, der Slave aber anbleibt.
Aussage von Woodhead: "Relais nachrüsten um das GW von der SPS aus aus- und wieder einzuschalten". lol

Thomas
 
was ist das für ein gateway?

was sagt der hersteller zu dem problem?

selbst wenn das deaktivieren/aktivieren des slaves das problem lösen würde, so ist diese lösung denoch beschissen und inakzeptabel.

ich denke du hast ein ganz anderes problem und das gilt es zu finden.

das problem mit deiner idee zu umgehen ist der absolut falscheste weg...


hängen noch andere teilnehmer am bus?
ist der bus physikalisch ok?

es gibt immer wieder vollidioten die stichleitugnen durch das aufeinaderstecken mehrer dp-stecker bauen und sich dann wundern, oder leute die einfach nicht in der lage sind eine busleitung sauber aufzulegen...

hast du 100% die richtige gsd?
ich hatte ähnliche probleme weil es von vipa mal plötzlich andere hw gab und ich noch die alte gsd in der "stadartsoftware" hatte...


wobei ich die vermutung nich los werde das mit deinem gateway was nicht passt. hat das gateway die selbe übertragungsrate bzw. kann es die in der s7-hw-config überhaupt.

(wenn zb. ein dp/pa koppler ohne et200-link im bus hängt darf der profibus nur mit 187,5 gefahren werden)

spannungsversorgung und potentialausgleich an dem gateway sind BEIDSEITIG ok?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen! ;)

was ist das für ein gateway?

was sagt der hersteller zu dem problem?

selbst wenn das deaktivieren/ktivieren des slaves das problem lösen würde, so ist diese lösung denoch beschissen und inakzeptabel.

ich denke du hast ein ganz anderes problem und das gilt es zu finden.

das problem mit deiner idee zu umgehen ist der absolut falscheste weg...

...

Erst mal danke für die vielen Tips! :)

Also physikalisch ist da alles im grünen Bereich. Von daher sollte der Fehler ausgeschlossen sein. Ich weiß, dass die Idee mit dem An- und Abschalten des Slaves eine beschissene Idee ist und völlig inakzeptabel ist. Da stimme ich Markus völlig zu. Deswegen suchte ich ja auch nach einer Funktion zu Reinitialisierung des Slaves, weil ich nähmlich herausgefunden habe, dass beim An-/Abstöpseln des Profibus-Steckers die ganze Sache wieder einwandfrei funzt. Und wenn ich mich nicht täusche, dann sendet der Master beim Anstöpseln eines Slaves ein Parameter-Telegramm und ein Config-Telegramm zum Slave. Deswegen die Idee mit dem An-/Abschalten des Slaves.

Bei dem Slave handelt es sich um eine Eigenentwicklung in der Prototypenphase eines Freundes. Ich denke auch, das Problem ist eher in der Firmware/Hardware des Slaves selber zu suchen. :(

Aber das mit der GSD-Datei könnte auch noch ein Problem darstellen. Ich habe da mehrere Versionen installiert. Könnte durchaus möglich sein, dass da etwas durcheinander gekommen ist. Da werde ich nochmal nachforschen.
Deinstallieren von GSD-Dateien geht ja leider unter STEP7 nicht, oder kennt da jemand einen Weg? :confused:

Grüße!
 
...
Bei dem Slave handelt es sich um eine Eigenentwicklung in der Prototypenphase eines Freundes. Ich denke auch, das Problem ist eher in der Firmware/Hardware des Slaves selber zu suchen. :(
Das hört sich doch verdächtig an:rolleyes:

...
Deinstallieren von GSD-Dateien geht ja leider unter STEP7 nicht, oder kennt da jemand einen Weg? :confused:
...
Die GSD-Dateien liegen unter <<LW:>>\Siemens\Step7\S7data\gsd\
ich weiss aber nicht, was passiert, wenn man die löscht. Kannst ja mal probieren, wenn du ein Backup hast
 
Danke für den Tipp!
Ich werde das mit der GSD-Datei mal auf einem anderen System ausprobieren. Ich will nicht riskieren, dass ich mir mein aktuelles System versaue - laut dem Motto: Never change a running system! ;)

Danke und Gruß!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
LADDR beim SFC12

Hallo zusammen

Nicht die Profibusadresse ist gemeint, sondern die E-/A-Adresse, die ja für einen Slave in der Hardwarekonfig eingetragen wird.

Ich habe bis jetzt immer die Diagnoseadresse der DP-Slaves verwendet. Ist das falsch? (Es funktioniert auch)

Meine Überlegung ist: Wenn ich zwei Slaves habe. Der Erste belegt EB100-EB107, und der zweite Slave AB100-AB107. Was trage ich denn beim SFC12 unter LADDR ein, wenn ich nur den zweiten Slave abschalten möchte?

Gruss Hoyt
 
Das hört sich doch verdächtig an:rolleyes:


Die GSD-Dateien liegen unter <<LW:>>\Siemens\Step7\S7data\gsd\
ich weiss aber nicht, was passiert, wenn man die löscht. Kannst ja mal probieren, wenn du ein Backup hast


Die betreffenden GSDs kann man problemlos löschen.
Danach im HW-Konfigurator "Katalog aktualisieren"
=> GSDs neu installieren
=> fertig
 
Hallo zusammen,

Ich hoffe ich erreiche hier in diesem Thema, dass ja schon etwas älter ist, noch jemanden.

Da ich selber gerade mit dem SFC 12 zu tun habe würde ich gerne auf die Frage von Hoyt zurückkommen:

Ich habe bis jetzt immer die Diagnoseadresse der DP-Slaves verwendet. Ist das falsch? (Es funktioniert auch)

Meine Überlegung ist: Wenn ich zwei Slaves habe. Der Erste belegt EB100-EB107, und der zweite Slave AB100-AB107. Was trage ich denn beim SFC12 unter LADDR ein, wenn ich nur den zweiten Slave abschalten möchte?

Gruss Hoyt


Weiters habe ich noch eine Frage:

Vorausgesetzt man kann mit PLC SIM und einem kleinen Anwenderprogramm diese Funktionen mit an- und abschalten von Slaves erfolgreich testen.
Weil die Hardware ja eigentlich nur "virtuell" ist...

Denn das deaktivieren läuft Problemlos, die Hardware kann auch ONLINE betrachtet werden, der Slave-Teilnehmer verabschiedet sich.
Ein Problem habe ich beim aktivieren dieses Slaves. Da bleibt das BUSY-BIT auf 1 und im RET_VAL steht W#16#7002. Jedoch dauerhaft und nicht wie in div. Themen beschrieben nur 1min.
Der Teilnehmer wird trotzdem aktiviert (laut ONLINE Hardwarekonfig, sowie ein weiterer SFC 12 Aufruf mit MODE=0 => RET_VAL=W#16#0001 => Teilnehmer aktiviert)

Die Frage lautet also warum sich das BUSY-BIT nicht wieder zurücksetzt. Sollte ja Automatisch gehen oder nicht?
 
Das dachte ich mir schon fast, doch was tun wenn ich keine reale Hardware zur verfügung habe?
(Softwarevorbereitung im Büro, Inbetriebnahme erst viel später)

Hast du auch bezüglich der LADDR Parametrierung eine Idee?

Vielen Dank
 
Hoyt schrieb ja, dass es mit den Diagnoseadressen auch funktioniert, vielleicht ist das ja deine Lösung, getestet habe ich das nie.
 
Zurück
Oben