TIA Namen einer Statischen Variablen eines FB ändern ohne IDB zu reinitialisieren

Zuviel Werbung?
-> Hier kostenlos registrieren
Jo, genau so ist es !!!! Im Prinzip schlechter als bei 300er mit Classic.

in erster linie liegts ja nicht an der CPU sondern an TIA. Wenn man selbst entscheiden könnte was geladen wird, wäre das alles kein Problem. Es fehlt eigentlich nur ein Haken in den Einstellungen der DBs
"kein OnlineOfflinevergleich durchführen"

mfG René
 
in erster linie liegts ja nicht an der CPU sondern an TIA. Wenn man selbst entscheiden könnte was geladen wird, wäre das alles kein Problem. Es fehlt eigentlich nur ein Haken in den Einstellungen der DBs
"kein OnlineOfflinevergleich durchführen"

mfG René

hmm, so einfach wirds nicht sein.. da ja jetzt alles symbolisch funktioniert incl. Visuanbindung, muss bei einer Änderung der Symbolik dies auch in die Steuerung... Wie auch immer, nur dass ich dabei die Aktualdaten verliere ist der Hammer...

Vielmehr müsste in die CPU eine Funktion, welche beim "Einketten" des neuen DBs die Aktualdaten des alten in den neuen kopiert.

Und dies nicht händisch vom Anwender ausprogrammiert, wie Du das machst, sondern implementiert in die Firmware der CPU...

Kann mir nicht vorstellen, das bei Siemens nur Gehirnamputierte sitzen, welche solche Überlegungen nicht anstellen können.

Ich versteh's einfach nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielmehr müsste in die CPU eine Funktion, welche beim "Einketten" des neuen DBs die Aktualdaten des alten in den neuen kopiert.

Und dies nicht händisch vom Anwender ausprogrammiert, wie Du das machst, sondern implementiert in die Firmware der CPU...

Mir würds ja schon reichen wenn er die Aktualdaten übers PG schnell in den runterzuladenden DB als Initialwerte schreibt und dann läd. Ist immernoch nicht ganz stossfrei. Aber besser als der Mist jetzt.
Ich mein jetzt kann man ja auch keinerlei Langzeitdaten auf der CPU vorhalten, denn keiner Garantiert das TIA nicht mal den Drang hat einen DB mit Jahresdaten zu reiinitialisieren.

Ich konnte bis jetzt auch keinerlei Vorteile von den Optimierten DBs erkennen. Bisher hab ich nur die Nachteile zu spüren bekommen.

mfG René
 
Es ist auf jeden Fall ein heißes Thema. Es bereitet mir auch viele Probleme.
Ducati, ich finde deinen Vorschlag nicht schlecht, beim laden eines DBs sollen die Altwerte in den neuen DB wieder automatisiert übernommen werden.
Variablen, welche in dem neuen DB neu angelegt wurden, stehen dann auf 0 und alle alten bereits vorhandenen auf dem Wert des alten DB.

Das wäre (für mich) eine sinnvolle Lösung
 
Ist immernoch nicht ganz stossfrei. Aber besser als der Mist jetzt.

Jo, aber stoßfrei muss es für meine Anwendung eigentlich sein, wie willst Du ne Flankenerkennung mit ner Variablen in nem DB machen, wenn evtl. einen Zyklus lang die Werte nicht gelesen/geschrieben werden...

Denn Sinn von optimierten DBs hab ich auch noch nicht erkannt... Das mit der Speicherreserve ist so ne Sache, neue Variablen anzulegen ist besser wie nichts, aber Reserven konnte ich früher im DB auch selbst anlegen, damals konnte ich die wenigstens noch umbenennen...

Der Performancevorteil fürs lesen von DWORDS ist auch an den Haaren herbeigezogen... Im optimierten DB werden die angeblich schneller gelesen, als in nem nichtoptimierten, wenn das DWORD nicht an einer 4Bytegrenze liegt (also z.B. DB1.DBD2). Bei der Argumentation lach ich mich doch tot...

Wenn wir grad dabei sind, die Ethernetkommunikation ist in der 1500 auch nicht wesentlich schneller als bei einer 315-2PN, wenn ich bei der 315 in der HW-Konfig "Priorisierte BuB-Kommunikation" aktiviere und Zyklusbelastung durch Kommunikation auf 50% stelle... Haben wir hier letzte Woche mal ausgetestet.

