TIA Programmänderungen im RUN, bei S7-1200 und S7-1500.

Beiträge
8.328
Reaktionspunkte
1.898
Zuviel Werbung?
-> Hier kostenlos registrieren
Diese Thema ist von Ralles Beitrag in das Thema Alternative Steuerungen zu Siemens abgeleitet.

Ralle schrieb:
Ich finde es auch sehr schade, dass Siemens mit dem neuen Konzept die Änderbarkeit der Programme im Online-Betrieb ohne SPS-Stop weitgehend aufgibt.

Vorher gab es ein Thema über die Online Geschwindigkeit, besonders bei Remote VPN Verbindungen. Dies war nicht zufriedenstellend.
Nun bin ich nochmals überrascht, das es gibt Einschränkungen bei Änderungen im RUN. Sehr interessant wenn das is der Tatsache.

Bitte Erfahrungen mit Online Programänderungen in die neue Siemens Steuerungen hier posten.
 
Ich weiß jetzt nicht genau wo das Problem sein soll, aber ...

- bei S7-300 Steuerungen kann man per TIA_Portal keine Bausteine zurücklesen. Bzw. schon zurücklesen, aber damit zerschießt man sich die komplette Symbolik, da TIA nicht in der Lage ist das Offline zusammenzufügen. Für die 1200/1500er muss sie das auch nicht können, da sind die Symboliken mit auf der MMC gespeichert.

- Einen geänderten Baustein "mal schnell" übertragen geht nicht. Es wird es eine Menge mitübersetzt, was zumindest scheinbar nichts mit der Änderung zu tun hat. Aber das kostet ja "nur" Zeit.

- Änderungen in der Bausteinschnittstelle sind nun kein Problem mehr, da alle nötigen Instanzdatenbausteine und die Aufrufe automatisch aktualisiert werden. IDBs werden dabei neu initialisiert.

- Unschöner wird es wenn man das so genannte Multiengeneering der V13 + einer S7-1500 V1.5 nutzen will. Dann ist nämlich die Steuerung der "Master" und wenn Kollege A den FB10 geändert hat und Kollege B will nun seinen FB20 einspielen kommt es erst zu einer synchronisation (FB10 wird an Kollege B zurückgeladen), danach wird der Bausstein geladen. Probleme gibt es, wenn beide den gleichen Baustein ändern, wenn im OB1 was gemacht wurde, wenn PLC-Variablen angefasst wurden. Dann versagt nämlich die automatische Synchronisation und man muss alles händisch machen.

- Behoben soll mit dem UPD5 das Problem des Änderungsladen sein. Problem war: man programmiert den ganzen Tag an der Maschine rum, überträgt viele Bausteine, alles tut. Man schaltet die Maschine zum Feierabend aus, nächsten Morgen wieder ein.... und die CPU startet nicht. Die DAten auf der MMC sind korrumpiert, heißt es. Also formatieren, neu einspielen, tut wieder.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Bevor man im Detail die "Spezialfälle" wie S7-300 Steuerungen per TIA_Portal, Multiengeneering und "Änderungsladen" diskutiert, erstmal eine Frage zum "Normalfall": Kann man in eine S7-1200 oder S7-1500 einen geänderten Baustein einspielen, ohne die CPU in Stop zu versetzen?
Meine persönliche Erfahrung beschränkt sich auf 3 kleine Projekte mit S7-1200 und TIA 12.0. Da ging es anfangs, aber mit wachsendem Umfang? oder nach Benutzung von einem ganz tollen Feature? oder nach einem blöden Anfängerfehler? ging es immer seltener. Immer öfter hieß es, für das Laden müsse die CPU gestoppt werden.
Für diejenigen, die nicht wissen, wo da das Problem sein soll: Wir haben reichlich Maschinen, bei denen die Vorbereitung zum Einschalten und Ingangsetzen zwischen einer halben und zwei Stunden dauert. Die möchte man am Laufen behalten! In eine 300 oder 400 kann ich heute einfach etwas Extracode einfügen, der mir z.B. festhält, ob Endschalter A vor oder nach Endschalter B kam...
 
Hallo,

also ich habe mit einer S7-1500-F programmiert und man kann geänderte Bausteine einspielen ohne die CPU in Stop zu versetzen. Das hat auch bei größeren Änderungen problemlos funktioniert. Einzige Einschränkung: Sobald an einem F-Baustein etwas geändert wurde wird beim Übertragen die CPU in Stop geschaltet. Das Problem mit dem korrupten Daten auf der MMC hatte ich auch einige Male. Da war derSiemens Support keine große Hilfe. Die haben´s erst auf die Projektierung geschoben und zum Schluß ohne Erklärung oder Kommentar empfohlen die Steuerung komplett zu löschen (einschließlich Formatierung der MMC), Hard - / und Software komplett neu übersetzen und dann wieder einspielen. Danach gab es keine Probleme mehr.

Viele Grüße
Klaus
 
Ich muß noch ein wenig mehr ausholen. Es geht nicht ausschließlich um den Stop. Auch die Änderung eines Bausteins, die dann die Übertragung von X beteiligten anderen Bausteinen (die direkt nichts mit der Änderung zu tun haben), insbesondere DB, veranlassen, würde ich nicht besonders fortschrittlich finden, da man nie genau weiß, welche DB-Daten denn nun eigentlich auch überschrieben werden. Das werte ich ebenso als "STOP", denn wenn bestimmte Daten, die ein FC/FB nutzt überschrieben werden, dann ist das genau so gefährlich für einen laufenden Prozess. Das Schlimmste ist eigentlich die Unklarheit, die herrscht. Man ändert irgendwo und weiß nun nicht, das alles warum den "grünen" Punkt einbüßt. Das ist bei Classic und 300/400 vollkommen transparent und auch durchaus noch verständlich nachvollziehbar, bei TIA und 1200/1500 eher nicht. In der Anleitung bin ich dazu noch nicht wirklich fündig geworden, was bei fast 10000 Seiten aber auch nicht verwundert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Ralle

