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

Seite 1 von 5 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 47

Thema: OB35, s7-CPU314: Einstellung 10ms funzt nicht, 50ms geht sehr gut

  1. #1
    Registriert seit
    02.11.2006
    Beiträge
    496
    Danke
    217
    Erhielt 25 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Liebe Gemeinde,

    anlehnend an das von mir beschriebene Problem http://www.sps-forum.de/showthread.php?t=22786

    (die CPU- Einstellungen in der HW-Konfig.... das hat super funktioniert >>)
    Danke an vierlagig

    habe ich noch folgende Fragen:

    - Ich habe das Progi noch einmal 'umgefrickelt'....
    NEU: => Meine DB- Aufrufe wollte ich im 10ms- Bereich über den OB35 realisieren. (dafür benötige ich keine IDB's mehr... das Progi wird einfacher lesbar).
    Bsp.:
    Code:
    // Referenzzähler setzen KD1 
    U E 3.5 // und KD "Ini oben" (Zähler Reset)
    R M 20.3 // wenn Ini_oben, dann Software-Endschalter rücksetzen
     
    U A 15.0 // SR-Merker "KD ab"
    U E 3.5 // und KD "Ini oben" (Zähler Reset)
     
    SPBN ZS_1 // Z-ähler S-etzen 1
    L 0 // Referenzzähler Reset
    T DB 1.DBW8 // Zähler schreiben
    SPA RzE1 // und Sprung zu R-echne z-ähl En-de1
     
    ZS_1: U A 15.0 // SR-Merker "KD ab"
    UN E 3.5 // und NICHT "Ini oben" (Zähler Reset)
    SPBN RzE1
     
    L DB 1.DBW8 // Lade Zähler
    L DB 1.DBW26 // obere Zählergrenze laden, um Zählerüberlauf zu vermeiden
    >=I
    = M 20.3 // Endschalter setzen, max. Ende ist erreicht
    U M 20.3
    SPB RzE1 // wenn Zähler >= Zähler_Max., dann nix mehr inkrementieren 
     
    L DB 1.DBW8 // Lade Zähler
    L 1 // inkrementieren
    +I 
    T DB 1.DBW8 // Referenzzähler schreiben
     
    // Zähler lernen 
    U E 2.6 // Bedingungen für Start "Ref_Zähler übernehmen"
    U E 2.0
    UN E 3.5
    UN M 20.3
    SPBN RzE1
    L DB 1.DBW8 // Ref_Zähler laden
    T DB 1.DBW0 // Rückgabewert schreiben
    SRW 1 // WORD nach rechts schieben => Division / 2
    T DB 1.DBW18 // und Ergebnis schreiben
     
    RzE1: NOP 0
    Das steht in 4 NW's für 4 KD's in OB35 => und fertig !

    Die min. Zykluszeit war lt. Diagnose: 5 ms
    Die max. Zykluszeit war lt. Diagnose: 23 ms
    Die mittlere Zykluszeit war lt. Diagnose: 9 ms ???
    (Mittelwert lt. meiner Rechnung: 14ms)

    Ich dachte, der OB35 würde unabhängig der Zykluszeit aufgerufen.
    (vergleichbar mit Interupt- Routinen, wie ich sie von Assembler kenne)

    Das Ergebnis nach dem Aufruf von OB35 mit 10ms: (ich verstehe es einfach nur noch nicht)
    Das Progi funzte mal 1h... 2h... mal nur 30sec lang.... Irgendwann
    war die CPU gestoppt.

    Seitdem ich den Weckalarm (OB35) auf 50ms eingestellt habe(Zwischenlösungen habe ich nicht getestet !), läuft die Sache stabil.

    Meine Fragen:
    - Hat die Zykluszeit doch etwas mit den WeckAlarm- OB's zu tun ?( vor allem die Zeit des OB- Aufrufs mit dem 'normalen' Progi- Ablauf )
    - Muß man die Zykluszeit beachten?
    Wenn JA... Was ist für eine sichere Funktion des Progis die richtige Einstellung für den OB35 ?

    Mfg
    Geändert von mega_ohm (19.10.2008 um 02:53 Uhr)
    Zitieren Zitieren OB35, s7-CPU314: Einstellung 10ms funzt nicht, 50ms geht sehr gut  

  2. #2
    Registriert seit
    27.10.2005
    Ort
    Schwäbisch Gmünd
    Beiträge
    5.224
    Danke
    630
    Erhielt 955 Danke für 769 Beiträge

    Standard

    Die mittlere Zykluszeit ist nicht der Mittelwert aus minimaler und maximaler Zykluszeit sondern eher der Ducrhschnitt aller Zyklsuzeiten (wie dies Siemens in der SPS berechnet, weiss ich nicht).
    Was ist die genaue Stopursache? Was steht im Diagnosepuffer? Was in den Stacks?
    Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist und durch den mehrfachen Aufruf des OB35 imnnerhalb eines Zykluses dann zuschlägt? Steht aber dann im Diagnosepuffer.
    Rainer Hönle
    DELTA LOGIC GmbH

    Ein Computer kann das menschliche Gehirn nicht ersetzen. Engstirnigkeit kann unmöglich simuliert werden. (Gerd W. Heyse)

  3. Folgender Benutzer sagt Danke zu Rainer Hönle für den nützlichen Beitrag:

    mega_ohm (20.10.2008)

  4. #3
    Registriert seit
    04.02.2007
    Beiträge
    2.544
    Danke
    167
    Erhielt 731 Danke für 528 Beiträge

    Standard

    Schon mal unabhängig welcher Fehler enststanden ist (Diagnosepuffer), bekommst Du ein Problem, weil dein OB eventuell zweimal aufgerufen wird in einem OB1 Zyklus. Dadurch greift du aber zweimal auf das gleiche Prozessabbild zu, welches sich natürlich nicht geändert hat.

    Wenn Du wirklich so eine kurze Rate haben willst, solltest Du im Code das Prozessabbild aktualisieren.

    Code:
    L PEW 2 // aktualisieren Eingänge
    T EW2
    ....
    L AW  14 // Zählerausgang
    T PAW 14

  5. #4
    Registriert seit
    17.10.2008
    Ort
    Neubrandenburg
    Beiträge
    21
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Hallo,

    bin nicht sicher ob es so sein kann aber:
    Was passiert wenn die Laufzeit des OB 35 selbst mehr als 10sec in Anspruch nimmt - vielleicht immer dann wenn umfangreichere Aktionen/ Berechnunge notwendig werden oder viele Werte in die DB's geschrieben werden.
    Hierfür würde sprechen das das Problem sporadisch auftritt.
    Die Abarbeitung müsste dann innerhalb des OB 35- Durchlauf unterbrochen werden um Ihn neu zu starten - das wird nicht gehen !!!

    Gruß MMM
    Zitieren Zitieren Laufzeit des OB 35  

  6. #5
    Registriert seit
    28.09.2005
    Beiträge
    428
    Danke
    118
    Erhielt 91 Danke für 76 Beiträge

    Standard

    Hi,
    aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:
    Code:
    Hinweis
    Sie müssen dafür sorgen, dass die Laufzeit jedes Weckalarm-OB deutlich
    kleiner ist als sein Zeittakt. Falls ein Weckalarm-OB noch nicht beendet ist,
    aber wegen des abgelaufenen Zeittakts erneut zur Bearbeitung ansteht,
    wird der Zeitfehler-OB (OB 80) gestartet. Anschließend wird der Fehler
    verursachende Weckalarm nachgeholt.

  7. Folgender Benutzer sagt Danke zu mst für den nützlichen Beitrag:

    mega_ohm (20.10.2008)

  8. #6
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.728
    Danke
    398
    Erhielt 2.406 Danke für 2.002 Beiträge

    Standard

    Hallo,
    um dein Programm "sauber" zu bekommen würde ich auf jeden Fall jeden der gemachten Vorschläge beachten. In der Reihenfolge :
    Vorschlag Jabba, Vorschlag Matthias / MST.

    Das gezeigte Netzwerk (auch wenn es 4mal da ist) sollte eigentlich nicht einen zweiten Einsprung in den OB35 ermöglichen (geschätzt) während der erste noch läuft (so was Schlimmes ist da nun auch nicht drin programmiert).

    Wie schon von Rainer beschrieben wird der OB35 vollkommen unabhängig vom OB1-Zyklus ausgerufen - bei der Berechnung der Gesamt-Zykluszeit des Programms schlägt er natürlich mit zu Buche.

    Aber eine andere Frage:
    Muß das gezeigt Programmteil überhaupt im Zeit-OB laufen ? Reicht es nicht aus, wenn du es im OB1 (oder in einem von dort gestarteten FC) hinterlegt hast ?

    Ach ja:
    Zu deiner letzten Frage (alle anderen sind m.E. schon beantwortet) :
    Das richtige Intervall für den OB35 legst du mit deiner Anwendung fest. Beispiel :
    Ich nutze den OB35 um Messwerte für eine Kurve aufzuzeichnen. Hier möchte ich z.B. alle 5ms einen neuen Messwert speichern. Das ist dann meine Anwendung und somit das von mir benötigte Intervall ...

    Gruß
    LL

  9. Folgende 2 Benutzer sagen Danke zu Larry Laffer für den nützlichen Beitrag:

    mega_ohm (20.10.2008),SIGGI (10.03.2009)

  10. #7
    mega_ohm ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    02.11.2006
    Beiträge
    496
    Danke
    217
    Erhielt 25 Danke für 6 Beiträge

    Standard

    Zitat Zitat von Rainer Hönle Beitrag anzeigen
    Die mittlere Zykluszeit ist nicht der Mittelwert aus minimaler und maximaler Zykluszeit sondern eher der Ducrhschnitt aller Zyklsuzeiten (wie dies Siemens in der SPS berechnet, weiss ich nicht).
    Rein rechnerisch ist die "mittlere Zykluszeit" nicht nachvollziehbar.
    Zumindest nicht mit einer 'normalen' Durchschnitts- Berechnung
    Was ist die genaue Stopursache? Was steht im Diagnosepuffer? Was in den Stacks?
    Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist
    und durch den mehrfachen Aufruf des OB35 imnnerhalb eines Zykluses dann zuschlägt? Steht aber dann im Diagnosepuffer.
    Das kann ich alles erst heute ab 14.00 Uhr herausfinden (wenn ich neben der Großreparatur an dieser Anlage noch Zeit dafür habe).
    Ich hatte am "lebenden Objekt mit offener Wunde" gearbeitet. Danach kamen noch 2 andere "Baustellen" und dann der Feierabend.
    Auf Grund dessen, das die Anlage am Mo und Di noch (wg. Reparatur) steht, habe ich mich mit der Diagnose dann nicht mehr beschäftigt... das muß ich nachholen.

    Kann es sein, dass die Zykluszeitüberwachung sehr knapp eingestellt ist...
    Finde ich die Einstellungen für die Zykluszeit- Überwachung auch in der HW- Konfig ?

    Bis spätestens Ende dieser Woche werde ich die Fragen beantworten können.

    mfg

  11. #8
    mega_ohm ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    02.11.2006
    Beiträge
    496
    Danke
    217
    Erhielt 25 Danke für 6 Beiträge

    Standard

    Zitat Zitat von jabba Beitrag anzeigen
    Schon mal unabhängig welcher Fehler enststanden ist (Diagnosepuffer), bekommst Du ein Problem, weil dein OB eventuell zweimal aufgerufen wird in einem OB1 Zyklus.
    Wieso wird der OB35 eventl. 2x aufgerufen ?
    Ich war bisher, nach vielen Suchen und Recherchen, der Meinung, daß der OB35 unabhängig von der Zykluszeit zeitgesteuert (CPU- Takt / Taktteiler) ist ?
    Ist mein Verständnis für diese Sache falsch ? Dann bitte ich um Links...
    mehr Input.
    Wenn Du wirklich so eine kurze Rate haben willst, solltest Du im Code das Prozessabbild aktualisieren.
    Theoretisch würde für diese Aufgabe ein Takt= 50ms auch ausreichen.
    Praktisch ist es natürlich so, daß umso mehr Zähldurchgänge (10ms statt 50ms) durchlaufen werden, umso genauer positioniert werden kann.

    Ich habe (mit 50ms) bei 30 Arbeitszyklen eine Fehlerqoute von 3mm gemessen. Das ist eigentlich für diese Sache mehr als ausreichend, zumal dieser Fehler auch noch durch hydraulische (es wird ein Hydraulikventil gesteuert) Probleme (Konsistenz bei Temp.-Änderungen) verursacht werden könnte.

    Aber unabhängig von diesem jetzigen Problem steht ja für mich das Verständnis um den Aufruf dieses OB35. Beim Suchen im www oder auch hier im Forum findet man viel VIEL zu diesem Thema, aber nix Konkretes.

    ______________________________________________________________
    Code:
    L PEW 2 // aktualisieren Eingänge
    T EW2
    ....
    L AW 14 // Zählerausgang
    T PAW 14
    Für dig. Eingänge lädst Du ein PEW ?
    Ich dachte bisher.... (PEW,PAW =analog )
    Ich setze mich morgen nochmal auf die "Schulbank"

    Mfg

  12. #9
    mega_ohm ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    02.11.2006
    Beiträge
    496
    Danke
    217
    Erhielt 25 Danke für 6 Beiträge

    Standard

    Zitat Zitat von Matthias_aus_AT Beitrag anzeigen
    Hallo,

    bin nicht sicher ob es so sein kann aber:
    Was passiert wenn die Laufzeit des OB 35 selbst mehr als 10sec in Anspruch nimmt - vielleicht immer dann wenn umfangreichere Aktionen/ Berechnunge notwendig werden oder viele Werte in die DB's geschrieben werden.
    Hierfür würde sprechen das das Problem sporadisch auftritt.
    Die Abarbeitung müsste dann innerhalb des OB 35- Durchlauf unterbrochen werden um Ihn neu zu starten - das wird nicht gehen !!!

    Gruß MMM
    Diese Idee hatte ich auch. Deshalb habe ich die Aufrufzeit auf 50ms erhöht.

  13. #10
    mega_ohm ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    02.11.2006
    Beiträge
    496
    Danke
    217
    Erhielt 25 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von mst Beitrag anzeigen
    Hi,
    aus der S7 Hilfe für Weckalarm-OB´s OB30 - OB38:
    Code:
    Hinweis
    Sie müssen dafür sorgen, dass die Laufzeit jedes Weckalarm-OB deutlich
    kleiner ist als sein Zeittakt. Falls ein Weckalarm-OB noch nicht beendet ist,
    aber wegen des abgelaufenen Zeittakts erneut zur Bearbeitung ansteht,
    wird der Zeitfehler-OB (OB 80) gestartet. Anschließend wird der Fehler
    verursachende Weckalarm nachgeholt.
    Ich glaube, daß diese Aussage für mich einkomplettes Umdenken bedeutet.

    In Assembler sichert man die Register, manipuliert danach, ruft einen Interrupt auf und schreibt die gesicherten Register danach zurück.
    Ich war bisher der Meinung, daß der Aufruf eines zeitgesteuerten OB's mir alle anderen Sorgen (Sichern, Zurückschreiben) abnehmen würde.
    Das scheint wohl ein Irrtum zu sein.

    Wie finde ich denn heraus, wie groß der benötigte Zeittakt für den Weckalarm ist ?
    Steht das dann im OB80 ?
    Und um das Ganze noch weiter auszudehnen...
    Reicht es aus, den OB121 einfach nur aufzurufen ( mit nix drinnen ), um das leidige CPU-Stop zu maskieren ?

    mfg
    Geändert von mega_ohm (20.10.2008 um 00:46 Uhr)

Ähnliche Themen

  1. Funktionstastenbit funzt nicht richtig!
    Von Chris_the_new im Forum HMI
    Antworten: 0
    Letzter Beitrag: 11.08.2010, 11:46
  2. Skript in flexible runtime funzt nicht
    Von DJMetro im Forum HMI
    Antworten: 3
    Letzter Beitrag: 31.05.2010, 15:32
  3. Antworten: 10
    Letzter Beitrag: 20.05.2008, 13:09
  4. Antworten: 7
    Letzter Beitrag: 19.02.2008, 20:04
  5. 313C OB35 mit Regler FB funktioniert nicht
    Von Dragonfire im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 31.01.2006, 14:23

Lesezeichen

Berechtigungen

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