TIA Zykluskontrollpunikt 1200 & 1500er Serie

Blackmike

Level-1
Beiträge
45
Reaktionspunkte
12
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Problematik des Verhaltens der 1200 er und der 1500er ist bekannt.

In einen intensiveren Gespräch mit einigen entsprechenden Leuten von Siemens möchten wir über ein paar gute Kontakte zu der Abteilung, welche die Firmwares für die Steuerungen erstellt, folgenden Punkt beantragen / vordringlich wünschen.

- Möglichkeit über Anwahl in HW-Config das verhalten einstellen zu können zwischen

a- Zykluskontrollpunkt (wie bei den alten 300ern)
b- feste Zeitscheiben (wie bei 400ern, 1200 und 1500)

Es kann nicht das Hexenwerk sein, da sich bei modernen 300ern schon das verhalten in HW Konfig im Reiter Kommunikation einstellen lässt.
(dort dann Verhalten nicht Zykluskontrollpunkt sondern Zeitscheibenverhalten).

Das passende Schreiben wird jetzt zeitnah rausgehen, ich würde gerne auf diesen Thread hier dann referenzieren, da das Problem Zykluskontrollpunkt ja häufiger aufgetreten ist und nicht spezifisch in unseren Anlagen zu suchen ist.

greetz, Black
 
Vielen Dank dass Ihr euch bemüht, schaden kann sowas nie.
Laut meinem Vertreter ist zu dem Thema zwar was im Gange, weil Sie auch teilweise schon von größeren (wichtigeren) Firmen Gegenwind bekommen haben.
Aber genaues weiß man nicht.

Behandelt wurde das Thema in der Tat schon oft hier, da auch schon ein paar damit auf die Nase gefallen sind. Hier eine Auswahl...
http://www.sps-forum.de/simatic/75294-mit-udt-inout-und-multiinstanz.html
http://www.sps-forum.de/simatic/821...ndung-mit-absoluter-adressierung-zur-cpu.html
http://www.sps-forum.de/simatic/71057-zykluskontrollpunkt-s7-1200-und-s7-1500-mit-hmi-2.html
http://www.sps-forum.de/simatic/79662-umstieg-auf-s7-1500-a.html
http://www.sps-forum.de/simatic/68319-s7-1500-hmi-kommunikation-zykluskontrollpunkt.html

Du schreibst du möchtest auf diesen Beitrag referenzieren...
Was genau erwartest du dir von diesem Beitrag hier? Kommentare von uns zum Thema? Zustimmung das wir den Kontrollpunkt auch gerne wieder hätten?

Ich hätte den Kontrollpunkt sehr gerne wieder gesehen.
Ich könnte mir aber eine womöglich bessere Variante zu a) und b) vorstellen.

Ein Flag am Baustein welches das Unterbrechen durch die HMI-Kommunkation verhindert solange der Baustein gerade läuft.
Man hätte dann das beste aus beiden Welten. Man könnte dann gewisse Bausteine auskoppeln und immer noch eine "beschleunigte" HMI-Kommunikation erreichen wenn zB. die Aktualisierung beim Übergang von einem auf den nächsten FB passiert. Das wäre für den Programmierer auch recht leicht zu handeln.

Dürfte auch nicht sonderlich schwer sein, jetzt könnte ein FB der Priorität > 16 hat auch schon nicht von der HMI unterbrochen werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
yap, es gibt halt Anwendungsfälle, wo das reine nun implementierte Zeitscheibenverhalten zu unerwünschten Effekten bzw im noch schlimmeren Fall zu inkonsistentem Verhalten führt.

dies über Prioritätsstufen einstellbar zu machen wäre mit Sicherheit auch ein interessanter Ansatz.

Dazu würde ich schon reichen, wenn der OB1 (bzw bei den 1200, 1500 die MainOB´s nicht die feste Priorität 1 und die HMI Kommunikation nicht die feste 15 hätte)
Damit liesse sich gradual die Unterbrechbarkeit priorisieren.

Der von dir genannte Ansatz ist auf jedenfall mal sehr interessant und eigentlich auch ohne immense Aufwände implementierbar.

greetz, Black
 
Der wesentliche Grund ist doch, das neue Prinzip der Aktualisierung wiederspricht den
was Siemens mit TIA Propagiert, nämlich das alles schneller und übersichtlicher wird als
in der Classic Welt.
In TIA wird die Kommunikation zur HMI unübersichtlicher und aufgeblähter, damit man eine
Daten Konsistenz hinbekommt. Alleine das sollte schon zur Argumentation reichen.
 
Da hat RN einen Punkt
Gerade der Neu-Einsteiger der ein paar UND/ODER zusammensteckt wundert sich dann wenn seine Anlage bei HMI-Wertänderung plötzlich Schluckauf bekommt.
Dort werden öfters mal unwahrscheinlich spannende Logik-Konstrukte zusammengeschustert die keine Wertänderung in der Mitte vertragen... :ROFLMAO:
 
Zuletzt bearbeitet:
Nunja ich bin sicher nicht der einzige der sich prioritätsebenen schon auf der 400er gewünscht hätte.
Aber auch da hat Siemens ja nix dergleichen gemacht. Da wärs ja auch nicht so ein grosser Aufwand gewesen.

Ich wünschte mir das natürlich für alles. Nicht nur für HMI sondern auch für AG-Link z.B. bein WinCC OA

mfG René
 
Könnt ihr mir kurz schreiben, was der Zykluskontrollpunkt ist bzw. bewirkt. Ich konnte keine Infos dazu finden
Bei den 300er-Steuerungen gab es einen definierten Zeitpunkt wann die HMI-Werte auf der SPS verändern könnte. Dieser lag außerhalb des OB1-Zyklus.
Bei den 400er/1200er/1500er-Steuerung gehlt dieser, heißt dass dir die HMI mitten im OB1-Zyklus, an einem mehr oder weniger zufälligen Punkt, Werte umschreibt.

Dies kann je nach Programmierung zu Fehlern führen...
Siehe... http://www.sps-forum.de/simatic/821...ndung-mit-absoluter-adressierung-zur-cpu.html
Solche Fehler zu verhindern ist oft mit zusätzlichem Programmieraufwand verbunden.

Kurz gesagt vereinfacht der Zyklus-Kontrollpunkt die SPS-Programmierung weil sich der Programmierer nicht Gedanken um die Daten-Synchronisation mit der HMI machen muss.
Lies dir einfach die verlinkten Themen durch, dort ist die Thematik teilweise lang und breit erklärt.

Ich wünschte mir das natürlich für alles. Nicht nur für HMI sondern auch für AG-Link z.B. bein WinCC OA
*ACK*
 
Zuletzt bearbeitet:
Dazu würde ich schon reichen, wenn der OB1 (bzw bei den 1200, 1500 die MainOB´s nicht die feste Priorität 1 und die HMI Kommunikation nicht die feste 15 hätte)
Damit liesse sich gradual die Unterbrechbarkeit priorisieren.
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.
 
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=Xk...AEIIzAA#v=onepage&q=priorität OB 1500&f=false
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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... :eek:

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.
 
Zuletzt bearbeitet:
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é
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :cool:
 
// 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.
 
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 http://www.sps-forum.de/simatic/71057-zykluskontrollpunkt-s7-1200-und-s7-1500-mit-hmi-2.html beschrieben wurde

Beitrag von PN/DP:
Code:
FUNCTION Check_HMI_Var_Int : BOOL
VAR_INPUT
    HMI_Var : INT ;                  [COLOR=#008000]//zu prüfende Variable vom HMI[/COLOR]
    Maxwert : INT ;
    Minwert : INT ;
END_VAR
VAR_OUTPUT
    PLC_Var : INT ;                  [COLOR=#008000]//Arbeitskopie in der PLC[/COLOR]
    xKorrektur : BOOL ;              [COLOR=#008000]//True: HMI-Var muß korrigiert werden[/COLOR]
END_VAR
VAR_TEMP
    Tmp_Var : INT ;
END_VAR

    Tmp_Var := HMI_Var ;             [COLOR=#008000]//HMI_Var vorsichtshalber kopieren, falls Übergabe ByRef[/COLOR]

    xKorrektur := True ;
    IF Tmp_Var > Maxwert THEN        [COLOR=#008000]//größer Maxwert?[/COLOR]
        Tmp_Var := Maxwert ;         [COLOR=#008000]//auf Maxwert setzen[/COLOR]
    ELSIF Tmp_Var < Minwert THEN     [COLOR=#008000]//kleiner Minwert?[/COLOR]
        Tmp_Var := Minwert ;         [COLOR=#008000]//auf Minwert setzen[/COLOR]
    ELSE
        xKorrektur := False ;
    END_IF;
    
    PLC_Var := Tmp_Var ;             [COLOR=#008000]//die geprüfte und ggf. korrigierte Arbeitskopie[/COLOR]
    Check_HMI_Var_Int := xKorrektur ;

END_FUNCTION



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

[COLOR=#008000]// oder:

// Check HMI_Var_2[/COLOR]
    IF Check_HMI_Var_Int(
             HMI_Var := HMI_Var_2    [COLOR=#008000]//hier der einzige Lesezugriff auf die HMI_Variable[/COLOR]
            ,Maxwert := 100
            ,Minwert := 0
            ,PLC_Var => PLC_Var_2    [COLOR=#008000]//die Kopie, mit der das PLC-Programm arbeitet[/COLOR]
         ,xKorrektur => Tmp_BOOL_Var
    ) THEN
        HMI_Var_2 := PLC_Var_2 ;     [COLOR=#008000]//ggf. Korrektur auf HMI_Variable zurückschreiben[/COLOR]
    END_IF;[URL="http://www.sps-forum.de/simatic/71057-zykluskontrollpunkt-s7-1200-und-s7-1500-mit-hmi-2.html"]

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.

 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
@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
 
Wahrscheinlich verstehe ich die Datenflüsse noch nicht gut genug:confused:
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.
 
Zurück
Oben