Mittlerweile sollte mir lieber kein Siemens-Schlippsträger mehr begegnen...

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
....Wieso muss denn immer der individuelle Programmierstil der bessere sein bzw. sinnvollere sein?
Ich sage ja nicht, dass individuelle Programmierung IMMER besser ist.
Ich wäre froh wenn ich solche "Wunderbausteine" hätte, die alle Eventualitäten erschlagen.
Wir hätten aber gar nicht die Zeit dazu, einen Baustein für ein Klick-Klack-Ventil so aufzublasen,
dass er 40 Tags und was weiß ich wie viele Bytes Arbeitsspeicher braucht.
Außerdem würde uns das mancher Kunde um die Ohren hauen, wenn seine Instandhalter damit nicht auf Anhieb zurechtkommen.

Ich bekomme öfters "Fremdprogramme" in die Hand, weil wir früher manche Sachen vergeben haben
und auch schon mal Anlagen umbauen die nicht von uns sind.
Dabei sehe ich eben oft, dass manche Programmierer meinen sie müssten sich ein Denkmal setzen
indem sie alles so kompliziert wie möglich machen. Weniger ist manchmal mehr.

Du propagierst hier ja eifrig die Vorteile die dir entstanden sind, seit Siemens uns die Segnungen des mächtigen TIA-Portals zuteil werden lässt.
Leider verstehe ich meistens nur Bahnhof bei deinen Lobhudeleien auf TIA und ich denke das geht 90% der User hier genauso.

Nix für ungut, geht nicht gegen dich persönlich, soll halt jeder machen wie er denkt,
aber mir geht TIA einfach nur wahnsinnig auf den Geist, und das geht ja vielen hier so.
Auch solchen Programmier-Cracks mit denen ich mich NIEMALS auf eine Stufe stellen würde.

Ich glaub ich wird langsam zu alt für den Sch..ß
 
Jo, aber stoßfrei muss es für meine Anwendung eigentlich sein, wie willst Du ne Flankenerkennung mit ner Variablen in nem DB machen, wenn evtl. einen Zyklus lang die Werte nicht gelesen/geschrieben werden...

Ich hab mir letzte Woche mal ne 400 im TIA portal angelegt. Wenn du da 10MB an DBs hast mit UDTs drin und einen UDT z.B. den Namen Anpasst, dauert das ca ne halbe Stunde bis er alle DBs runtergeladen hat (notabene mit reinitialisierung).
Bei Programmen die mehrere MB gross sind dauert es eine Ewigkeit bis man was machen kann. Nur schon dafür sollte man die Siemensianer treten. Ich weiss selbst welche DBs mich interessieren, die welche ich selbst aktuell halte muss ich nicht von Tia auf Online/Offline unterschiede kontrolliert haben.

Wenn die CPU dann noch etwas kommunikationslast hat, geht die Verbindung vollends in die Knie. Keine Ahnung wer daran interesse haben könnte dass das PG immer schaut ob Online/offline alles aktuell ist. Dafür hätte also auch ein Knopf gereicht um das ab und zu anzustossen.
Kennt Siemens wohl nur so Minianlagen unter 100kb an Daten auf der CPU? Regalsysteme mit den daten auf der CPU statt im SCADA hats es nicht zu geben?
Wozu bauen die dann CPUs mit so viel Speicher?

mfG René
 
.... beim laden eines DBs sollen die Altwerte in den neuen DB wieder automatisiert übernommen werden.
Variablen, welche in dem neuen DB neu angelegt wurden, stehen dann auf 0 und alle alten bereits vorhandenen auf dem Wert des alten DB.

Das wäre (für mich) eine sinnvolle Lösung
Das wäre das mindeste was man erwarten kann, bei einer Software die die Automatisierungsbranche revolutionieren soll.
Leider haben die TIA Entwickler offenbar noch nie eine echte Inbetriebnahme durchgeführt, sonst wüssten sie was sie uns damit antun.
Und ich denke das wird auch noch eine Zeit lang ein frommer Wunsch bleiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Richtig Paul, das wäre das mindeste.
Ich habe meine Ansprüche mittlerweile runtergefahren. Mit Step7 fahre ich aktuell noch besser. Ich warte
noch ein paar SP´s von TIA 14 ab und muss dann zwangsläufig komplett umsteigen, wenn wir Schaltschränke mit
1500ér bauen. Ich glaube ich werde auch zu alt und hoffe, dass ich nur noch für Änderungen und Umbauten eingesetzt
werde und keine hochsensible Anwendung ( Kunde und Produktionsablauf sensibel ) eingesetzt werde für 1500ér

Mit Grüßen
 
Es ist auf jeden Fall ein heißes Thema. Es bereitet mir auch viele Probleme.
Ducati, ich finde deinen Vorschlag nicht schlecht, beim laden eines DBs sollen die Altwerte in den neuen DB wieder automatisiert übernommen werden.
Variablen, welche in dem neuen DB neu angelegt wurden, stehen dann auf 0 und alle alten bereits vorhandenen auf dem Wert des alten DB.

Das wäre (für mich) eine sinnvolle Lösung
Ich bin mir nicht sicher was Du mit "automatisiert übernehmen meinst" aber bei Anwendungen mit Reaktionszeiten im ms-Bereich oder darunter möchte ich nicht, dass beim ändern im Betrieb Daten kopiert warden, denn die Kopierzeit muss natürlich in die Reaktionszeit eingehen, sonst würde das Programm ja halb alte halb neue Daten sehen. Die Daten sollen mal schön bleiben wo sie sind.

Das Reservekonzept ist hier der bessere Ansatz, denn man bemerkt bei Änderungen im Betrieb keine Rückwirkungen auf die Reaktionszeiten.

Verbesserungspotential sehe ich aber schon:

Es wäre schön, wenn man auch in Strukturen Reserven haben könnte.

Noch schöner wäre, wenn man Variable auch Umbenennen könnte. Allerdings stelle ich es mir schwierig vor, Umbenennungen hantieren zu können. Man bräuchte eine Art Variablen-Historie dafür. Außerdem würde es schwierig werden, wenn es externe Bezüge auf die Namen gäbe, z.B. durch OPC UA, ....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Reservekonzept ist hier der bessere Ansatz, denn man bemerkt bei Änderungen im Betrieb keine Rückwirkungen auf die Reaktionszeiten.
Aber NICHT das "Reservekonzept" vom TIA...

Ich hab schon Reserven in meinen DBs seit ich programmieren kann... Daran ist ja nun nix tolles ;)

Ansätze und Ideen, wie man sowas ordentlich hinbekommt, gibt es sicherlich mehrere...

Nur Siemens scheint die nicht zu haben ;)
 
Aber NICHT das "Reservekonzept" vom TIA...

Ich hab schon Reserven in meinen DBs seit ich programmieren kann... Daran ist ja nun nix tolles ;)

Ansätze und Ideen, wie man sowas ordentlich hinbekommt, gibt es sicherlich mehrere...

Nur Siemens scheint die nicht zu haben ;)

Sagen wir mal so: ich kann einschätzen, was daran toll ist (die nicht vorhandenen Rückwirkungen auf die Reaktionszeiten und die hohe Anzahl von gleichzeitig änderbaren Bausteinen) und was nicht (was ich vorhin erwähnt habe) ;)

Ich kann aber auch einschätzen, was bisher ging und jetzt nicht mehr :TOOL:
 
Ich kann mir ehrlich gesagt auch nicht vorstellen, dass Siemens so doof ist und nicht mal bei Codesys spioniert was die so treiben. Ich habe zur Zeit das Glück ein PacDrive 3 zu projektieren und darf erleben was mein Kollege in TIA V13 für Probleme hat. Da kann ich mich nur glücklich schätzen.
Wie Codesys das macht kann ich mir nur so erklären, dass die einen Zykluskontrollpunkt abwarten und da dann das bereits fertig geladene Programm übernehmen wobei sie auch alle Bestandsvariablen übernehmen und neue mit den Defaultwert beschreiben. Klingt eigentlich ganz einfach.
Ich finde, dass Siemens das versucht was Codesys schon lange kann...

Gesendet von meinem SM-G930F mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie Codesys das macht kann ich mir nur so erklären, dass die einen Zykluskontrollpunkt abwarten und da dann das bereits fertig geladene Programm übernehmen wobei sie auch alle Bestandsvariablen übernehmen und neue mit den Defaultwert beschreiben. Klingt eigentlich ganz einfach.
Klingt ganz einfach :D und die Theorie ist auch jedem klar - doch wie lange dauert die Einkettung bei 100kB symbolischen Daten? Kann Codesys das auch ohne Programm-Stop?

