PCS7 konformes G120D Baustein incl. Treiber / Diagnose

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi zusammen

Aus gegebenem Anlaß wird hier der Bedarf gesehen, einen PCS7 konformen G120D Baustein incl. Faceplate zu creieren.
Wie würde man sinnvollerweise dabei vorgehen ?

G120 wird ja schon beim "Baugruppentreiber erzeugen" nicht unterstützt. Diagnose etc. wäre aber wichtig.

Dank im Voraus

 

[ducati]

Hi zusammen

Aus gegebenem Anlaß wird hier der Bedarf gesehen, einen PCS7 konformen G120D Baustein incl. Faceplate zu creieren.
Wie würde man sinnvollerweise dabei vorgehen ?

das kannst Du vergessen, wenn Du nicht wenigstens ein par Jahre PCS7 Erfahrung hast...

...

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

das kannst Du vergessen, wenn Du nicht wenigstens ein par Jahre PCS7 Erfahrung hast...

...

So eine Raketentechnik steckt da aber nun auch nicht drin. Ich hatte nur einen PCS7 "Schnupperkurs" und habe in meinem ersten PCS7-Projekt direkt einen eigenen Baustein inkl. Faceplate erstellt. Einigermaßen fit in WinCC und SCL sollte man aber schon sein. Es gibt von Siemens auch einen Styleguide bezüglich Aufbau und Aussehen der Faceplates. Allerdings hatte mein Baustein nur auf internen Daten gearbeitet.

Wenn ich in PCS7 andere Profibusteilnehmer wie z.B. FUs, Schieber, Messungen habe die von PCS7 baugruppentreibermäßig nicht unterstützt werden, schreibe ich mir dazu einen eigenen Treiber den ich dann vor die APL-Bausteine vorschalte, der die entsprechenden Diagnosedaten liefert und den Signalstatus in der Wert-Struct passend setzt.

 

[Draco Malfoy]

das kannst Du vergessen, wenn Du nicht wenigstens ein par Jahre PCS7 Erfahrung hast......

Hi ich finde deinen Kommentar ziemlich sinnfrei und destruktiv. Du kannst meine Erfahrung ja nicht abschätzen da wir uns nicht kennen. Es hat aber auch nichts mit der Fragestellung zu tun. Ich möchte einfach wissen, wie das Workarround aussieht und ob es dazu irgendwelche Literatur außer dem Dokument "Bibliotheken APL Styleguide" gibt. Das Dokument ist schon ziemlich nützlich, erfasst allerdings nicht alles.

Speziell interessiert mich, wie ich bei Geräten vorgehe, die vom BG-Treiber nicht erfasst sind.

- Gibt es eine Möglichkeit, den Baugruppentreiber selbstständig zu erweitern ?
- Wie kann ich dafür die notwendigen Steuerdateien für CFC anlegen, damit meine Bausteine schon bei der Hardware automatisch in die "@..."-Pläne eingefügt werden ?
- Wie würde man den fehlenden Diagnoseast sinnvollerweise ergänzen ? Gibt es dazu irgendwelche grundsätzliche Konzepte, die man öffentlich einsehen darf ?

Das Schema wonach die Diagnose unter der Basic Library aufgebaut ist, lässt sich ja grob in die CPU-SUBNETZ-RACK-CHANNEL Hierarchie aufteilen. Mir fehlen an der Stelle die RACK und CHANNEL - Anteile, wobei die Frage ist, ob ich die bei einem Gerät wie G120 tatsächlich getrennt aufbauen kann, eher wird es nämlich einfach ein Gerätetreiber der das Rack und die Module diagnostiziert und die zyklischen / azyklischen Datenkanäle nach oben zur Verfügung stellt. Hat schon mal einer damit Erfahrung gehabt ?

 

[Draco Malfoy]

So eine Raketentechnik steckt da aber nun auch nicht drin.

