Profibus/Profinet-Teilnehmer Diagnose

Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem kompletten Datensatz habe ich auch gelesen. Es bleibt jedoch offen, was Siemens unter "Datensatz" versteht. Weiter unten in der Onlinehilfe unter "SZL_HEADER" läßt Siemens verläuten daß die SZL-Teilliste aus mehreren Datensätzen besteht bzw. bestehen kann. Die SFC muß in jedem Zyklus irgendwo ihre Ergebnisse ablegen. Vielleicht macht das aber auch irgendwie das Betriebssystem.
 
Ich habe "meinen" Baustein noch einmal angepasst und mit ein wenig Beschreibungstext versehen!

Grüße

Marcel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
da ihr ja scheinbar noch ein paar Fragen zur SFC51-Systematik habt - das Folgende war die Grundlage meines Bausteins (ich habe es aber nicht weiter kommentiert) :
- Der SFC51 läuft asynchron. Bestimmte Aufgaben lassen sich sogar gleichzeitig anstossen. Vom grundsätzlichen Verhalten wird zunächst der RET_Val des SFC <>0 und je nach Auftrag kommt ggf. auch der Busy. Der angestossenen Auftrag ist dann abgearbeitet, wenn der RET_Val wieder 0 ist.
- Bei meiner Vorgehensweise ergibt so etwas dann eine Schrittkette. Wenn laut Beschreibung nicht sicher ist, ob die Parallel-Bearbeitung der Aufträge dem Herrn S. genehm ist so lasse ich es vorsichtshalber - ich frage also immer nur einen "Auftrag" ab.
- An die Geschichte mit den TEMP-Arrrays hatt ich auch schon mal gedacht, hatte aber festgestellt, dass die Bit-Einträge in die Liste so "nach und nach" erfolgt sind. Da verbietet sich dann für mich das TEMP-Array - im Übrigen : kommt es auf den I-DB-Speicher wirklich an ?
- Die Trigger-Geschichte kommt vom dem "alten" FC125 von Siemens. Den hatte ich bislang in meiner Auswertung drin. Hier war es so gedacht, dass derselbe durch ein in den jeweiligen OB's gesetztes Trigger-Bit aktiviert wurde und der Baustein selbst dieses Bit dann wieder gelöscht hat. Das System hatte ich einfach beibehalten (never change a running System ...)

Ich glaube, das war es - ach ja, ich nutze den OB122 zum Triggern ...

Gruß
Larry
 
Danke Larry,
sag mal wie handhabst du das den mit den OB122, lässt du den Trigger permanent neu zu
und pfeifst auf die zusätzliche Systembelastung oder hast du da eine Rafinierte Maßnahme
und fängst das irgendwie ab?

Gruß RN
 
Hallo RN,
ich muss dir gestehen, dass ich mir über eine mögliche System-Belastung an der Stelle nie wirklich Gedanken gemacht habe. Auf der anderen Seite wollte ich aber auch nur im speziellen den Ist-Zustand der Slaves in der Visu anzeigen können (der Sinn dieses Baustein, hatte ich aber auch glaube ich schon geschrieben, war/ist, den Slave-Status für die Visu aufzubereiten. Jetzt ist es aber auch (Zitat Marcel) wohl so, dass von dem Baustein anscheinend keine "echte" Zykluszeit-Belastung ausgeht - immerhin möchte Marcel seinen FB ja kontinuierlich aufrufen ....

Dem dargestellten FB126 ist ein etwas einfacherer FB125 vorausgegangen, der allerdings den Status nicht in Bytes zusammengefasst hat (sondern nur die Bit-Array's hatte) und eben kein PN konnte. Dort hat es aber auch nie Zeitprobleme gegeben.

Die Idee von Marcel, die Größe des Byte-Array's zu limitieren, ist gar nicht so schlecht. Kein Mensch wird in einer Anlage irgendwann einmal 2048 PN-Teilnehmer haben - und wenn doch dann kann man ja immer noch eine Variante des gleichen FB's generieren. Den Ansatz werde ich also für mich aufgreifen (mit je einer Konstanten für PB und auch PN im SCL-Baustein).

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es wird doch eine interessante Diskussion :) Das Freut mich!

Ich werde bei mir noch den RET_VAL auswerten, um ganz sicher zu gehen. Die "Schrittkette" habe ich soweit ja auch übernommen.
Warum habe ich die Auswertung in den TEMP-Bereich geschmissen? Ich weis es selbst nicht mehr! Ich muss aber sagen es funktioniert wirklich einwandfrei!
Es stimmt zwar das Speicher nichts kostet, aber es ist doch schön einen schlanken Baustein zu haben!

Grüße

Marcel

Edit: Der Ausgang am SFC51 für die Daten ist OUTPUT. D.H. der Baustein wird vermutlich intern einen BLK_MOV auf die Variable an diesem Ausgang machen, somit wird mein TEMP-Array immer komplett überschrieben.
Das Änderungen nur Blockweise passieren kann am Internen Ablauf liegen, aber ich behaupte trotzdem das die Daten konsistent von Intern an den OUTPUT geschrieben werden, und das TEMP deshalb keine Probleme macht!

Edit2: Habe den Baustein weiter vorn angepasst, und bei der Fehlerauswertung sogar noch einen Fehler im PN-Teil gefunden und natürlich beseitigt...
 
Zuletzt bearbeitet:
Es wird doch eine interessante Diskussion :) Das Freut mich!

