D_ACT_DP - I/O Device aktivieren/deaktivieren

[Drumfan159]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe eine Standard Maschine mit einer ET200SP und 9 möglichen Netzwerkteilnehmer (Interfacemodule). Um in zukunft nicht immer das Projekt mit der Größe im TIA definieren zu müssen, würde ich gerne die Funktion D_ACT_DP nutzen, um die vorhandenen Geräte/Peripherien zu aktivieren.
Fällt da jemandem etwas ein, wie die Geräte trotz projektierter Hardwarekonfig beim erstmaligem Einschalten der CPU erst einmal alle standardmäßig deaktiviert sind und erst nach angewähltem Steuerungsauftrag der Funktion aktiviert werden? Weil aktuell sind sie zu beginn ja immer aktiv und ich müsste alle die, die ich nicht im Projekt habe deaktivieren und ich bräuchte das System genau andersherum, um die Hauptkomponente ohne Zubehör fehlerfrei im Hause testen zu können.
Und gibt es auch noch eine Funktion, die mir ständig Rückmeldung liefert, ob ein I/O-Device gerade aktiv oder deaktiv ist, ohne dass man erst einen Steuerauftrag starten muss?

LG, Drumfan.

 

[DeltaMikeAir]

Fällt da jemandem etwas ein, wie die Geräte trotz projektierter Hardwarekonfig beim erstmaligem Einschalten der CPU erst einmal alle standardmäßig deaktiviert sind und erst nach angewähltem Steuerungsauftrag der Funktion aktiviert werden?

Ja, das habe ich an bestimmten Anlagen auch schon umgesetzt. Du kannst das z.B. im OB100 umsetzen ( alle erst einmal deaktivieren ). Beachten müsst du, das der Baustein azyklisch arbeitet und die maximale Anzahl der gleichzeitigen Aufträge ist auch begrenzt.

Und gibt es auch noch eine Funktion, die mir ständig Rückmeldung liefert, ob ein I/O-Device gerade aktiv oder deaktiv ist

Schau einfach mal in die Hilfe des Bausteins.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn Du nur im Haus testen willst, dann sollte es doch egal sein, ob zuerst alle Geräte als fehlend gemeldet werden.
Wenn ein I/O-Device deaktiviert ist, dann wird sämtliche Kommunikation mit dem Gerät eingestellt. Woher soll die CPU wissen, ob das Gerät tatsächlich vorhanden ist, wenn nicht durch einen extra ausgelösten Kommunikationsversuch?

Harald

 

[PN/DP]

Ja, das habe ich an bestimmten Anlagen auch schon umgesetzt. Du kannst das z.B. im OB100 umsetzen ( alle erst einmal deaktivieren ).

Ich hätte gedacht, daß D_ACT_DP im OB100 gar keinen Sinn macht, falls das überhaupt geht... D_ACT_DP benötigt mehrere Durchläufe durch den Zykluskontrollpunkt.

Harald

 

[Drumfan159]

Das hab ich mir auch gerade gedacht bezüglich OB100....vielleicht hab ich ja auch falsch gedacht.
Das Problem bei mir ist das wir den NOT-HALT kreis mit Profisafe Kommunikation realisiert haben und über die Eingliederung des Gerätes alles erdenkliche aktivieren möchte ( eventuelle Störungen der "peripherie-Station" selbst, NOT-HALT Funktion, usw....)
Dazu müsste ich die Devices aber wie gesagt beim ersten Einschalten der CPU erst mal als deaktiv erfassen können und nur durch gezielte Aktivierung mit auswerten.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hab ich mir auch gerade gedacht bezüglich OB100....vielleicht hab ich ja auch falsch gedacht.
Das Problem bei mir ist das wir den NOT-HALT kreis mit Profisafe Kommunikation realisiert haben und über die Eingliederung des Gerätes alles erdenkliche aktivieren möchte ( eventuelle Störungen der "peripherie-Station" selbst, NOT-HALT Funktion, usw....)
Dazu müsste ich die Devices aber wie gesagt beim ersten Einschalten der CPU erst mal als deaktiv erfassen können und nur durch gezielte Aktivierung mit auswerten.

Kannst du einmal ganz genau erklären, was das Problem bei euch ist? So ganz verstanden habe ich es nicht.

 

[PN/DP]

Und gibt es auch noch eine Funktion, die mir ständig Rückmeldung liefert, ob ein I/O-Device gerade aktiv oder deaktiv ist, ohne dass man erst einen Steuerauftrag starten muss?

Man kann D_ACT_DP mit MODE = 0 aufrufen, das liefert die Auskunft, ob das Device aktiviert oder deaktiviert ist. Das könnte sogar sofort ohne mehrere Durchläufe das Ergebnis liefern? (ich habe da keine Erfahrung mit S7-1x00)

