TIA mobile-Panel mit D_ACT_DP deaktiieren/aktivieren

MFreiberger · 6 März 2019

Moin Zusammen,

da der SIEMENS Support mich anscheinend nicht verstehen will oder kann, hier einmal meine Aufgabenstellung:

Ich will vermeiden, dass die Error-LED an der CPU (1515F) leuchtet, wenn das KTP700F (IO-Device) nicht gesteckt ist.
Ein guter Vorschlag von SIEMENS war die Verwendung des D_ACT_DP. Da ich aber i.M. noch keine Testhardware habe,
habe ich weiter gefragt, wie ich erkennen kann, ob das Panel gesteckt ist, wenn ich es vorher mit D_ACT_DP deaktiviert habe.

Kommt das Live-Bit noch an?
Kann ich die Box-ID noch auslesen?
Kann ich die Bereichszeiger auslesen (Bildnummer)?

Ich möchte das KTP700F gerne deaktivieren, wenn es ausgesteckt wurde. Wenn es dann wieder gesteckt wurde will ich es wieder aktivieren.
Gesteckt/ nicht gesteckt usw. auswerten ist kein Problem. Die Frage ist, ob die (ich nenne sie mal Systeminformationen s.o.) noch
angezeigt werden, wenn ich das Panel als Slave vorher deaktiviert hatte?

VG

MFreiberger

Egon323 · 6 März 2019

Also ich hoffe ich kann dir da weiterhelfen.

Der Baustein deaktiviert den betreffenden PN Teilnehmer, schaltet ihn also ab. Beim KTP Mobile verhält es sich so das quasi IO Modul dann "tot" ist. Es gibt also gar keine Rückmeldung mehr zu irgendwas. Das muss auch so sein, denn der eigentliche Sinn ist ja der Module im Betrieb tauschen zu können, Lifebit wäre da wohl fehl am Platze.

ABER

Der Bedienteil geht noch. HMI Kom ist ebenfalls noch aktiv. Also die Verbindung zur CPU und alle damit verbundenen Runtime Features sind noch da. Du kannst also über deinen Zonenprojekterung bzw. Bereichszeiger immer noch erkennen ob das Panel da ist oder nicht.

Die Frage is zu welchen Zeitpunkt du Deaktivieren bzw. Aktivieren willst und wie aber da gibt es wohl verschiedenste Ansätze die man verfolgen kann.

MFreiberger · 6 März 2019

Moin Egon323,

ich detektiere ja über die Bereichszeiger, ob das Panel irgendwo gesteckt ist. Wenn es ausgesteckt wird, bekomme ich das mit und will das Panel als Slave deaktivieren, damit die CPU keinen Kommunikationsfehler erkennen muss. Und vor Allem keine Störung (rote LED) anzeigt. Erstens finde ich das doof (beim Verlassen der Anlage sollte alles grün sein), zweitens ist der Kunde dann etwas nervös.
Soweit so gut. Damit ich das Panel als Slave wieder sauber aktivieren kann, muss ich ja wissen, dass es gesteckt ist. Dazu fällt mir eigentlich nur das LiveBit über den Bereichszeiger "Koordinierung" ein. Das muss natürlich funktionieren, auch wenn das Panel als Slave deaktiviert ist.
Eigentlich muss das funktionieren... Aber ich habe halt keine Hardware zum ausprobieren...

VG

MFreiberger

Egon323 · 6 März 2019

Ich kann aktuell nicht rumprobieren, irgendjemand muss ja das Bruttosozilaprodukt steigern

Allerdings weiß ich das "abschalten beim ziehen" vom Timing her zu spät wäre, zudem musst du voher PROFIsafe trennen sonst bekommst du noch mehr Fehler.

Das deaktivieren würde ich manuell machen (trennen => abschalten => ziehen), aktivieren kann man ja rein theoretisch mit dem Bereichszeiger in der PLC automatisieren.

Es kann aber sein, und das weiß ich leider nicht so genau: Beim abschalten des PNIO ist auch PROFIsafe weg, was passiert wenn das Panel wieder angesteck wird? Muss ich quittieren/eingliedern? Will das der Kunde?

EDIT: hab doch mal kur geschaut: Wenn man PROFIsafe vorher beendet muss man nach stecken ziehen nicht quittieren auch wenn PNIO kurzzeitig vom Netz war (habs mit nemm 400er gemacht das ist ja nicht gepuffert)

MFreiberger · 2 November 2019

Moin,

jetzt nochmal zum Thread-Abschluss:
Es funktioniert. Über den Koordinierungsbereichszeiger erkenne ich am Live-Bit, ob das Panel gesteckt ist.
Wenn es nicht gesteckt ist, deaktiviere ich das Panel als PN-Teilnehmer ==> CPU grün.
Wenn es gesteckt wird, aktiviere ich das Panel wieder ==> das Panel funktioniert und die CPU ist grün.

Vielen Dank für Deine Informationen, Egon323!

VG

Mario

Mecha2211 · 10 Januar 2020

Hallo Mario,

ich hänge derzeit am selben Thema.