Bislang hatte ich kaum Probleme bei der 1500 mit nicht transparenten Vorgängen.
Einzig das Ändern von Werten von Word -> Int in einem Global-DB hat sie mir übel genommen.
Dachach waren alle Aktualwerte weg und der DB neu initialisiert.

Gruß
Dieter
 
@Ralle

Bislang hatte ich kaum Probleme bei der 1500 mit nicht transparenten Vorgängen.
Einzig das Ändern von Werten von Word -> Int in einem Global-DB hat sie mir übel genommen.
Dachach waren alle Aktualwerte weg und der DB neu initialisiert.

Gruß
Dieter

Man sollte die Aktualwerte vor einer Änderung am DB einer 1200 / 1500 als Startwerte übernehmen, dann gibt es dort keine Probleme
 
Man sollte die Aktualwerte vor einer Änderung am DB einer 1200 / 1500 als Startwerte übernehmen, dann gibt es dort keine Probleme

aber was mache ich wenn ich einen DB ändere der sich schnell ändernde Werte enthält die keines Falls beim Laden des neuen DBs mit Werten von vor einigen Minuten überschrieben werden darf?

Als Beispiel sei da ein Zählwert im DB genannt der jeden Zyklus um einen gewissen Wert erhöht wird und mit einem Wert aus einer anderen Quelle verglichen wird. Bei einer Differenz zwischen den beiden Werten würde die Anlage sofort stoppen, ich muss den Zählwert also beim Laden eines verlängerten DBs "Stoßfrei" beibehalten.
Bei Step 7 Classic ist das kein Problem, aber wie geht das mit TIA?

Ich habe diesen Fall sehr oft, da ich in der Regel nur an laufenden Anlagen arbeite(Stop and Go würde über 1h dauern und wäre zu teuer). Bei DB-Änderungen kann man da zwar Reserven einplanen aber irgendwann sind die am Ende oder die Symbolik der Reserven passt nicht zur gewünschten Änderung (Symbole ala "Spare_0815" ohne Kommentar will ich im Programm nicht sehen).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei einer Differenz zwischen den beiden Werten würde die Anlage sofort stoppen, ich muss den Zählwert also beim Laden eines verlängerten DBs "Stoßfrei" beibehalten.
Bei Step 7 Classic ist das kein Problem, aber wie geht das mit TIA?

Wie machst du das bei Classic? Bei mir werden DBs die ich runterlade weil sie länger geworden sind zwingend initialisiert.

Ich hab mir darum mal einen Baustein gemacht der mir die DB_werte welche nicht verloren gehen dürfen in einen anderen Bereich sichert (Merker, Globaler DB) und dann zyklisch überprüft ob im zu sichernden Baustein der Initial-wert drin steht. Wenn nicht, dann Wert in Sicherungsbereich kopieren. Wenn initial-wert, dann gesicherten Inhalt wieder in den originalen Baustein schreiben.

mfG René
 
Man sollte die Aktualwerte vor einer Änderung am DB einer 1200 / 1500 als Startwerte übernehmen, dann gibt es dort keine Probleme

Weiß ich, aber bei der Änderung des Formats erhalten die Einträge - glaube ich - eine neue interne ID bei optimierten Bausteinen.
Ansonsten kannst du bei der 1500 eigentlich fast alles bei DBs anstellen ohne dass sie es krumm nimmt. Einträge hinzufügen oder Verschieben macht sie alles mit.

Gruß
Dieter
 
Wie machst du das bei Classic? Bei mir werden DBs die ich runterlade weil sie länger geworden sind zwingend initialisiert.

Ich hab mir darum mal einen Baustein gemacht der mir die DB_werte welche nicht verloren gehen dürfen in einen anderen Bereich sichert (Merker, Globaler DB) und dann zyklisch überprüft ob im zu sichernden Baustein der Initial-wert drin steht. Wenn nicht, dann Wert in Sicherungsbereich kopieren. Wenn initial-wert, dann gesicherten Inhalt wieder in den originalen Baustein schreiben.

mfG René

Mit Sicherungsbausteinen arbeite ich auch.
Wenn ich passende Aktualwerte habe, dann erzeuge ich eine AWL-Quelle aus dem DB und ändere diese dann passend ab.
Dabei bleiben die Aktualwerte auch erhalten.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab mir schonmal überlegt einen Baustein zu bauen der wärend der Laufzeit einen DB kreiert (Einen DB ab Nummer 10000.) um den projektierten DB darin abzubilden
Wenn ein DB länger/initialisiert wird, wird der generierte DB-Inhalt zurückkopiert, der generierte DB gelöscht und in neuer Länge neu generiert und der zu sichernde DB inhalt wird in den neu generierten DB gesichert für den Fall das wieder initialisiert wird. Das sichern kann man ja jeden SPS Zyklus machen.

Bisher hab ichs immer rausgeschoben, weil ich üblicherweise kaum 30 wichtige Werte habe die online gesichert werden müssen. Und da rufe ich halt 30 mal den Sicherungsbaustein auf, tut der Zykluszeit kaum weh.

mfG René
 
Zurück
Oben