Harald

 

[Drumfan159]

Also mein Gedanke ist folgender:
1. Maschine das aller erste mal Einschalten (Programm schon aufgespielt und CPU geht in RUN)
2. Bereits jetzt sollen die Devices schon als deaktiv von der CPU ausgewertet werden, ohne dass ein Bediener diese zuvor über die Funktion D_ACT_DP deaktivieren muss -->sprich keine ERROR Led am blinken obwohl in der Hardware alle möglichen Profinet-Teilnehmer konfiguriert sind. Und ich müsste jetzt schon eine Rückmeldung im Programm haben "xxxxxxxx-Device aktuell deaktiviert" und das auch ohne das irgend jemand etwas bedient hat. Dadurch kann ich in der Safety auch den fehlenden Not-Halt-Kreis Teilnehmer mit auswerten und ohne auch ohne Safety-Teilnehmer freigeben.
3. Haupt-Maschine konnte so ohne kompletten Aufbau getestet werden. Nun geht sie mit den zugehörigen Devices auf die Baustelle und meine Monteure können sich das Projekt am Panel zusammenstricken, also erst jetzt die jeweiligen Geräte aktivieren, dann benötige ich wieder eine dauerhafte Rückmeldung, dass das Gerät aktiviert ist und kann damit auch den Gesamt-NotHalt verschalten.

Im wesentlichen liegt aber mein Problem beim ERSTEN Einschalten der CPU (Wechsel auf RUN)....genau jetzt müssen die Geräte nämlich schon des Status "deaktiviert" haben und ich schon eine Rückmeldung "Gerät aktuell deaktiviert" ins Programm bekommen. Und hier fehlt mir die Praktische Umsetzung, da die Geräte beim Einschalten schon als aktiviert gelten und nun deaktiviert müssen-->das muss ich andersherum realisieren.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

und meine Monteure können sich das Projekt am Panel zusammenstricken, also erst jetzt die jeweiligen Geräte aktivieren,

Das Problem bei mir ist das wir den NOT-HALT kreis mit Profisafe Kommunikation realisiert

Wie soll das mit dem fehlersicheren Teil funktionieren, also wenn an den dezentralen Gerätschaften F-E/A´s verbaut und verwendet sind?

 

[PN/DP]

Im wesentlichen liegt aber mein Problem beim ERSTEN Einschalten der CPU (Wechsel auf RUN)....genau jetzt müssen die Geräte nämlich schon des Status "deaktiviert" haben und ich schon eine Rückmeldung "Gerät aktuell deaktiviert" ins Programm bekommen. Und hier fehlt mir die Praktische Umsetzung, da die Geräte beim Einschalten schon als aktiviert gelten und nun deaktiviert müssen

Bei S7-300/400 z.B. deaktiviere ich alle zu deaktivierenden DP-Slaves automatisch ca 5 Sekunden nach Start des OB1 in einer "Schrittkette". Da braucht niemand was anstossen.

Spoiler: AWL Code Slaves deaktivieren

// ein paar Sekunden nach Neustart nicht benötigte DP-Slaves deaktivieren
      U     "CYCLE1"                    //(M0.2: wenn #OB1_SCAN_1 <> 3)
      L     S5T#5S
      SS    T      2
      U     T      2
      R     T      2
      S     "D_ACT_REQ"

      U     "D_ACT_REQ"                 //kann auch per PG angestossen werden
      SPBN  EDAC

//Geräte die nicht deaktiviert werden sollen einfach die SPA-Zeile auskommentieren
      L     "D_ACT_CNT"                 //(MB41, nicht remanent, startet mit 0)
      SPL   LDAE
      SPA   DAW1
      SPA   DAW2
      SPA   DAW3
      SPA   DAW4
      SPA   DAL1
      SPA   DAL2
      SPA   DASO
      SPA   DAVM
      SPA   DAJ1
      SPA   DAJ2
LDAE: L     0                           //wenn CNT größer als Liste
      T     "D_ACT_CNT"                 //dann fertig
      SET   
      R     "D_ACT_REQ"

      SPA   EDAC

//Liste der zu deaktivierenden DP-Slaves: jeweils Diagnoseadresse des DP-Slave
DAW1: L     2045                        //DP:3  2045 Waage 321
      SPA   MSFC
DAW2: L     2043                        //DP:5  2043 Waage 322
      SPA   MSFC
DAW3: L     2041                        //DP:7  2041 Waage 323
      SPA   MSFC
DAW4: L     2038                        //DP:20 2038 Waage 324
      SPA   MSFC
DAL1: L     2036                        //DP:12 2036 321 CPU
      SPA   MSFC
DAL2: L     2034                        //DP:13 2034 322 CPU
      SPA   MSFC
