Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 5 von 8 ErsteErste ... 34567 ... LetzteLetzte
Ergebnis 41 bis 50 von 79

Thema: Profibus/Profinet-Teilnehmer Diagnose

  1. #41
    Registriert seit
    06.10.2003
    Beiträge
    3.413
    Danke
    451
    Erhielt 506 Danke für 408 Beiträge

    Standard


    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.
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  2. #42
    Matze001 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    11.12.2009
    Beiträge
    2.115
    Danke
    388
    Erhielt 390 Danke für 271 Beiträge

    Standard

    Ich habe "meinen" Baustein noch einmal angepasst und mit ein wenig Beschreibungstext versehen!

    Grüße

    Marcel

  3. #43
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.402 Danke für 2.001 Beiträge

    Standard

    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

  4. #44
    Registriert seit
    13.10.2007
    Beiträge
    12.038
    Danke
    2.789
    Erhielt 3.273 Danke für 2.159 Beiträge

    Standard

    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

  5. #45
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.402 Danke für 2.001 Beiträge

    Standard

    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

  6. #46
    Matze001 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    11.12.2009
    Beiträge
    2.115
    Danke
    388
    Erhielt 390 Danke für 271 Beiträge

    Standard

    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...
    Geändert von Matze001 (05.07.2012 um 08:45 Uhr)

  7. #47
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.727
    Danke
    398
    Erhielt 2.402 Danke für 2.001 Beiträge

    Standard

    Zitat Zitat von Matze001 Beitrag anzeigen
    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

  8. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    rostiger Nagel (05.07.2012)

  9. #48
    Registriert seit
    13.10.2007
    Beiträge
    12.038
    Danke
    2.789
    Erhielt 3.273 Danke für 2.159 Beiträge

    Standard

    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.

  10. #49
    Registriert seit
    13.10.2007
    Beiträge
    12.038
    Danke
    2.789
    Erhielt 3.273 Danke für 2.159 Beiträge

    Standard

    hier jetzt mal mein Beispiel (noch im Endwurfs-Status)
    Getriggert wird er zZ vom OB86 und OB30 (5000ms) und ist nur zur DP-Diagnose.

    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
    Geändert von rostiger Nagel (10.07.2012 um 13:12 Uhr)

  11. #50
    Matze001 ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    11.12.2009
    Beiträge
    2.115
    Danke
    388
    Erhielt 390 Danke für 271 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. ProfiNet/ProfiBus Diagnose einfach
    Von kliebisch.m im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 29.12.2011, 10:13
  2. Profinet Teilnehmer Diagnose
    Von GobotheHero im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 11.08.2010, 17:31
  3. Diagnose Profinet-Teilnehmer anhand der IP
    Von Hawkster im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 08.02.2010, 16:39
  4. Auswertung Profinet Teilnehmer
    Von Ensiferum im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 27.05.2009, 22:51
  5. Hilfe; ProfiNet/ profiBus- Diagnose....
    Von Cliff im Forum Feldbusse
    Antworten: 12
    Letzter Beitrag: 19.02.2009, 18:53

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •