TIA Vermeidung vom Initialisieren der DBs

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

S7-300 ist ein fast 30 Jahre altes System, S7-400 detto.

S7-300 / 400ér CPU´s kann man noch neu kaufen. Ich wollte damit auch nur sagen, dass es alles schon einmal möglich war. Bei S5 genauso ( ok, anderes Thema ).

Ich hätte wohl "alle modernen Steuerungen am Markt" schreiben sollen.

Genau, hier fragen sich ja auch nur ein paar wenige, warum ist mit einem "modernen" System etwas nicht mehr möglich was mit einem "uralten" Sytem schon einmal möglich war.

Zu sagen, bei anderen ist es ja genauso ist irgendwie auch keine echte Antwort sondern nur ein abtun. War es nicht mal Ziel, sich mit "Features" von Mitbewerbern abzuheben? Heute reicht es zu sagen "bei anderen ist es auch so"?

 

[ducati]

Alle Programmierer die sich hier über das Reinitialisieren von DBs mukieren, sollten mal ihre Hausaufgaben machen und sich ein sauberes Datenmodell überlegen und auch daran denken was Programmänderungen an der laufenden Anlage bedeuten.

OK, mal ein Beispiel aus der täglichen Praxis:
Ich habe einen FB, der u.A. mehrere Pumpen steuert. Die benötigten Variablen befinden sich pro Pumpe in je einer Struktur im Instanz-DB dieses FB.
Jetzt muss für eine Pumpe eine Temperaturüberwachung im laufenden Betrieb nachgerüstet werden. Um ne Hysterese zu haben, brauche ich ein stat Bool, welcher bei über 50° gesetzt wird und unter 45° wieder rückgesetzt wird.
Da dieses Bool zu der einen Pumpe gehört, hätte ich das gern in der Struktur.
Bei S7-300/400 habe ich deshalb von vornherein immer Reserve-Bool in den Strukturen, die bei Bedarf benutzt und umbenannt werden. Bei S7-300/400 geht das stoßfrei im laufenden Betrieb, bei S7-1500 nicht.
So, also muss man das jetzt anders machen. D.h. die Speicherreserve nutzen und das neue Bool irgendwo am Ende des DB dranklatschen, oder nen Merker hernehmen, oder nen neuen DB hernehmen, oder das Reserve-Bool nicht umbenennen, oder sich händisch nen Rettungsmechanismus bauen, der am Ende vom OB1 den DB sichert und am Anfang vom OB1 wieder rücksichert.
Alles keine schönen Lösungen.
Welches andere Datenmodell hab ich da jetzt übersehen?

 

