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

Ergebnis 1 bis 10 von 10

Thema: Lebensmeldung von der CPU

  1. #1
    Registriert seit
    08.07.2004
    Beiträge
    503
    Danke
    11
    Erhielt 4 Danke für 3 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Programmierfreunde,
    eine Frage.
    Ich soll über einen DP/DP Koppler an eine andere Maschine ein Toggle-Bit übergeben.
    Das soll etwa ein Lebenszeichen meiner CPU sein dass alles OK ist

    Wie könnte man das realisieren, gibt es da ein SFC, SFB oder eine andere Möglichkeit zu testen ob sich die CPU im Run-Betrieb befindet.

    Danke im Vorraus für Infos
    Gruß
    Zitieren Zitieren Lebensmeldung von der CPU  

  2. #2
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.752
    Danke
    323
    Erhielt 1.526 Danke für 1.286 Beiträge

    Standard

    Die leichtest Möglichkeit ist einfach ein Taktmerker.

    Alles weitere: http://www.sps-forum.de/search.php Suche nach Lebensbit.

    Mfg
    Manuel
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  3. #3
    Registriert seit
    08.08.2007
    Ort
    Dresden
    Beiträge
    9.648
    Danke
    1.059
    Erhielt 2.046 Danke für 1.627 Beiträge

    Standard

    Zitat Zitat von MSB Beitrag anzeigen
    Alles weitere: http://www.sps-forum.de/search.php Suche nach Lebensbit.
    ...oder nach watchdog

    Wie Watchdog richtig lösen
    Watchdog
    [SIGNATUR]
    Ironie setzt Intelligenz beim Empfänger voraus.
    [/SIGNATUR]

  4. #4
    Registriert seit
    30.03.2005
    Beiträge
    2.096
    Danke
    0
    Erhielt 673 Danke für 541 Beiträge

    Standard

    Überwachung eines Lebensbits mit zwei Einschaltverzögerungen:

    http://www.sps-forum.de/showpost.php...69&postcount=6

    http://www.sps-forum.de/showthread.php?t=17416

    Gruß Kai

  5. #5
    Registriert seit
    31.10.2003
    Beiträge
    265
    Danke
    23
    Erhielt 37 Danke für 31 Beiträge

    Standard

    Hallo,
    der DP-Koppler bietet selbst schon die Möglichkeit der Diagnose des gegenüberliegenden Netzes.
    Schau mal im Handbuch des DP-Kopplers ab Seite 50, Kapitel 6.2 Diagnose durch Anwenderprogramm
    https://a248.e.akamai.net/cache.auto...HB/dpdpk_d.pdf

    Gruß Andre
    Geändert von andre (06.02.2008 um 17:05 Uhr)

  6. #6
    Registriert seit
    20.06.2003
    Ort
    Sauerland.NRW.Deutschland
    Beiträge
    4.862
    Danke
    78
    Erhielt 805 Danke für 548 Beiträge

    Standard

    also ich mach das auch über den taktmerker.
    das ist einfach simpel und schnell geproggt.

    z.b.

    cpu1
    Code:
    u m 5.3 //taktmerker
    = a 100.0 //geht auf e100.0 der cpu2
    cpu2
    Code:
    u e 100.0 //=a100.0 der cpu1
    = a 100.0 //geht auf e100.0 der cpu1
    auswerten
    Code:
    un e 100.0
    l s5t#500ms //zeit ist natürlich abhängig vom taktmerker
    se t100
    u t100
    = m100.0 //störung lebensbit
    .
    mfg Volker .......... .. alles wird gut ..

    =>Meine Homepage .. direkt zum Download

    Meine Definition von TIA: Total Inakzeptable Applikation

  7. #7
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Böse

    Zitat Zitat von volker Beitrag anzeigen
    also ich mach das auch über den taktmerker.
    das ist einfach simpel und schnell geproggt.
    Ich würde das aus Mißtrauen mit einem Merker oder Ausgang machen, den ich in jedem OB1-Zyklus invertiere.
    Code:
    UN A 100.0
    = A 100.0 //geht auf e100.0 der cpu2
    Die Taktmerker werden ja von der Firmware verwaltet. Ist dokumentiert, daß sie im STOP nicht weiterlaufen? Ist man sciher, daß das für jede CPU, Firmware und Update gilt? So ist es sicher und kostet weniger Zeit als die Doku zu lesen...

    Ich würde in CPU2 auswerten, daß das Lebenszeichen von CPU1 kommt UND UMGEKEHRT.
    Nicht so:
    Zitat Zitat von volker Beitrag anzeigen
    Code:
    un e 100.0
    l s5t#500ms //zeit ist natürlich abhängig vom taktmerker
    se t100
    u t100
    = m100.0 //störung lebensbit
    weil ein ewig gesetzter e100.0 hier als gut erkannt würde, sondern so:
    Code:
    U E 100.0
    U M 100.0
    O(
    UN E 100.0
    UN M100.0
    )   // Diese Bedingung ist bei jeder positiven und jeder negativen Flanke unwahr. 
    L S5t#500ms //zeit ist natürlich abhängig vom taktmerker
    SE T100
    U T100
    = M100.1 //störung lebensbit
    
    U E 100.0
    U M 100.0 // für Flankenauswertung
    Dadurch wird garantiert, daß das Lebensbit WECHSELN muß. Das mache ich auch so, wenn ich andere periodische Vorgänge (z.B. Drehzahlüberwachung per Ini) überwachen muß.

  8. #8
    Registriert seit
    20.06.2003
    Ort
    Sauerland.NRW.Deutschland
    Beiträge
    4.862
    Danke
    78
    Erhielt 805 Danke für 548 Beiträge

    Standard

    hähhh ???
    einen getrunken ?

    selbst wenn der taktmerker (was ich jedoch ausschliesse) weiterlaufen würde, wäre der ausgang 0.
    und wieso sollte der e100.0 1 signal behalten? entweder das pae wird gelesen, dann läuft die cpu oder sie ist im stop. dann geht sowieso nix mehr und auswerten bei gestoppter cpu ist nich.
    .
    mfg Volker .......... .. alles wird gut ..

    =>Meine Homepage .. direkt zum Download

    Meine Definition von TIA: Total Inakzeptable Applikation

  9. #9
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Zitat Zitat von volker Beitrag anzeigen
    selbst wenn der taktmerker (was ich jedoch ausschliesse) weiterlaufen würde, wäre der ausgang 0.
    Zunächst einmal kenne ich es so, daß man bei manchen/vielen/allen DP-Slaves wählen kann, ob bei Busausfall die letzten Daten gehalten werden oder 0 ausgegeben wird. Zum DP-Koppler meint:
    http://support.automation.siemens.co...ard&viewreg=WW
    Zitat Zitat von Siemens Support-Seite
    bei Ausfall einer Seite werden die Ausgänge der anderen Seite auf den letzten Wert gehalten
    Zitat Zitat von volker Beitrag anzeigen
    und wieso sollte der e100.0 1 signal behalten?
    1. Weil CPU2 auf diesem Eingang den gehaltenen Ausgang von CPU1 "sieht"
    2. Weil je nach Projektierung bei DP-Ausfall zwischen Koppler und CPU2 das PAE von CPU2 wiederum die letzten Werte halten könnte.
    Zitat Zitat von volker Beitrag anzeigen
    entweder das pae wird gelesen, dann läuft die cpu oder sie ist im stop. dann geht sowieso nix mehr und auswerten bei gestoppter cpu ist nich.
    Weil Auswertung im Stop nicht ist, wollte ich ja CPU1 das Lebenszeichen von 2 und 2 das von 1 auswerten lassen.

    Zuletzt ist die Methode mit dem Wechselnden Bit und PRÜFUNG AUF WECHSEL sehr allgemein anwendbar und robust:
    1. Jemand benutzt nicht PAA/PAE für den DP-Koppler, sondern schreibt diesen mit SFC15. Der letzte Schreibzugriff setzt das Bit. Danach Stop. Der Eingang der anderen CPU bliebe 1.
    2. Jemand benutzt statt des DP/DP-Kopplers GET über MPI,Ethernet etc-Verbindung. In diesem Fall holt sich die laufende CPU einfach die Daten aus dem Speicher der anderen, egal ob diese läuft. Es kann eine Dauer "1" gelesen werden. Hier kann es auch interessant werden, ob Taktmerker im Stop weiterlaufen.
    3. Jemand benutzt eine Verbindung über Drähte. In diesem Fall kann einer nach 24V kurzgeschlossen sein.

  10. #10
    Registriert seit
    24.05.2006
    Beiträge
    234
    Danke
    14
    Erhielt 77 Danke für 57 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Das Problem ist nur, lieber Zottel, dass die letzte Zeile deines Codes einen Fehler enthält:

    eben NICHT
    Code:
    U E 100.0
    U M 100.0 // für Flankenauswertung
    sondern

    Code:
    U E 100.0
    = M 100.0 // für Flankenauswertung

  11. Folgender Benutzer sagt Danke zu hovonlo für den nützlichen Beitrag:

    Zottel (07.02.2008)

Lesezeichen

Berechtigungen

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