Bei mir kommen aber, nach dem Aktivieren Fehlermeldungen "Passivierung der F-Peripherie". Kann man das noch verhindern?

Reihenfolge ist:

1. am Panel Profisafe trennen
2. Panel abstecken
3. Über den F_FB_KTP_Mobile (diag-Ausgang) Werte ich aus, ob das Panel disintegriert ist
4. ich deaktiviere den PN-Teilnehmer
5. über den Bereichszeiger Koordination werte ich aus, dass das Panel wieder gesteckt ist
6. ich reaktiviere den PN-Teilnehmer
7. Das Panel wird wieder reintegriert
8. Passivierung der Panel-Safety
9. Depassivierung der Panel-Safety (Automatisch und nach 120 ms)

Ist kein riesen-Drama, weil die Störung nur wenige Sekunden gemeldet wird, aber mich nervt es trotzdem, weil es ja keine Störung ist, sondern ein gewollter Vorgang.

Interessanterweise schaltet der Not-Halt nicht ab.

MFreiberger · 10 Januar 2020

Moin Mecha2312,

das Passivieren tritt bei dauernd am Profinet aktivierten Baugruppen ja auch auf, z.B. wenn Baugruppenfehler anstehen.

Punkt 7: ich glaube Du meinst nicht reintegriert, sondern aktiviert?

Das Panel ist ja immer zunächst passiviert, nachdem es eingesteckt wurde. Auch wenn es nicht mit D_ACT_DP deaktiviert bzw. aktiviert wurde.
Jeder F-Teilnehmer ist immer zunächst passiviert, wenn es eine Kommunikationsunterbrechung gab.

Man muss die reine Profinet-Kommunikation (wo man Teilnehmer mit D_ACT_DP deaktivieren und aktivieren kann) von der Profisafe-Kommunikation unterscheiden.
Die Profinet-Verbindung ist die Voraussetzung dafür, dass eine Profisafe-Kommunikation arbeiten kann.

Da beim Abstecken die Profisafe-Kommunikation unterbrochen wird (auch, wenn das Panel korrekt abgemeldet wird), kommt das Panel ja auch irgendwann wieder
neu als Profisafe-Teilnehmer hinzu. Dann muss es reintegriert werden (Also das F-Device muss am Controller angemeldet werden).

Das kann man auch mit ACK_NEC = true nicht verhindern, da das automatische Reintegrieren nicht bei Kommunikationsunterbrechung, sondern nur bei Kanalfehlern funktioniert.

VG

MFreiberger

Mecha2211 · 10 Januar 2020

Moin Mario,

danke für Deine Antwort.

Das TIA Information system oszilliert zwischen verschiedenen Begriffen, mal integriert, mal aktiviert und deaktiviert, ohne klare Erkennbarkeit

Aus der Info zu F_FB_KTP_Mobile:

The following HMI device states are possible:

"Removed"

"Integrated"

"Communication error"

"Communication error, acknowledgement required"

Okay, Du hast recht mit dem Punkt dass das passivieren auch bei anderen Baugruppen auftritt.
Ich denke nur, das Profisafe an- und abmelden des Panels passiert ja auf Benutzerbefehl (Systemfunktion des Panels).

Es nervt mich halt dass es dann eine, wenn auch nur kurze, Störmeldung im Diagnosepuffer gibt.

Wir haben auch Kunden, die wollen den SPS-LED-Status über Schnittstelle gemeldet bekommen. Die fragen dann warum immer wieder Störungen auftreten.

Den grundlegenden Vorgang des An-/Abmeldens sowie das Zusammenspiel/Unterschied von Profinet/Profisafe verstehe ich schon.
Ich verstehe auch dass, und warum, ich die Störung des ausfallenden ProfiNET-Devices mit an-/abmelden vor dem Stecken verhindern kann.

Ich kann nach Deiner Ausführung auch nachvollziehen, warum das F-Device passiviert und dann wieder depassiviert werden muss.
Ich hätte nur gern, dass die Systemfunktion des Abmeldens ohne Profisafe-Fehler auch für das anmelden funktioniert.
Aber das bleibt wohl ein Wunsch

JanB1 · 15 Februar 2021

Um diesen alten Thread nochmals auszugraben falls jemand anders auch noch drüber stösst:
Zusammenfassung:

Wir können verhindern, dass die Störungs-LED auf der CPU blinkt wenn das MobilePanel abgezogen wurde, indem wir en Profinet-Teilnehmer (hier das MoPa) abmelden nachdem es getrennt wurde.
Dazu können wir die Funktion "D_ACT_DP" mit dem entsprechenden Modus 2 mit der Hardware-Kennung (Systemkosntante "Hw_Device") des MoPa aufrufen.
Um zu detektieren, ob das MoPa abgezogen wurde können wir den Koordinations-Bereichszeiger des MoPa verwenden (in HMI>Verbindungen>Bereichszeiger definieren, Länge 1 = 1 Word).
Im Koordinations-Bereichszeiger ist auf Bit 2 (Komfortabel über Slice-Zugriff ".%X2") das Lebensbit welches im 1 Sekunden Takt den Wert wechselt.
Mit 2 Flanken (TRUE>FALSE & FALSE>TRUE) welche jeweils die gleiche Ausschaltverzögerung triggern können wir die Abwesenheit des Panels nach frühestens 1 Sekunde detektieren.