Ich muss auch zugeben, dass der Thread mir Spaß macht - ich hätte allerdings schon erwartetet, dass sich mit dem Thema schon mehr User auseinandergesetzt haben. Ist wohl nicht so - sei es drum - dann haben wir hier sicher etwas angeregt ...

Zu deinen TEMP-Array's noch einmal :
Bleiben wir einmal bei einem der Aufrufe des SFC51. Hier wird z.B. im Zyklus 1 der Auftrag gegeben und im Zyklus 5 das Ergebnis zurück geliefert, von mir aus konsistent - wobei sich das nicht so ganz mit meinen gemachten Beobachtungen deckt. Jetzt ist es aber so, das du hier mit einem SFC (also nichts mit Gedächtnis) arbeitest. Bei dir weiß ich jetzt nicht aber bei mir würden die Daten nun z.B. im Zyklus 50 in das Byte-Array übernommen. Ich denke, dass der TEMP-Bereich hier auf jeden Fall recht groß wird und du vermutlich sonst nicht so viele Bausteine mit einem großen TEMP-Bereich hast. Dadurch funktioniert dein TEMP-Array im Augenblick wahrscheinlich korrekt. Was ist aber, wenn du noch einen Baustein hast, der einen ähnlich großen Temp-Bedarf hat und ihn auch bearbeitet. Was passiert jetzt mit den Ergebnissen der Auswertung ? Kannst du mir folgen ?

Gruß
Larry
 
Hallo LL,
spaß macht mir das auch, ich gestehe ich habe mir dazu noch nie gedanken gemacht, aber in irgeneinen Thread, den der Marcel
anscheinend auch gelesen hat, kochte es auch bei mir hoch und schwups erstellte Marcel diesen Thread ;)

Zur Zeit glaube ich auch noch nicht das es mit dem Temp Bereich funktioniert, deshalb würde ich das auch lieber Statisch sehen.
Ich habe mir gerade mal einen Baustein in AWL geschrieben, das liegt mir mehr und verstehe ich sofort.
Dieses Zusammenfassen von PN und DP finde ich in beiden Bausteinen nicht glücklich gelöst. Ich würde eher dazu tendieren das getrennt
zu machen, da ich glaube das in der Zukunft DP sowieso immer mehr aussterben wird, oft wird sowieso nur das eine oder andere Bussystem
genutzt. Bei uns kommt es sogar vor das wir mehrere PN Stränge aufmachen, so kann mann dann für jeden Busstrang eine eigene Instanz
machen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hier jetzt mal mein Beispiel (noch im Endwurfs-Status)
Getriggert wird er zZ vom OB86 und OB30 (5000ms) und ist nur zur DP-Diagnose.

Anhang anzeigen DP_DIAG.txt

EDIT_1: Version 2, mit Diagnoseablage im Byte und Aktivierungszustand. Wegen Kommentar wurde die Quelle
hochgeladen.
EDIT_2: Version 3, noch mal ein wenig aufgehübscht
 
Zuletzt bearbeitet:
Also nach vielem hin und her muss ich euch recht geben! Ich werde nun auch auf STAT umschwenken, die paar Byte die es verschwendet... scheiss drauf.

Mein Baustein kombiniert ja nicht PN und PB, sondern ist "exklusiv" es geht PB ODER PN, und nicht beides auf einmal.
Es ist als würdest du zwei Bausteine machen, ich hab es halt kombiniert damit ich Bausteine spare und weil ich zu Faul zum Suchen bin.

Die Idee mit den verschiedenen Instanzen ist gut, da ich diesen Fall aber nie haben werde, werde ich das nicht berücksichtigen!

Grüße

Marcel
 