Harald
 
hätte wäre könnte...

Vielleicht sollten wir wieder zum eigentlichen Thema kommen.

Wie kann man dieses Problem (Reinitialisierungswut) unter den gegebenen Bedingungen (TIA v13 SP1 und S7-1500) auf einfache Weise lösen?

Randbedingungen:
- zyklusgenau, stoßfrei
- Speicher und Zykluszeit schonend

Also z.B. Merker: bleiben die eigentlich immer erhalten, oder "reinitialisiert" TIA die auch irgendwann? Was ist mit remanenten und nicht remanenten Merkern?
Hat damit schon mal jemand bei der 1500er rumgespielt? Nachteil bei Merkern sehe ich darin, man kann die ja nicht gescheit vorbelegen. Bzw. müsste man sich ja auch was basteln um die "Rückzulesen".

Gruß.
 
Bei TIA muß man sich wohl ein ähnliches Vorgehen Step-by-Step neu überlegen

Basierend auf Vollmis Lösung versuche ich jetzt mal folgendes:

- Am Ende des OB1 werden die Inhalte von wichtigen DBs mittels UBLKMOVin einen großen Sicherungs-DB kopiert, welcher so groß ist, dass er nicht mehr verändert werden muss.
- Am Anfang des OB1 wird bei Erkennen einer Reinitialisierung diese Sicherung wieder in die eigentlich verwendeten DBs rückgesichert.

aber:
- Das Ganze geht nur bei nicht optimierten DBs
- Die Struktur der DBs darf sich nicht mehr ändern
- wenn ein Reinitialiseren erkannt wurde, muss u.U. der OB35 für einen Aufruf übersprungen werden, falls dieser Aufruf vor dem ersten Netzwerk im OB1 zufällig erfolgt.

Für uns sollte das so funktionieren.

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mit UBLOCKMOV wollte ich es auch erst machen. Da die Daten die zu sichern sind aber remanent sind müsste dies ja im zu sichernden DB ja auch so sein. Dafür reicht aber mein Remanenzspeicher bei weitem nicht mehr aus. Will heissen. bei jedem restart der CPU verliert auch der sicherungsdb die Daten.
Man könnte aber den Sicherungsdb als einzigen DB remanent machen und dann einfach im firstcycl rücksichern. Find ich aber so richtig uncool.
So eine richtig schöne Vorgehensweise fällt mlr leider auch nicht ein. Und ehrlichgesagt, finde ich das eine so üble schwäche im System dass ich eigentlich Siemens im Zugzwang sehe.

mfG René
 
Wo wir gerade beim Thema DBs sind: Ich weiß nicht, wie das bei der 1500er ist, aber bei der 1200er (an einer sehr kleinen Maschine) führt die Übertragung eines einzelnen DBs mit einer einzigen geänderten Variablen unter Umständen schon dazu, dass man nur im STOP übertragen kann, selbst wenn man die Aktualwerte nicht retten möchte.
Warum? Alle Codebausteine, die den DB verwenden, werden neu übersetzt. Das kann, je nach Zweck des DB, quasi das gesamte Programm sein. Wenn man anschließend übertragen möchte, kommt eine Meldung, die sinngemäß etwa lautet "Die Anzahl der geänderten Bausteine ist zu groß, um im RUN zu übertragen. CPU muss gestoppt werden." Wenigstens kann man auswählen, ob man fortfahren möchte.
Bei unseren kleine Maschinen ist das kein Problem, aber wehe dem, der mit der 1200er eine große Anlage betreibt.
 
Mit UBLOCKMOV wollte ich es auch erst machen. Da die Daten die zu sichern sind aber remanent sind müsste dies ja im zu sichernden DB ja auch so sein. Dafür reicht aber mein Remanenzspeicher bei weitem nicht mehr aus. Will heissen. bei jedem restart der CPU verliert auch der sicherungsdb die Daten.

Bei uns geht es eher um stoßfreies Laden von reinitialisierten DBs.

Bei CPU-Stop steht eh die Anlage, also eh egal.

Einstellwerte, Zählwerte etc. werden bei uns eh schon auf andere Art und Weise gesichert.

Und ehrlichgesagt, finde ich das eine so üble schwäche im System dass ich eigentlich Siemens im Zugzwang sehe.

mfG René

Wir haben grad eine "größere Beschwerde" eingereicht ;)
 
Zurück
Oben