DASO: L     2030                        //DP:15 2030 S7-400 Xxxx1
      SPA   MSFC
DAVM: L     2028                        //DP:17 2028 SPS Xxxx2
      SPA   MSFC
DAJ1: L     2024                        //DP:99 2024 Jesma 1
      SPA   MSFC
DAJ2: L     2019                        //DP:98 2019 Jesma 2
      SPA   MSFC

//Aufruf SFC12 "D_ACT_DP"
MSFC: T     "D_ACT_LADDR"               //logische Adresse des DP-Slaves, hier: Diagnoseadresse

      L     2                           //SFC12 MODE: 0=Auskunft, 1=aktivieren, 2=deaktivieren
//      L     0                           //#### TEST: nur Auskunft ######
      T     "D_ACT_MODE"

      CALL  "D_ACT_DP"
       REQ    :="Always1"               //(Merker immer True)
       MODE   :="D_ACT_MODE"
       LADDR  :="D_ACT_LADDR"
       RET_VAL:="D_ACT_RET_VAL"         //(MW...)
       BUSY   :="D_ACT_BUSY"

      U     "D_ACT_BUSY"                //noch beschäftigt
      SPB   EDAC

      L     "D_ACT_CNT"
      INC   1                           //nächster DP-Slave von Liste
      T     "D_ACT_CNT"

//Beobachten
EDAC: L     "D_ACT_RET_VAL"

Mit Safety kenne ich mich nicht aus.

Harald

 

[JesperMP]

Ich arbeite auch nicht mit Safety SPS.
Aber für Maschinen mit Safety-SPS und Optionshantierung wird es (von Kollegen) so gemacht:
Die Safety Funktionen für die deaktivierte Busteilnehmer werden 'gemutet' in das Safety-Programm. Dies wird gesteuert über realen Safety-Eingänge. Bei die Installation muss man Brücken einlegen in dafür vorbereitete Safety-Eingänge in die Hauptsteuerung. Das nicht-Safety Programm hat dabei kein Einfluss.
Ich weis nicht ob den Zugang zu diese Safety-Eingänge gesperrt oder plombiert ist. Ich wurde es aber überlegen. Man muss darüber denken wie man beweist das niemand die Safety gemutet hat wenn ein Unfall passiert ist.
In das nicht-Safety Programm werden die nicht-installierte Busteilnehmer deaktiviert. Dies aber nur dafür dass es keine Busstörungen gibts.

 

[Drumfan159]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie soll das mit dem fehlersicheren Teil funktionieren, also wenn an den dezentralen Gerätschaften F-E/A´s verbaut und verwendet sind?

Wieso soll das nicht gehen? Wenn ich das NOT HALT Bit z.B. einer Dezentralen Peripherie nicht mehr abfrage kann ich meinen Gesamt NotHalt ja trotzdem aktiv lassen

 

[david.cordier]

Wieso soll das nicht gehen? Wenn ich das NOT HALT Bit z.B. einer Dezentralen Peripherie nicht mehr abfrage kann ich meinen Gesamt NotHalt ja trotzdem aktiv lassen

Wenn eine F-Peripherie projektiert aber nicht erreichbar ist geht die F-CPU normalerweise in Stop, ob und wie dies umgangen werden kann ist mir leider nicht bekannt. GGF. mit Ersatzwerten logisch 1, aber Achtung was passiert wenn Aktiv und F-E/A Karte gezogen wird?! Ersatzwert 1, Not Halt oder sonstige SF ohne Funktion.
Bei solchen Ausbaustufen lassen wir die F-Module alle immer da, sprich nur Stationen ohne F können de- bzw. aktiviert werden.

Gruß

 

[david.cordier]

Wenn eine F-Peripherie projektiert aber nicht erreichbar ist geht die F-CPU normalerweise in Stop, ob und wie dies umgangen werden kann ist mir leider nicht bekannt. GGF. mit Ersatzwerten logisch 1, aber Achtung was passiert wenn Aktiv und F-E/A Karte gezogen wird?! Ersatzwert 1, Not Halt oder sonstige SF ohne Funktion.
Bei solchen Ausbaustufen lassen wir die F-Module alle immer da, sprich nur Stationen ohne F können de- bzw. aktiviert werden.

Gruß

Fehlinformation, geht wohl.
https://support.industry.siemens.com/cs/mdm/54110126?c=115694764811&lc=de-DE

Gruß

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fehlinformation, geht wohl.
https://support.industry.siemens.com/cs/mdm/54110126?c=115694764811&lc=de-DE

Zitat aus die FAQ:

Eine sichere Auswahl/Erkennung einer Stationsoption nehmen Sie mit fest auf M/L+ verdrahteten Eingängen einer F-Peripherie vor.

Genau so machen wir es.