Hallo Marcel,
Mein Baustein kombiniert ja nicht PN und PB, sondern ist "exklusiv" es geht PB ODER PN, und nicht beides auf einmal.
Es ist als würdest du zwei Bausteine machen, ich hab es halt kombiniert damit ich Bausteine spare und weil ich zu Faul zum Suchen bin.
Naja ... bei mir ist es halt so - das war dann meine Vorgabe an mich ... Ich hatte aber auch einen Moment lang überlegt, zu dem PB, den ich schon hatte, noch einen PN zu bauen. Ich fand halt nur den "alten" FB125 mittlerweile auch nicht mehr so toll ...

Die Idee mit den verschiedenen Instanzen ist gut, da ich diesen Fall aber nie haben werde, werde ich das nicht berücksichtigen!
Das wäre doch aber gar kein Problem. Einfach die ID auf die Schnittstelle und alles ist OK. Das wäre auch noch so ein Ding, dass ich mir für meinen FB vorstellen könnte. Auf der anderen Seite habe ich bislang auch nie 2 PB's in einer Anlage gehabt - die Chance für 2 PN's ist hier dann nicht größer.

[OT]
Den PN so als Mass aller Dinge herauszustellen sehe ich persönich noch "ein wenig" differenziert. Wenn ich z.B. ein I-Device (jetzt nur von der Einbindung her) mir einer "bereits projektierten PB-Steuerung vergleiche so würde ich sagen : hier hat Siemens echt einen Schritt rückwärts gemacht. So was muss doch komfortabler und nicht komplizierter werden ...
[/OT]

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@RN:
Ein schöne Bereicherung - das Ganze als AWL-Code. Ich selbst wäre allerdings nicht im Traum darauf gekommen, dass in AWL zu machen.

Für PB ist es relativ egal - aber für einen PN-Baustein solltest du dir genau den Aufbau und die Verwendung der Array's reinziehen. An der Stelle hatte ich "ein bißchen" Grundlagenforschung betreiben müssen. Irgendwo findet man es dann irgendwann auch in der S7-Doku zum SFC51 - das war aber nicht ganz so einfach. Das könntest du dir aber ersparen.

...
 
Ich befass mich gerade etwas ausführlicher mit der Diagnose PB und PN. Zur PB Diagnose hab ich nun einen DiagnoseRepeater verbaut, den Siemens FB126 eingesetzt und die Visu dazu übernommen und angepasst... Der Baustein erkennt bei mir aber PB. PN wird nicht erkannt. Ich finde auch die Dokumentation dazu auch sehr spärlich. Versteh noch nicht so wirklich wie der Baustein arbeitet...

Die Bausteine von euch könnte ich vermutlich deutlich besser an mein System anpassen, und es wäre die Diagnose zu PN und PB möglich.
Was beim Siemens FB126 nicht schlecht ist, das die Leitungsdiagnose vom DR ausgelesen wird (wenns auch nicht immer richtig funktioniert)

Außerdem wär für mich noch wichtig die "Qualität" des PB/PN zu beurteilen. Ich hab manchmal Probleme mit Kabelbrüchen oder losen Steckverbindungen. Wie könnte ich die am besten erkennen?
 
Zuletzt bearbeitet:
Hallo Leute,

danke für eure Bausteine. Allerdings sind mir einige Dinge noch schleierhaft, würde mich über Aufklärung sehr freuen:

@LL, @Matze:
  1. Warum deklariertihr Abfrage_PN_Slaves.X als ARRAY[0..2047] OF BOOL, anstatt es gleich als ARRAY[0..127] OF WORD zu machen, ohne den Umweg über at_Abfrage_PN_Slaves.X ?
  2. Außerdem sagt die S7-SCL-Hilfe zum Thema ARRAY: "Variablen vom Typ ARRAY werden Zeile für Zeile angelegt. Jede Dimension einer Variablen vom Typ BOOL, ... enden an einer BYTE-Grenze." --> heisst das ARRAY[0..2047] OF BOOL könnte ich auch mit 2048 BYTE füllen ? :confused:
  3. Wozu dient at_Abfrage_PN_Slaves? Warum schaltet man nicht direkt Abfrage_PN_Slaves auf den SFC51.DR (so wie in dem PB-Teil)?
  4. Müsste nicht korrekterweise [0..127] anstelle von [0..128] stehen (bei nullbasierter Zählweise), alternativ natürlich [1..128] (einsbasiert), damit der Array-Index mit der TN-Nummer korrespondiert.
  5. Wie lautet die Syntax, wenn ich die Länge von at_Abfrage_PN_Slaves per IN-Parameter "ANZ" vorgeben möchte? at_Abfrage_PN_Slaves[1..ANZ] ? oder at_Abfrage_PN_Slaves[0..(ANZ-1)] ? oder wie geht das?
  6. EDIT: @Matze: Wozu hast du Abfrage_PN_Slaves.mit_Stoerung deklariert, wenn ihr es nie verwendet ?? Oder bin ich blind? :confused:
