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

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 22

Thema: Zykluskontrollpunikt 1200 & 1500er Serie

  1. #11
    Registriert seit
    18.02.2009
    Ort
    NRW
    Beiträge
    45
    Danke
    1
    Erhielt 12 Danke für 6 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Mediator Beitrag anzeigen
    Man könnte das OB1 - Programm ja in einem Weckalarm mit Priorität > 15 laufen lassen und die IOs an diesen OB binden.
    Klar dass eine lange Programmlaufzeit dann zu einem schlechteren Kommunikationsverhalten führt.
    Auf jeden Fall kann man das jetzt schon so ausprobieren.
    klar, würde gehen als "Notfall-Workaround".
    wäre dann HF-Technik (Hauptsache Funktioniert)

    aber nicht gerade schöner und in sich nachvollziehbarer Stil.

    Wir möchten ja eine möglichst einfach zu implementierende, aber allgemeingültig anpassbare Lösung gerne in den Firmwares finden.

    zum Thema Prioritäten Link auf leseprobe bei Google:
    https://books.google.de/books?id=Xkq...201500&f=false
    Die Wahrheit ist ein Chor aus Wind

  2. #12
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.345
    Danke
    451
    Erhielt 691 Danke für 516 Beiträge

    Standard

    Das mit der Priorität 16 hat wieder den Nachteil dass man nicht vergessen darf die anderen OBs nach zu stellen. OB35 hat z.B. nur Priorität 12.
    Jetzt wo ich es schreibe, eigentlich lustig dass OB35, den alle möglichst stabil für die Regelaufrufe haben wollen, auch per Standardeinstellung von der HMI unterbrochen wird...

    Im Prinzip hatte man bei der 300er die Wahl zwischen Halsweh und Bronchitis.
    Das Eine macht die HMI-Kommunikation langsamer, das andere führt eventuell zu Programmfehlern, mehr Arbeit und macht eventuell die CPU (weil mehr Operationen um es zu verhindern) langsamer.
    Am wichtigsten ist aber dass es die erste Variante dem Programmiere eher erleichtert, während die Andere erschwerend wirkt.

    Damit man nicht nur zu dieser Auswahl gezwungen wird, sondern damit es wirklich ein Fortschritt gegenüber der 300 werden würde, wäre eher so eine Lösung wie ich in meinem Eingangspost angedacht hatte nötig.
    Im Moment haben wir aber bei der 1200/1500 einen Rückschritt im Vergleich zur 300.
    Geändert von RONIN (24.05.2016 um 14:56 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  3. #13
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.618
    Danke
    776
    Erhielt 646 Danke für 492 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    Damit man nicht nur zu dieser Auswahl gezwungen wird, sondern damit es wirklich ein Fortschritt gegenüber der 300 werden würde, wäre eher so eine Lösung wie ich in meinem Eingangspost angedacht hatte nötig.
    Im Moment haben wir aber bei der 1200/1500 einen Rückschritt im Vergleich zur 300.
    Ich weiss jetzt nicht, ob man das wirklich als Rückschritt bezeichnen kann. Es ist halt anders als bei der 300er serie. Aber halt so wie bei der 400er und 318er. Ich hab eigentlich aufgehört solche Programme zu schreiben wo HMI und CPU Daten gleichzeitig beeinflussen können seit ich auch für 400er Software schreibe. Bei Codesys WAGO hatte ich übrigens dasselbe Verhalten im Zusammenspiel mit PVSS II.
    Es macht also durchaus Sinn sich dessen bewusst zu sein.

    mfG René

  4. #14
    Registriert seit
    18.02.2009
    Ort
    NRW
    Beiträge
    45
    Danke
    1
    Erhielt 12 Danke für 6 Beiträge

    Standard

    bewusst bin ich mir dessen.

    nur suche ich noch nach ner vernünftigen Umsetzung für meine Problematik

    gefordert:
    - Lokalbedienung am Panel
    - Wenn Modus Remote, Sollwerte kommen von Leitwarte, Panelwerte werden ausgegraut und nicht bedienbar) Werte am Panel werden mit den Werten der Leitwarte aktualisiert
    - es muss eine Konsistensprüfung durchgeführt werden.
    (Begrenzung z.b. auf maximale Maschinendrehzahlen, minimale und maximale technologische Zeiten)

    vorhanden:
    UDT.Rezept (Struct mit dem Datenblock für die auszutauschenden Werte)

    DB.VISU für Visualisierung (UDT.P)
    DB.LEITWARTE_SW für Leitwarte Sollwerte (UDT.P)
    DB.LEITWARTE_IW für Leitwarte Istwerte (UDT.P)
    DB.PRODUKTION für die Produktionswerte (UDT.P)

    es läuft nu schematisch so ab.

    // Werte aus dem Visu DB in den ProduktionsIntern DB umkopieren
    RETVAL:= BLKMOV (SRCBLK := Visu.Rezept, DSTBLK := Produktion.Rezept);

    // Werte aus dem Leitwarten DB in den ProduktionsIntern DB kopieren, wenn die Werte auf Leitwarte konfigutiert sind
    IF "DB.Config".Event.SWvonLeitWarte THEN
    IF Prozesswert1 THEN Produktion.Rezept.Wert1:= Leitwarte_SW.Rezept.Wert1; END_IF;
    usw.....
    END_IF;

    // Die Produktionswerte werden nun auf Konsistenz gecheckt
    FC.KONSISTENZ (PRODUKTION.REZEPT);

    // Ab hier sind die Produktionswerte aktuell und konsistent
    xxxxxxx Programm halt

    // Bei Leitwerte die Produktionswerte in Leitwarten IW Schrieben
    IF "DB.Config".Event.SWvonLeitWarte THEN
    RETVAL:= BLKMOV (SRCBLK := Produktion.Rezept, DSTBLK := Leitwarte_IW.Rezept);
    END_IF;

    // Produktionswerte in Visu zurückschreiben
    RETVAL:= BLKMOV (SRCBLK := Produktion.Rezept, DSTBLK := VISU.Rezept);

    Und damit hänge ich beim Zeitscheiben Verfahren ziemlich am Fliegenfänger

    greetz, Black
    Die Wahrheit ist ein Chor aus Wind

  5. #15
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard

    Zitat Zitat von Blackmike Beitrag anzeigen
    klar, würde gehen als "Notfall-Workaround".
    wäre dann HF-Technik (Hauptsache Funktioniert)

    aber nicht gerade schöner und in sich nachvollziehbarer Stil.
    Ich finde meinen Vorschlag auch nicht schön. Die Idee mit den Prioritäten kam ja von Dir. Ich wollte nur erwähnen, dass man schon jetzt nicht an die festen Prioritäten gebunden ist
    Auch den Modus "ZKP" finde ich nicht wirklich schön, weil er Risiken mit sich bringt. Wenn man erkennt, dass man doch den anderen Modus braucht, hat man wahrscheinlich ein Problem.
    Ich sehe es so wie Vollmi geschrieben hat, sich auf die HMI - Zugriffe einstellen

  6. #16
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard

    Zitat Zitat von Blackmike Beitrag anzeigen
    // Werte aus dem Visu DB in den ProduktionsIntern DB umkopieren
    RETVAL:= BLKMOV (SRCBLK := Visu.Rezept, DSTBLK := Produktion.Rezept);
    .....
    // Produktionswerte in Visu zurückschreiben
    RETVAL:= BLKMOV (SRCBLK := Produktion.Rezept, DSTBLK := VISU.Rezept);
    Wenn ich richtig verstehe, dann könnte es bei diesen beiden BLKMOV zu Inkonsistenzen kommen. Kopierst Du mit UBLKMOVstatt BLKMOV, dann ist das Kopieren ununterbrechbar und damit konsistent.

  7. #17
    Registriert seit
    18.02.2009
    Ort
    NRW
    Beiträge
    45
    Danke
    1
    Erhielt 12 Danke für 6 Beiträge

    Standard

    bei den BLKMOV´s ist es theoretisch möglich, kritisch ist die Programmlaufzeit zwischen

    //Werte aus dem Visu DB in den ProduktionsIntern DB umkopieren
    (Zeit für Leitwarte koperen und Konsistenzprüfung)
    //Produktionswerte in Visu zurückschreiben

    kommt es in dem Teil " (Zeit für Leitwarte koperen und Konsistenzprüfung)" zu einer Zeitscheibenunterbrechung und Datenübertragung durchs HMI in den VISU DB, werden diese Daten später im Teil "//Produktionswerte in Visu zurückschreiben" überschrieben und sind damit weg.

    ich kenne auch den Lösungsansatz, dr unter dem Beitrag hier Zykluskontrollpunkt S7-1200 und S7-1500 mit HMI beschrieben wurde

    Beitrag von PN/DP:
    Code:
    FUNCTION Check_HMI_Var_Int : BOOL
    VAR_INPUT
        HMI_Var : INT ;                  //zu prüfende Variable vom HMI
        Maxwert : INT ;
        Minwert : INT ;
    END_VAR
    VAR_OUTPUT
        PLC_Var : INT ;                  //Arbeitskopie in der PLC
        xKorrektur : BOOL ;              //True: HMI-Var muß korrigiert werden
    END_VAR
    VAR_TEMP
        Tmp_Var : INT ;
    END_VAR
    
        Tmp_Var := HMI_Var ;             //HMI_Var vorsichtshalber kopieren, falls Übergabe ByRef
    
        xKorrektur := True ;
        IF Tmp_Var > Maxwert THEN        //größer Maxwert?
            Tmp_Var := Maxwert ;         //auf Maxwert setzen
        ELSIF Tmp_Var < Minwert THEN     //kleiner Minwert?
            Tmp_Var := Minwert ;         //auf Minwert setzen
        ELSE
            xKorrektur := False ;
        END_IF;
        
        PLC_Var := Tmp_Var ;             //die geprüfte und ggf. korrigierte Arbeitskopie
        Check_HMI_Var_Int := xKorrektur ;
    
    END_FUNCTION



    und dem Aufruf:
    Code:
    // Check HMI_Var_1
        Check_HMI_Var_Int(
                 HMI_Var := HMI_Var_1    //hier der einzige Lesezugriff auf die HMI_Variable
                ,Maxwert := 100
                ,Minwert := 0
                ,PLC_Var => PLC_Var_1    //die Kopie, mit der das PLC-Programm arbeitet
             ,xKorrektur => Tmp_BOOL_Var
        );
     
        IF Tmp_BOOL_Var THEN
            HMI_Var_1 := PLC_Var_1 ;     //ggf. Korrektur auf HMI_Variable zurückschreiben
        END_IF;
    
    // oder:
    
    // Check HMI_Var_2
        IF Check_HMI_Var_Int(
                 HMI_Var := HMI_Var_2    //hier der einzige Lesezugriff auf die HMI_Variable
                ,Maxwert := 100
                ,Minwert := 0
                ,PLC_Var => PLC_Var_2    //die Kopie, mit der das PLC-Programm arbeitet
             ,xKorrektur => Tmp_BOOL_Var
        ) THEN
            HMI_Var_2 := PLC_Var_2 ;     //ggf. Korrektur auf HMI_Variable zurückschreiben
        END_IF;


    Aber bitte, es kann doch nicht Ziel in Zeiten von "modernen" Werkzeugen wie TIA sein, das ich nun jede der etwas über 100 Variablen, die ich so zwischen HMI und Leitwarte austausche durch derartige Funktionen jagen muss, nur um eine Konsistenz zu erhalten, wenn es mit anderen Mitteln der Priorisierung, Interruptsperren etc auch gehen würde.

    Geändert von Blackmike (25.05.2016 um 07:58 Uhr)
    Die Wahrheit ist ein Chor aus Wind

  8. #18
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard

    Zitat Zitat von Blackmike Beitrag anzeigen
    bei den BLKMOV´s ist es theoretisch möglich, kritisch ist die Programmlaufzeit zwischen

    //Werte aus dem Visu DB in den ProduktionsIntern DB umkopieren
    (Zeit für Leitwarte koperen und Konsistenzprüfung)
    //Produktionswerte in Visu zurückschreiben

    kommt es in dem Teil " (Zeit für Leitwarte koperen und Konsistenzprüfung)" zu einer Zeitscheibenunterbrechung und Datenübertragung durchs HMI in den VISU DB, werden diese Daten später im Teil "//Produktionswerte in Visu zurückschreiben" überschrieben und sind damit weg.
    Ich dachte zunächst, das Problem sei, dass die BLKMOVs von HMI-Zugriffen unterbrochen werden können.
    So wie ich es jetzt verstehe ist das Problem aber auch, dass die DB.Visu-Struktur sowohl vom Programm als auch vom HMI gelesen und geschrieben wird, korrekt?
    Das Problem kannst Du auflösen, indem Du mit getrennten Strukturen arbeitest:
    1. eine Struktur Visu.RezeptHMIVorgabe für Vorgaben vom HMI, die das Programm nur einmal liest und ununterbrechbar mit UBLKMOV in Produktion.Rezept umkopiert.
    2. eine Struktur Visu.RezeptHMIAnzeige für die Anzeige im HMI, die vom Programm nur einmal ununterbrechbar mit UBLKMOV geschrieben und vom HMI nur gelesen wird.

  9. #19
    Registriert seit
    18.02.2009
    Ort
    NRW
    Beiträge
    45
    Danke
    1
    Erhielt 12 Danke für 6 Beiträge

    Standard

    @Mediator
    das geht so aber nicht, der VisuDB muss bidirektional in beide Richtungen sein.
    WEIL:
    Wenn Vorwahl REMOTE kommen die Werte führend von der Leitwarte und werden dann damit auch von der SPS in den Visu DB Kopiert.
    Grund: vermeidung von Sollwert Sprüngen, wenn die Anlage von Remote in Local zurückgenommen wird bzw von Sollwertsprüngen bei Busausfall der Leitwarte.

    Ansonsten wäre dein Ansatz gut.

    Im übrigen ist morgen kleines Treffen, wo die Wünsche mal zusammengefasst vorgetragen werden.
    mal schauen, aber vor vielen jahren hat auch der Wunsch damals noch bei meinem alten Arbeitgeber, die 412er Slot CPU mit einem Hardwaremäßigen Run stop MRES Schalter auszustatten und nicht nur mit dem PC OCX zu steuern, nach einiger Zeit Früchte getragen.
    Von daher bin ich nicht völlig hoffungslos.

    Bis dahin, Black
    Die Wahrheit ist ein Chor aus Wind

  10. #20
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Wahrscheinlich verstehe ich die Datenflüsse noch nicht gut genug
    Die Leitwartenbehandlung hattest Du doch bisher auch schon dazwischen. Das kannst Du doch so lassen!?

    Ich hatte mir das so vorgestellt:

    1. eine Struktur Visu.RezeptHMIVorgabe für Vorgaben vom HMI, die das Programm nur einmal liest und ununterbrechbar mit UBLKMOV in Produktion.Rezept umkopiert.

    // Werte aus dem Leitwarten DB in den ProduktionsIntern DB kopieren, wenn die Werte auf Leitwarte konfigutiert sind
    IF "DB.Config".Event.SWvonLeitWarte THEN
    IF Prozesswert1 THEN Produktion.Rezept.Wert1:= Leitwarte_SW.Rezept.Wert1; END_IF;
    usw.....
    END_IF;

    // Die Produktionswerte werden nun auf Konsistenz gecheckt
    FC.KONSISTENZ (PRODUKTION.REZEPT);

    // Ab hier sind die Produktionswerte aktuell und konsistent
    xxxxxxx Programm halt

    // Bei Leitwerte die Produktionswerte in Leitwarten IW Schrieben
    IF "DB.Config".Event.SWvonLeitWarte THEN
    RETVAL:= BLKMOV (SRCBLK := Produktion.Rezept, DSTBLK := Leitwarte_IW.Rezept);
    END_IF;

    2. eine Struktur Visu.RezeptHMIAnzeige für die Anzeige im HMI, die vom Programm nur einmal ununterbrechbar mit UBLKMOV geschrieben und vom HMI nur gelesen wird.

Ähnliche Themen

  1. TCP FIN & RST mit 1500er CPU
    Von Jochen Kühner im Forum HMI
    Antworten: 1
    Letzter Beitrag: 01.03.2016, 08:16
  2. B&R schwarze Serie
    Von William700 im Forum Sonstige Steuerungen
    Antworten: 18
    Letzter Beitrag: 25.06.2015, 21:46
  3. TIA ET200M an 1500er Serie möglich
    Von pjoddi im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 29.05.2015, 11:45
  4. TIA 1500er Steuerung - DataLogCreate & DataLogWrite Funktion
    Von herrwernersens im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 24.02.2015, 16:02
  5. B&R schwarze Serie / blaue Serie
    Von weq im Forum Sonstige Steuerungen
    Antworten: 5
    Letzter Beitrag: 15.10.2008, 14:09

Lesezeichen

Berechtigungen

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