Ne, das nicht. Mein Problem ist eher, daß auch die grundsätzlichen Konzepte zum Beispiuel zum Aufbau der BG-Treiber z.T. unter Verschluss gehalten werden, sonst müsste man ja vielleicht nicht überall das Rad neu erfinden.

Ich hatte nur einen PCS7 "Schnupperkurs" und habe in meinem ersten PCS7-Projekt direkt einen eigenen Baustein inkl. Faceplate erstellt. Einigermaßen fit in WinCC und SCL sollte man aber schon sein.

Ich habe auch schon Bausteine erstellt, auch faceplate-fähige. Ich möchte diesmal jedoch etwas creieren was 1) ausgereift ist und 2) sich nahtlos in das Konzept einfügt.

Wenn ich in PCS7 andere Profibusteilnehmer wie z.B. FUs, Schieber, Messungen habe die von PCS7 baugruppentreibermäßig nicht unterstützt werden, schreibe ich mir dazu einen eigenen Treiber den ich dann vor die APL-Bausteine vorschalte, der die entsprechenden Diagnosedaten liefert und den Signalstatus in der Wert-Struct passend setzt.

An der Stelle gerne etwas mehr Details.

Wie sieht dein Treiber aus ? Liest er einfach zyklisch den Zustand der BG über SFC51 RDSYSSTAT aus und verarbeitet die Diagnoseinformationen ? Wertet dein Treiber auch die Informationen aus den ALARM-OB aus ? Werden auch Diagnosealarme empfangen ? Werden Meldungen generiert ? Wenn deine BG ein Bus-Device ist, spricht also ein RACK und SUBMODULE hat - wie realisierst Du dann die Diagnose ? Getrennt für Rack / Slot oder nur einmal für das gesamte Gerät ?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie sieht dein Treiber aus ? Liest er einfach zyklisch den Zustand der BG über SFC51 RDSYSSTAT aus und verarbeitet die Diagnoseinformationen ? Wertet dein Treiber auch die Informationen aus den ALARM-OB aus ? Werden auch Diagnosealarme empfangen ? Werden Meldungen generiert ? Wenn deine BG ein Bus-Device ist, spricht also ein RACK und SUBMODULE hat - wie realisierst Du dann die Diagnose ? Getrennt für oder nur einmal für das gesamte Gerät ?

Ein Profibus-Teilenehmerausfall wird von PCS7 automatisch mit entsprechenden Meldetext gemeldet, auch wenn der Teilnehmer nicht PCS7-kompatibel ist. Der Teil ist auf jeden Fall immer erschlagen (solange du nicht beispielsweise Profinet in PCS7 v7 verwendest, was nicht freigegeben ist - alles schon gesehen).

Für meine eigenen Treiber habe ich schon verschiedene Varianten eingesetzt. Einmal einen eigenen globalen Diagnosebaustein der mir einen Teilnehmerausfall an einem Ausgang meldet, und den ich dann mit meinem eigenen Treiberbaustein manuell verschalten muss, oder wenn mein Treiber einen ganzen Bereich via DP_SEND/RECV liest, dann über den Rückgabewert der Funktionen.
Letzteres ist mehr Plug&Play, weil du nur den Baustein in deinen Plan ziehen musst und eine Startadresse z.B. des FUs im EA-Bereich angeben musst. Mit dem Nachteil, dass dieses dann nicht mehr in den Querverweisen auftritt.
Ich habe auch nicht hochkomplexe Antriebe, FUs nur mit U/f Kennlinie wo ich dann Strom / Istfrequenz über die Begleitwerte der APL-Bausteine komfortabel erschlagen kann.

Erweiterte Meldungen lassen sich auch über die externen Meldeobjekte mit Verbindung recht einfach an APL-Bausteine anbinden, sodass diese Meldungen dem Antrieb zugehörig (d.h. im Faceplate) gemeldet werden.
So eine Kombination an Bausteinen lässt sich auch als wiederverwendbares Plan-In-Plan Objekt erstellen, auch wenn ich das selber etwas unpraktisch finde.