Danke
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu 2.:
Kannst in ein Array[0..2047] of Bool keine 2048 Bytes ablegen. Dein Array hat Platz für 2048 Bit und für Deine 2048 Byte würdest du 16384 Bit benötigen. Also kannst du in deinem Array nur die 256 Byte ablegen. Und ich denke jedes der Byte entpricht einen PN-Device.
 
Hallo Flux,
Warum deklariert ihr Abfrage_PN_Slaves.X als ARRAY[0..2047] OF BOOL, anstatt es gleich als ARRAY[0..127] OF WORD zu machen, ohne den Umweg über at_Abfrage_PN_Slaves.X ?
Weil es mir so die Möglichkeit bietet, den Zustand sinnvoll einsehen, bzw. auch einzeln visualisieren zu können.

Außerdem sagt die S7-SCL-Hilfe zum Thema ARRAY: "Variablen vom Typ ARRAY werden Zeile für Zeile angelegt. Jede Dimension einer Variablen vom Typ BOOL, ... enden an einer BYTE-Grenze." --> heisst das ARRAY[0..2047] OF BOOL könnte ich auch mit 2048 BYTE füllen ? :confused:
Nein kannst du nicht - die Größen und die Typen müssen übereinstimmen.

Wozu dient at_Abfrage_PN_Slaves? Warum schaltet man nicht direkt Abfrage_PN_Slaves auf den SFC51.DR (so wie in dem PB-Teil)?
Das habe ich gemacht, weil ich im Script die AT-Sicht einfacher verarbeiten konnte ...

Müsste nicht korrekterweise [0..127] anstelle von [0..128] stehen (bei nullbasierter Zählweise), alternativ natürlich [1..128] (einsbasiert), damit der Array-Index mit der TN-Nummer korrespondiert.
Da hast du wahrscheinlich Recht - das ist mir nur anscheinend bislang nicht aufgefallen weil es Siemens hier auch egal ist ...
Wie lautet die Syntax, wenn ich die Länge von at_Abfrage_PN_Slaves per IN-Parameter "ANZ" vorgeben möchte? at_Abfrage_PN_Slaves[1..ANZ] ? oder at_Abfrage_PN_Slaves[0..(ANZ-1)] ? oder wie geht das?
Siemens läßt keine dynamische Dimensionierung von Datenbausteinen zu.

Wozu hab ihr Abfrage_PN_Slaves.mit_Stoerung deklariert, wenn ihr es nie verwendet ?? Oder bin ich blind? :confused:
Bist du nicht. Der Baustein dient bei mir dazu, den Status für die Visualisierung bereitzustellen - die Visu fragt also den Instanz-DB ab ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Weil es mir so die Möglichkeit bietet, den Zustand sinnvoll einsehen, bzw. auch einzeln visualisieren zu können.

Wie groß muss denn das ARRAY mind. sein, das ich an SFC51.DR hänge (bei PROFINET, also SZL_ID = 0094, 0294, 0694)? Und wie ist DR organisiert? 1 WORD/TN oder? Welche Infos stehen in dem WORD?


Nein kannst du nicht - die Größen und die Typen müssen übereinstimmen.

OK

Siemens läßt keine dynamische Dimensionierung von Datenbausteinen zu.

OK
 
Zuletzt bearbeitet:
Hier ist meine Version für reine PN-Diagnose (basierend auf den bereits vorgestellten Bausteinen ;)). Jedem TN wird ein Bit in IO_DEV_STATE zugeordnet. Triggerung erfolg aus den OBs (82, 83, 86, 100, 122) per OBxx_TRIGGER (Merkerbit) sowie über internen TIMER_RETRIGGER.

Code:
FUNCTION_BLOCK PN_DIAG_SCL

//************************
VAR_IN_OUT
OBxx_TRIGGER : BOOL;
END_VAR

VAR_INPUT
    PN_ID : INT; //100..?
END_VAR

VAR_OUTPUT
    IS_BUSY : BOOL;
    HAS_IO_DEV : BOOL;
    PN_OK : BOOL;
END_VAR        