Unten ein umgesetztes Beispiel in AWL:

Code:

Name: "FB_MoPa_Abmelden"
Input:
[LIST]
[*]iMoPaKoordination : Word
[*]iMoPaHwDevice : HW_DEVICE
[/LIST]
Static:
[LIST]
[*]statLiveBitMerkerMoPa : Bool
[*]Timer_TOF_MoPa : TOF_TIME
[*]statLetzterZustandMoPa : Bool
[*]D_ACT_DP : Struct
[LIST]
[*]REQ : Bool
[*]MODE : USInt
[*]RET_VAL : Int
[*]BUSY: Bool
[/LIST]
[/LIST]
Temp:
[LIST]
[*]tempLiveBitMoPa : Bool
[*]tempLiveBitFlankeMoPa : Bool
[*]tempZustandMoPa : Bool
[*]tempETTimer : Time
[/LIST]

Code:

//Lebens-Bit auswerten
      U     #iMoPaKoordination.%X2
      =     #tempLiveBitMoPa


      U(
      U     #tempLiveBitMoPa
      UN    #statLiveBitMerkerMoPa
      )
      O(
      UN    #tempLiveBitMoPa
      U     #statLiveBitMerkerMoPa
      )
      =     #tempLiveBitFlankeMoPa


      CALL  #Timer_TOF_MoPa
         time_type:=Time
         IN :=#tempLiveBitFlankeMoPa
         PT :=t#5s
         Q  :=#tempZustandMoPa
         ET :=#tempETTimer


//Aktivierungs/Deaktivierungsauftrag starten
//Aktivierung
      U     #tempZustandMoPa
      UN    #statLetzterZustandMoPa
      SPBN  nAkt


      L     1
      T     #D_ACT_DP.MODE


      SET
      S     #D_ACT_DP.REQ


nAkt: NOP 0


//Deaktivierung
      UN    #tempZustandMoPa
      U     #statLetzterZustandMoPa
      SPBN  nDeakt


      L     2
      T     #D_ACT_DP.MODE


      SET
      S     #D_ACT_DP.REQ


nDeakt : NOP 0


//D_ACT_DP ansteuern
      CALL  D_ACT_DP
         REQ     :=#D_ACT_DP.REQ
         MODE    :=#D_ACT_DP.MODE
         LADDR   :=#iMoPaHwDevice
         RET_VAL :=#D_ACT_DP.RET_VAL
         BUSY    :=#D_ACT_DP.BUSY


      U     #D_ACT_DP.REQ
      UN    #D_ACT_DP.BUSY
      R     #D_ACT_DP.REQ


//Merker aktualisieren
      U     #tempLiveBitMoPa
      =     #statLiveBitMerkerMoPa


      U     #tempZustandMoPa
      =     #statLetzterZustandMoPa

Ich werd die Funktion wahrscheinlich zu einem späteren Zeitpunkt noch in SCL "übersetzen", aktuell hab ich sie in AWL benötigt.

PN/DP · 15 Februar 2021

JanB1 schrieb:
Mit 2 Flanken (TRUE>FALSE & FALSE>TRUE) welche jeweils die gleiche Ausschaltverzögerung triggern können wir die Abwesenheit des Panels nach frühestens 1 Sekunde detektieren.

(...)

Code:

//Lebens-Bit auswerten U( U #tempLiveBitMoPa UN #statLiveBitMerkerMoPa ) O( UN #tempLiveBitMoPa U #statLiveBitMerkerMoPa ) = #tempLiveBitFlankeMoPa

Befreie Deinen Geist, denke nicht so umständlich. Erwarte nicht explizit eine steigende oder eine fallende Flanke, sondern erwarte daß das Signal sich ändert

Code:

      X     #tempLiveBitMoPa
      X     #statLiveBitMerkerMoPa
      =     #tempLiveBitFlankeMoPa

Harald

JanB1 · 16 Februar 2021

PN/DP schrieb:
Befreie Deinen Geist, denke nicht so umständlich. Erwarte nicht explizit eine steigende oder eine fallende Flanke, sondern erwarte daß das Signal sich ändert

Code:

X #tempLiveBitMoPa X #statLiveBitMerkerMoPa = #tempLiveBitFlankeMoPa

Harald

Heh. Das gute Alte XOR. Stimmt, das gibts ja auch noch. Schon so lange nicht mehr gebraucht.

TIA mobile-Panel mit D_ACT_DP deaktiieren/aktivieren

MFreiberger

Level-3

Egon323

Level-1

MFreiberger

Level-3

Egon323

Level-1

MFreiberger

Level-3

Mecha2211

Level-2

MFreiberger

Level-3

Mecha2211

Level-2

JanB1

Level-2

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

JanB1

Level-2

Similar threads

Wir schützen deine Privatsphäre