Mit der Diagnose würde ich das nicht zu weit treiben, meiner Erfahrung nach interessiert das von den Bedienern eh keinen. Meldungen kannst du auch einen Begleitwert mitgeben, z.B. FU Störungsnummer.
Wirklich automatisch einen Baugruppentreiber erzeugen lassen wie das bei den Siemens-Baugruppen gemacht wird, ist bei eigenen Bausteinen soweit ich weiß nicht möglich.

 

[Draco Malfoy]

Mit der Diagnose würde ich das nicht zu weit treiben, meiner Erfahrung nach interessiert das von den Bedienern eh keinen.

Das Problem ist, es kann sein daß diese Bausteine später noch von jemand anders genutzt werden müssen, also Inbetriebnehmern etc. Sprich Leuten, die vielleicht auch mal Flüchtigkeitsfehler machen oder eben das Funktionsprinzip nicht kennen. Mein Ansatz war daher folgender (Es geht sich alles um PROFINET) :


- Übergebene Diagnoseadresse des Submoduls mit LGC_GEO auflösen, dann mit GEO_LGC die Basisadresse des Master-Rack bestimmen (Adressen müssen verschieden sein);
- Auf die Basisadresse des Submoduls SFC51 mit "0C91" drüberlaufen lassen; Wenn alles OK ist, zyklische / azyklische Kommunikation freigeben;
- Wenn Baugruppe z.B. falsch parametriert - zyklische Kommunikation sperren, azyklische Freigeben;
- Wenn die Diagnose des Submoduls Mist liefert, dann SFC51 mit Bezug auf die Basisadresse des Master-Rack aufrufen;
- Meldungen mit entsprechenden Begleitwerten generieren;

Bei Ablauf im OB82 mit SFB54 Diagnose empfangen - GEO Daten abgleichen, ggf. Meldungen generieren;
Bei Ablauf im OB83 / OB 86 ebenfalls GEO Daten abgleichen, ggf. Meldungen generieren.

Was meint Ihr.

 

[Thomas_v2.1]

Ich würde mich darauf beschränken solche grundlegenden Parametrierungsfehler nur im SPS-Programm am Baustein im Detail zu melden. In der OS dann nur eine Meldung "Parametrierungsfehler" oder etwas in der Art, und dann muss jemand mit entsprechendem Fachwissen nachsehen was dort nicht passt. Solche Fehler kann ein OS-Bediener im Normalfall nicht beheben, und dürfen nach der Inbetriebnahme nie wieder auftreten.

Das alles zu diagnostizieren kann man ja machen, aber ich würde das nicht an die OS alles im Detail hochmelden. Dort nur "funktioniert" oder "funktioniert nicht", und wenn nicht funktioniert, dann nur einen Anhaltspunkt wo jemand mit Sachverstand zu suchen hat. Außer dein PCS7-System steht nur auf einer klein abgesteckten Anlage. Aber meistens sind das doch Anlagen mit mehreren zehntausend Meldungen, und da interessieren den Anlagenfahrer die Details nicht, bzw. er wird dich dafür hassen wenn du ihn mit zu vielen Details "zumüllst".

 