VAR // static variables
    
    REQ : STRUCT
        REQ1 : BOOL;
        REQ2 : BOOL;
    END_STRUCT;
    
    BUSY : STRUCT
        BUSY1 : BOOL;
        BUSY2 : BOOL;
    END_STRUCT;        
    
    STEP : INT; //0..5
    
    IO_DEV_STATE_RETR : STRUCT
        PLANNED : ARRAY[1..128] OF INT;
        WORKING : ARRAY[1..128] OF INT;
    END_STRUCT;
    
    IO_DEV_STATE : ARRAY[1..128] OF BOOL; //WinCC-Interface (FALSE = OK/NO_INFO; TRUE = ERROR)
    
    IO_DEV_COUNT : INT;

    TIMER_RETRIGGER : SFB4;
END_VAR

VAR_TEMP // temporary variables
    ERROR : INT;
    
    SZL_HEADER : STRUCT
        LENTHDR : WORD;
        N_DR    : WORD;
    END_STRUCT;    
    
    i : INT;
    
    PN_OK_TEMP : BOOL;
END_VAR       
//************************

BEGIN // statements

//IF(IO_DEV_COUNT <= 0) THEN STEP := 5; END_IF; //end

IF((STEP <= 0) AND (OBxx_TRIGGER OR TIMER_RETRIGGER.Q)) THEN
    OBxx_TRIGGER := FALSE; //reset
    PN_OK_TEMP := TRUE;
    STEP := 1;
END_IF;

IS_BUSY := (STEP > 0);    

// PLANNED
REQ.REQ1 := ((STEP = 1) OR (STEP = 2));

ERROR := RDSYSST(REQ := REQ.REQ1
                ,SZL_ID := W#16#0094 //Retrieve planned IO-stations
                ,INDEX := PN_ID
                ,BUSY := BUSY.BUSY1
                ,SZL_HEADER := SZL_HEADER
                ,DR := IO_DEV_STATE_RETR.PLANNED    
                );
                
IF((STEP = 1) AND (BUSY.BUSY1 OR (ERROR = 0))) THEN STEP := 2; END_IF;
IF((STEP = 2) AND NOT BUSY.BUSY1) THEN STEP := 3; END_IF;

// WORKING                
REQ.REQ2 := ((STEP = 3) OR (STEP = 4));

ERROR := RDSYSST(REQ := REQ.REQ2
                ,SZL_ID := W#16#0294 //Retrieve working IO-stations
                ,INDEX := PN_ID
                ,BUSY := BUSY.BUSY2
                ,SZL_HEADER := SZL_HEADER
                ,DR := IO_DEV_STATE_RETR.WORKING    
                );
                
IF((STEP = 3) AND (BUSY.BUSY2 OR (ERROR = 0))) THEN STEP := 4; END_IF;
IF((STEP = 4) AND NOT BUSY.BUSY1) THEN STEP := 5; END_IF;

// EVALUATION
IF(STEP >= 5) THEN
    IO_DEV_COUNT := 0; //reset
    
    FOR i := 1 TO 128 DO
        IO_DEV_STATE[i] := 0; //clear
        
        IF(IO_DEV_STATE_RETR.PLANNED[i] > 0) THEN
            IO_DEV_COUNT := IO_DEV_COUNT + 1;
            
            IF(IO_DEV_STATE_RETR.WORKING[i] > 0) THEN
                IO_DEV_STATE[i] := FALSE; //OK
            ELSE
                IO_DEV_STATE[i] := TRUE; //ERROR
                PN_OK_TEMP := FALSE; 
            END_IF;       
            
        END_IF;
            
    END_FOR;    
    
    HAS_IO_DEV := (IO_DEV_COUNT > 0);
    PN_OK := (HAS_IO_DEV AND PN_OK_TEMP);
    
    STEP := 0; //reset
    
END_IF;    

TIMER_RETRIGGER (IN := (STEP = 0)
                ,PT := T#60s
                );
END_FUNCTION_BLOCK

Für Verbesserungsvorschläge bin ich dankbar.
  • Außerdem meckert der Compiler beim Datentyp am BUSY-Ausgang des SFC 51, warum? BUSY.BUSY1 und BUSY.BUSY2 sind doch BOOL.
  • Wie kann ich nun Baugruppen-granular diagnostizieren (wieder entsprechend 1 Bit/Baugruppe (FALSE = OK; TRUE = ERROR)) ?
 
Zuletzt bearbeitet:
Außerdem: Wie stellt man sicher, dass die Zuordnung Statusbit <-> TN gleichbleibt, sonst müsste man die WinCC-Schnittstelle ständig nachziehen !?
 
Zurück
Oben