[GrauesHaar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jedes Projekt beginnt seither mit der Datenmodell-Planung.

Das freut mich für dich, dass du so viel Zeit für deine Projekte hast.
Wir sind ein kleines Schrittchen weiter und haben einen gewissen Standard, der unter anderem auch das Datenmodell weitestgehend vorgibt.

Alle Programmierer die sich hier über das Reinitialisieren von DBs mukieren, sollten mal ihre Hausaufgaben machen und sich ein sauberes Datenmodell überlegen und auch daran denken was Programmänderungen an der laufenden Anlage bedeuten.

Danke für den Vorschlag. Ich denke, dass ich in Sachen Software-Design keine Nachhilfe brauche.
Das tollste Design funktioniert aber nicht, wenn einer der Softwerker nur einen Klick (hier zum Beispiel bei der Markierung "Sollwert" innerhalb eines DBs) mal nicht macht. Soll heißen: Nach meiner Erfahrung kannst du nicht per Definition im Bereich Software-Design erreichen, dass später bei der Datensicherung nichts in die Hose geht.

 

[ducati]

Das tollste Design funktioniert aber nicht, wenn einer der Softwerker nur einen Klick (hier zum Beispiel bei der Markierung "Sollwert" innerhalb eines DBs) mal nicht macht. Soll heißen: Nach meiner Erfahrung kannst du nicht per Definition im Bereich Software-Design erreichen, dass später bei der Datensicherung nichts in die Hose geht.

Dazu kommt, dass an manchen Anlagen über 30 Jahre 10 verschiedene Firmen mit 20 verschiedenen Programmierern rumändern... Da kannst vergessen, dass da alle Haken für "Einstellwerte" richtig gesetzt sind. Wenn jetzt niemand mehr Variablennamen umbenennt, weil sonst die Anlage aus geht, dann kannst dir vorstellen, wie sowas nach 30 Jahren aussieht.

Also am besten alle 5 Jahre eh alles neu bauen... wie bei Handys halt auch.

 

[Onkel Dagobert]

... Ich denke, dass ich in Sachen Software-Design keine Nachhilfe brauche...

Das eingangs erwähnte Programm, an dem du Änderungen machen willst, stammt aber aus deiner Feder?

Dazu kommt, dass an manchen Anlagen über 30 Jahre 10 verschiedene Firmen mit 20 verschiedenen Programmierern rumändern...

Was soll man dazu sagen? Da läuft ja grundsätzlich etwas verkehrt.

... Da kannst vergessen, dass da alle Haken für "Einstellwerte" richtig gesetzt sind...

Wenn man ein System hat, dann setzt man den Haken für "Einstellwert" ein einziges Mal im UDT, und dann idealerweise nie wieder! Das geht natürlich nur wenn man ein ausgereiftes "Datenmodell" verwendet, welches nicht mehr geändert werden muss, vielseitig verwendet werden kann, und auch am HMI verwendet wird. Was macht ihr denn eigentlich bei Änderungen solch fundamentalen Strukturen mit den Bildbausteinen, die mit diesen Strukturen beschaltet sind? Oder gibt es so etwas bei euch gar nicht? Die müssten ja auch bei jeder Änderung nachgezogen werden.

OK, mal ein Beispiel aus der täglichen Praxis:
... Die benötigten Variablen befinden sich pro Pumpe in je einer Struktur im Instanz-DB dieses FB...
... Da dieses Bool zu der einen Pumpe gehört, hätte ich das gern in der Struktur...

Die daraus resultierenden Probleme kannst du vermeiden, indem du deine Strukturen in einem globalen DB ablegst. Dort sind alle Betriebsarten, Schaltzustände, Parameter, Flankenmerker etc. gespeichert. Dieser DB ist "heilig", sollte also nicht mehr geändert werden müssen. In diesem DB ist natürlich genügend Reserve vergesehen. Vielleicht kannst du dich auch mit einem ARRAY of UDT anfreunden, und nur im Kommentar die Namen der Pumpen, Regler etc. pflegen. Wenn, um bei deinem Beispiel zu bleiben, ein Zweipunktregler als Automatik-Freigabe bei einer Pumpe hinzu kommt, dann gehört er in die Instanzdaten des FB und keinesfalls in die Struktur der Pumpe. Das macht das Programm auch gleich wieder übersichtlicher.

Natürlich liegt es an jedem selbst, wie er seine Werkzeuge nutzt. Nur muss man bei unsachgemäßer Nutzung auch mit den daraus resultierenden Konsequenzen leben.

Welches andere Datenmodell hab ich da jetzt übersehen?

Du hast doch gar kein "Datenmodell"!

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das freut mich für dich, dass du so viel Zeit für deine Projekte hast.
Wir sind ein kleines Schrittchen weiter und haben einen gewissen Standard, der unter anderem auch das Datenmodell weitestgehend vorgibt.

Wenn er euer Standard allerdings solche Probleme verursacht, wäre es doch mal an Zeit an der Version 2.0 des Standards zu arbeiten?!?

 

[GrauesHaar]

Dazu kommt, dass an manchen Anlagen über 30 Jahre 10 verschiedene Firmen mit 20 verschiedenen Programmierern rumändern... Da kannst vergessen, dass da alle Haken für "Einstellwerte" richtig gesetzt sind.

In der Tat waren es bei dem "eingangs erwähnten Programm" ca. 10 Jahre, >6 verschiedenen Firmen aus 4 Nationen (UK, Spanien, Indien, D) >20 Programmierer. Das bringt der Sonderanlagenbau in einem Konzern so mit sich.

Das eingangs erwähnte Programm, an dem du Änderungen machen willst, stammt aber aus deiner Feder?

Nein, dort war ich in der Tat das erste Mal mit dem Auftrag "das läuft nicht so richtig, flieg mal rasch hin". Ist ja auch kein Ding. Aber natürlich verlassen ich mich da nicht auf jeden einzelnen Klick.

Wenn er euer Standard allerdings solche Probleme verursacht, wäre es doch mal an Zeit an der Version 2.0 des Standards zu arbeiten?!?

Dann sag mir bitte, wie?
Das ist genau einer der Punkt, die ich noch nicht verstanden habe: Wenn bei einer(!) einzigen Variable, der Startwert zur Laufzeit nicht übernommen werden darf, dort aber der Haken "Sollwerrt" angehakt ist, und ich Dusel möchte es richtig machen und kopieren die Momentanwerte in die Startwerte (Nur Sollwerte), dann kann das in ein paar Wochen böse Folgen haben. Natürlich(!) sind gemäß Standard alle zu sichernden Parameter in einigen wenigen DBs abgelegt, die entsprechende Namen haben, aber woher weiss ich, dass sich alle Programmierer immer daran gehalten haben und nicht vielleicht doch ein Parameter in einem DB befindet, der nicht gesichert wird. Genau: Der/ die Gute hat dann wohl Pech gehabt mit ihrer Variable (dann sichere ich den Wert halt nicht). Aber: deshalb läuft die Anlage dann trotzdem Scheiße, nachdem das nächste mal die Startwerte geladen werden.
Also: Per Definition im Standard kannst du solche Fehler nicht vermeiden.
Wäre schön, wenn die Werkzeuge da nachvollziehbarer funktionieren würden.
Aber geht schon, habe durch die Aktion super dazugelernt.

Was ich aber interessant finde: Dass bei diesem Thema ganz offensichtlich so viel Unsicherheit besteht, dass hier die Diskussionen noch so lange nachkochen. Gleichzeitig ist der Ton auch bisl aggressiv. Warum?
Ich finde es großartig wie jeder durch Informationaustausch hier Hilfe finden kann.
Nu habt euch mal wieder lieb!

 

[Mrtain]

Also aggressiv empfinde ich den Ton hier gerade nicht....
@maxder2te hat insofern schon recht, dass sich viel zu wenig Gedanken über die Datenstruktur gemacht wird. Bin da letztens auch selbst drüber gestolpert. Udt mit HMI /PLC & gespeichert Sollpositionen, das für mehrere Achsen und alles in eine DB. Jetzt müsste ich da was ändern, reinitialsieren und alle erfassten Achspositionen, die ich bis dato nicht in den Startwerten gespeichert hatte, waren für den Allerwertesten. Zum Glück war es am Anfang der IBN. Hätte ich die Positionen von vornherein ausgelagert, am besten noch je Achse in einen DB, hätte ich das Problem nicht gehabt

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was soll man dazu sagen? Da läuft ja grundsätzlich etwas verkehrt.

ja sicher, da kannst aber nichts dran ändern, Kunde kann halt an seinen Anlagen rumprogrammieren lassen wen er will...

Was macht ihr denn eigentlich bei Änderungen solch fundamentalen Strukturen mit den Bildbausteinen, die mit diesen Strukturen beschaltet sind? Oder gibt es so etwas bei euch gar nicht? Die müssten ja auch bei jeder Änderung nachgezogen werden.

Änderungen an solchen standardisierten Strukturen gibts in der Regel im lauenden Betreib nicht, die sind tatsächlich heilig, darum gehts hier aber in dem Thema garnicht. Das zusätzliche "Automatikfreigabebit" liegt doch nicht in den Strukturen zur Anbindung ans HMI, wie kommst Du auf die Idee?

Die daraus resultierenden Probleme kannst du vermeiden, indem du deine Strukturen in einem globalen DB ablegst. Dort sind alle Betriebsarten, Schaltzustände, Parameter, Flankenmerker etc. gespeichert. Dieser DB ist "heilig", sollte also nicht mehr geändert werden müssen. In diesem DB ist natürlich genügend Reserve vergesehen. Vielleicht kannst du dich auch mit einem ARRAY of UDT anfreunden, und nur im Kommentar die Namen der Pumpen, Regler etc. pflegen.

irgendwie reden hier alle (absichtlich) aneinander vorbei. Für UDTs der einzelnen Pumpen-Elemente mach ich das genauso. Nur geht es mir hier in dem Thema nicht darum, sondern um Variablen die zusätzlich zu diesen Standardstrukturen benötigt werden.

Wenn, um bei deinem Beispiel zu bleiben, ein Zweipunktregler als Automatik-Freigabe bei einer Pumpe hinzu kommt, dann gehört er in die Instanzdaten des FB und keinesfalls in die Struktur der Pumpe. Das macht das Programm auch gleich wieder übersichtlicher.

Hab ich doch geschrieben, die "Automatikfreigabe" liegt doch in den Instanzdaten des FB. Nur werden diese dann halt blöderweise bei Änderungen reinitialisiert. Da ich mehrere Pumpen in diesem FB bearbeite liegen die jeweils benötigten Variablen dort auch noch einmal sortiert in Strukturen und nicht wirr verteilt im IDB. (Das ist nicht die selbe Struktur, welche für z.B. HMI verwendet wird sondern vielleicht sowas wie eine "Strukturierung der jeweils für Automatikfunktionen benötigten Variablen)

Du hast doch gar kein "Datenmodell"!

was versteht ihr denn unter Datenmodell?

 

[ducati]

Gleichzeitig ist der Ton auch bisl aggressiv. Warum?

Das ist immer derselbe Forentroll. Immer wenn jemand eines der grundlegenden Probleme vom TIA anspricht ist der jemand für ihn einfach nur nicht schlau genug, TIA zu bedienen.

Ansonsten ist natürlich immer jeder Programmierer schlauer als jeder andere

Und oft wird auch einfach nur aneinander vorbei geredet.

Hier werden ja auch immer zwei Themen vermischt, wie kann ich Einstellwerte sichern, wie kann ich Änderungen stoßfrei im laufenden Betrieb machen.
Hat beides nicht viel miteinander zu tun, ausser dass das ursächliche Problem für beides das Reinitialisieren ist. Wobei man Einstellwerte so oder so regelmäßig mal ins Offline Projekt sichern sollte, falls die SPS mal defekt gehen sollte...

Und spätestens, wenn ich mal Änderungen an einem nicht von mir selbst erstellten Programm oder Programmierstil machen MUSS, hab ich eh keinen Einfluss auf die "Datenstruktur"... ICH WILL EINFACH NUR NE VARIABLE EINFACH UMBENENNEN KÖNNEN (weil es abundzu warum auch immer notwendig ist), OHNE DASS REINITIALISIERT WIRD

 

[Cassandra]

Mal schnell einen „Variablennamen“ ändern ist bei S7-Classic recht einfach.
Bei vielen moderneren Systemen scheinbar nicht mehr.


Hier noch ein weiterer Vergleich von ChatGPT zu anderen üblichen Änderungen.
B&R fällt hier positiv auf…

 

[Chräshe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielleicht lohnt auch mal ein Blick in die IT Welt zu „echten“ Datenbanken. Wenn hier neue/umbenannte Datenfelder benötigt werden, gibt es Befehle um die DB anzupassen. Niemand würde eine Produktionsdatenbank initialisieren, nur weil sich die Struktur geändert hat. Warum sollte es soetwas in der SPS Welt nicht auch geben? Die Notwendigkeit ist ja definitiv da.

Das ist ein vielversprechender Ansatz.
Die Schwierigkeit wird sein, Daten in der SPS zu retten, umstrukturieren, und neu einzubinden. Das alles innerhalb eines SPS-Zyklus.

 

[vollmi]

Die Diskussion hatte ich vor Jahren schon mit den Herren von Siemens.
Wenn sie wenigstens mal auf Alternative mit Global-DBs hinweisen würden und ein paar Beispiele zeigen würden, wär ich ja zufrieden.
Jeder Anfänger meint, dass die Guidelines fast sowas wie die Bibel sind.

Hast du mal die Programmierbeispiele von Siemens angesehen? Wäre mal cool, wenn die welche die Programmierrichtlinien schreiben, diese auch bei Siemens selber durchsetzen. Dann würden die welche die Beispiele programmieren, denen vielleicht auch mal aufs Dach steigen.
Der Gipfel sind ja dann Bibliotheksbausteine in den Standardbibliotheken, die man über den STAT
Bereich der Schnittstelle konfigurieren muss.
Ich bin ja auch kein Freund von endlosen Sitzungen. Aber so ab und zu wäre es möglicherweise Sinnvoll, wenn die Siemens Entwickler für TIA, mit den Siemens SPS Programmierern, mit den Siemens Dokumentationsschreibern, reden, schreiben, Telefonieren, Meetings abhalten? Die gehören dammich zu demselben Konzern.

 

[Blockmove]

Hast du mal die Programmierbeispiele von Siemens angesehen? Wäre mal cool, wenn die welche die Programmierrichtlinien schreiben, diese auch bei Siemens selber durchsetzen. Dann würden die welche die Beispiele programmieren, denen vielleicht auch mal aufs Dach steigen.
Der Gipfel sind ja dann Bibliotheksbausteine in den Standardbibliotheken, die man über den STAT
Bereich der Schnittstelle konfigurieren muss.

Also über die Konfig im Stat-Bereich hab ich mich auch schon aufgeregt.
Da kann man sich nur an den Kopf fassen.
Normalerweise gehört da in dem Konzern ein Code-Review Prozess her.
Ich benutz seit vielen, vielen Jahren Linux.
Wenn man da hin- und wieder mitbekommt, wie heftig da in der Kernel-Mailingliste über Code-Design gestritten wird, würde man sich sowas auch mal bei Siemens (und anderen Herstellern) wünschen.

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie oft besteht denn wirklich in etablierten laufenden Systemen die Notwenigkeit Variablen umzubenennen? Für mich ist das ein viel zu theoretische Diskussion. Wenn sich wirklich was ändert, dann füge ich eine neue Variable hinzu und markiere die alte Variable im Kommentar als obsolet falls das Initialisierungen vermeidet.

 

[Blockmove]

Vielleicht lohnt auch mal ein Blick in die IT Welt zu „echten“ Datenbanken. Wenn hier neue/umbenannte Datenfelder benötigt werden, gibt es Befehle um die DB anzupassen. Niemand würde eine Produktionsdatenbank initialisieren, nur weil sich die Struktur geändert hat.

Da gilt aber auch in der Theorie geht's und in der Praxis sieht es oft ganz anders aus.
Du hast da auch Änderungen für die du Migrationsfunktionen schreiben musst.
Also so richtig stoßfrei geht es da oft auch nicht.

 

[DeltaMikeAir]

Wie oft besteht denn wirklich in etablierten laufenden Systemen die Notwenigkeit Variablen umzubenennen? Für mich ist das ein viel zu theoretische Diskussion.

Hin und wieder halt. Ist es denn wirklich zu viel verlangt, eine Variable ohne Reinit/CPU Stop umbenennen zu können?
Ein Umbenennen einer Variablen kann ja auch z.b. notwendig sein um sie verständlicher zu beschreiben. Also als reine Verbesserungsmaßnahme.

Wenn sich wirklich was ändert, dann füge ich eine neue Variable hinzu und markiere die alte Variable im Kommentar als obsolet

So fängt das Chaos dann im kleinen an.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie oft besteht denn wirklich in etablierten laufenden Systemen die Notwenigkeit Variablen umzubenennen? Für mich ist das ein viel zu theoretische Diskussion. Wenn sich wirklich was ändert, dann füge ich eine neue Variable hinzu und markiere die alte Variable im Kommentar als obsolet falls das Initialisierungen vermeidet.

täglich bei mir... wir arbeiten fast ausschließlich an Anlagen im laufenden Betrieb...

wieich weiter oben schon geschrieben hab, sortiere ich meine Variablen etwas, damit man sich halt zurecht findet. Neue Variablen hinzufügen geht halt nur am Ende. Das ist dann irgendwann Chaos...

 

[rostiger Nagel]

Bei diesen Unmengen an Hacken, könnten Siemens noch einen schaffen,
mit der Funktion „aktuellen Variablen Wert beibehalten“, um den Rest hat
sich halt TIA zu kümmern.

 

[vollmi]

Wie oft besteht denn wirklich in etablierten laufenden Systemen die Notwenigkeit Variablen umzubenennen? Für mich ist das ein viel zu theoretische Diskussion. Wenn sich wirklich was ändert, dann füge ich eine neue Variable hinzu und markiere die alte Variable im Kommentar als obsolet falls das Initialisierungen vermeidet.

Ja aber schön aufgeräumt ist das ja nicht mehr. Ich würde gerne immer mehr in UDTs packen. Aber wenn man die dann nicht mehr anpassen kann und man ne zusätzliche Variable dann im DB ganz am Schluss hinpacken muss, hat man am Ende Objektbausteine an denen hängt an IN/OUT ein UDT und an zusätzlichen IN und OUTs noch Zusätze wie Betriebsstunden, Energie, Sollwerte die eigentlich ins UDT gehörten, aber jetzt halt an zusätzlichen Punkte mit zusätzlichen DBs hinzugefügt wurden.
Ich mache für viele SW, Betriebsstundenzähler etc. Sicherungsbausteine, welche die DB Variable überwachen und in ein Merkerwort sichern um bei Reinit dieses Merkerwort wieder in den DB zu schreiben. Dass man solche Verrenkungen machen muss ist gelinde gesagt lächerlich.