[Draco Malfoy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, so habe ich mir das auch gedacht. Intern im Programm würde man anhand der Fehlercodes dann sehen, was nicht stimmt. Bist Du sicher, daß man keine eigenen Zusatzlibrarys für BG-Treiber anlegen kann ? CFC lässt ja beim Generieren die Option offen, daß man zusätzliche Bibliotheken dazu nehmen kann. Zwischenzeitlich hat Siemens auch eine PCS7-fähige UPS/PSU Library rausgebracht, die Treiber und Modulbausteine enthält, welche in der Basic Library nicht enthalten sind.

 

[Thomas_v2.1]

Wie das Generieren der Baugruppentreiber funktioniert habe ich mir noch nie im Detail angesehen.
Gerade bei eigenen Bausteinen würde ich persönlich auf zu viel "Magie" bei PCS7 verzichten. Ich habe es selber schon oft genug gehabt, dass selbst die PCS7 Baugruppentreiber für Siemens Baugruppen in einem Fehlerstatus hängenbleiben, weil irgendein Fehler-OB nicht zuverlässig mitbekommen wurde. Gerade bei der Auswertung in Fehler-OBs musst du viele verschiedene Kombinationen beachten (Abschaltung CPU bei Fehler, Zuschaltung mit Fehler, Kaltstart, Warmstart usw.), dass ich eine einfache Auswertung im Standard-Task immer vorziehe.

 

[Draco Malfoy]

Gerade bei eigenen Bausteinen würde ich persönlich auf zu viel "Magie" bei PCS7 verzichten. Ich habe es selber schon oft genug gehabt, dass selbst die PCS7 Baugruppentreiber für Siemens Baugruppen in einem Fehlerstatus hängenbleiben, weil irgendein Fehler-OB nicht zuverlässig mitbekommen wurde.

Interessant. Habe mich schon oft gefragt, ob das passieren kann, daß man einen Alarm-OB aus welchen auch immer Gründen "verpasst", z.B. bei Überlastung der CPU.

Intern machen die Treiber-FB das nämlich so, um sicherzustellen, daß ein SFC51 Aufruf innerhalb eines Zyklus abgearbeitet werden kann:

    IF PNIO_ADR <> 0 THEN
        REPEAT
            (* Module status information centrally or at a PROFIBUS DP/PROFINET *)
            RETURN_CODE         :=      RDSYSST     (
                                                    REQ         :=  TRUE,
                                                    SZL_ID      :=  W#16#C96, //Module status information centrally or at a PROFIBUS DP/PROFINET
                                                    INDEX       :=  INT_TO_WORD(PNIO_ADR),
                                                    BUSY        :=  tPNIO_ADR,
                                                    SZL_HEADER  :=  SZL_HEADER,
                                                    DR          :=  BGR_ZUST
                                                    );
                                                    
        UNTIL NOT OB_START_bool[7] OR NOT tPNIO_ADR END_REPEAT;

Gerade bei der Auswertung in Fehler-OBs musst du viele verschiedene Kombinationen beachten (Abschaltung CPU bei Fehler, Zuschaltung mit Fehler, Kaltstart, Warmstart usw.), dass ich eine einfache Auswertung im Standard-Task immer vorziehe.

Ich wollte eigentlich die Stati der SFC51-Aufrufe mehr intern im Programm nutzen, und die Alarm-OB Aufrufe dazu gebrauchen, daß entsprechende Messages an- oder abgemeldet werden. In Etwa so:

IF INI_ALRM AND EN_MSG THEN
    
    ALARM_8P_1  (   
                EN_R    :=  TRUE, 
                ID      :=  W#16#EEEE, 
                EV_ID   :=  EV_ID, 
                SIG_1   :=  _V_ASIG0[0],    (* @1%d@/@2%d@/@3%d@: Ausfall Pufferbatterie    *)
                SIG_2   :=  _V_ASIG0[1],    (* @1%d@/@2%d@/@3%d@: Ausfall Pufferspannung    *) 
                SIG_3   :=  _V_ASIG0[2],    (* @1%d@/@2%d@/@3%d@: Ausfall 24V-Versorgung    *) 
                SIG_4   :=  _V_ASIG0[3],    (* BG @1%d@/@2%d@/@3%d@: Ausfall                *) 
                SIG_5   :=  _V_ASIG0[4],    (* BG @1%d@/@2%d@/@3%d@: Falsch oder gestört    *) 
                SD_1    :=  bySUBN1_ID, 
                SD_2    :=  byRACK_NO, 
                SD_3    :=  bySLOT_NO
                );
                
    sbASIG0     :=  ASIG0;
    MSG_STAT    :=  ALARM_8P_1.STATUS;
    
    IF NOT ALARM_8P_1.DONE AND NOT ALARM_8P_1.ERROR AND ALARM_8P_1.STATUS <> W#16#000B THEN 
        INI_ALRM    :=  FALSE; 
    END_IF;
END_IF;