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

[miasma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist ja lustig, dass man riesen Speicherbereiche im Voraus vorbelegen muss, damit es später zu keinen Problemen kommt. Es ist schon verrückt.
Wenn man bedenkt, was für Programme und Spiele auf einen Commodore C64 liefen. Alles war optimiert auf geringst möglichen Speicherverbrauch.
Und das ging auch ganz einfach. Heute, 30 Jahre später muss man 256 Ventile anlegen, wenn man 3 hat. Es könnten ja noch welche dazu kommen ?!?!

Schöne neue Welt

Naja, der Speicher kostet ja auch nichts mehr.

Die Elemente kann ich alle einzeln Anlegen. Sie sind aber immer auf alle Varianten unserer mechanischen Ausführung ausgelegt.
Bei solchen Elementen geht es um optimale Funktionalität, der Speicher spielt da eine untergeordnete Rolle.

Speicher ist doch dazu da um gebraucht/verbraucht zu werden, seien es nun 64kB , 128kB oder 2MB.

 

[ducati]

O.K. ich verstehe.

Du müsstest Du vorläufig mit der Variable db1000.Ventil1.Reserve arbeiten, ohne die Variable umzubennen (im Kommentar könntest aber etwas über die Verwendung vermerken).

Dagegen spricht ein unleserlicher Programmcode, wenn ich in der Logik dann ständig symbolisch mit #Ventil1.Reserve arbeite...

Ich bin kein Instandhalter in einem Werk, wo ich das dann mal irgendwann bei einem Stillstand geradeziehen könnte. Unsere Anlagen sind überall verstreut und nur um nen Text geradezuziehen fahr ich da bei nem Stillstand nicht hin.

Alternativ könntest Du eine neue um die Variable erweiterte Struktur hinzufügen DB1000.Ventil1V2.Stoerung.

Dagegen spricht, dass ich alle Verwendungsstellen von #Ventil1.Freigabe dann in #Ventil1V2.Freigabe umändern müsste (da sind meist ca. 10 verwendete Bools in der Struktur mit jeweils 2-3 Verwendungen...) An einer laufenden wichtigen Anlage ist das nicht möglich, da die Gefahr eines Fehlers zu groß ist.

Gruß.

 

[miasma]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dagegen spricht ein unleserlicher Programmcode, wenn ich in der Logik dann ständig symbolisch mit #Ventil1.Reserve arbeite...

Ich bin kein Instandhalter in einem Werk, wo ich das dann mal irgendwann bei einem Stillstand geradeziehen könnte. Unsere Anlagen sind überall verstreut und nur um nen Text geradezuziehen fahr ich da bei nem Stillstand nicht hin.
Dagegen spricht, dass ich alle Verwendungsstellen von #Ventil1.Freigabe dann in #Ventil1V2.Freigabe umändern müsste (da sind meist ca. 10 verwendete Bools in der Struktur mit jeweils 2-3 Verwendungen...) An einer laufenden wichtigen Anlage ist das nicht möglich, da die Gefahr eines Fehlers zu groß ist.

Gruß.

Du vergibst also innerhalb der Instanz absolute Namen (BMKs) für deine Ventile? Musst Du dann nicht von Projekt zu Projekt immer was ändern?

 

[DeltaMikeAir]

Solange keiner das Spiel weiterentwickelt, während es gerade gespielt wird ist alles etwas einfacher, auch in der neuen Welt :wink:

Ok, das ganze ist etwas weiter hergeholt. Aber gibt mal einem heutigen Entwickler das Lastenheft, in dem steht, was so auf einem C64 tatsächlich
umgesetzt wurde und sage ihm du hast 64KB Speicher und ein 5 1/4" Laufwerk sowie eine Taktfrequenz von 0,985249 Mhz zur Verfügung.
Wer würde so einem Projekt zusagen. Ich bemängle nur, dass bei Programmentwicklungen nicht mehr oder weniger auf Recourcen geachtet wird.

Des weiteren haben wir früher Palettenstretcher ( Folienwickler ) gebaut und programmiert, mit einer einfachen 95U. Umgesetzt wurde das ganze mit vielen
Ideen zur Regelung. Heute gibt es von $S ein Applikationsbeispiel, wie man das ganz toll machen kann. Mit einer 1500ér T Baugruppe. Jetzt braucht man also
für das ganze eine T-Steuerung. Oder eine normale kleine wenn man sich eben auch mal Gedanken macht.

Vielleicht stehe ich auch alleine mit meiner Meinung.

Mit Grüßen

 

[SPS-freak1]

Stoppen Übertragen und weiter

Gesendet von meinem SM-G930F mit Tapatalk

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja genau bloß keine Änderungen und neue Elemente, deshalb ja alle Optionen von der Visu zur Laufzeit einstellbar. Dafür nehmen ich dann aber auch in Kauf das ein Ventil 40 Tags in der Visu hat und 57372 Byte im Ladespeicher brauch.

Genau der richtige Weg um riesige, aufgeblähte Monsterprogramme zu schaffen, bei denen außer dem (den) Entwickler keiner mehr durchsieht.
Das Ganze noch schön gespickt mit Pointern und Skripten, die aus der Visu im Ablaufprogramm rumhantieren, so dass Querverweise nutzlos sind, dann wird's richtig lustig.

Ich wünsche dir, dass du einmal ein Jahr bei einem kleinen Sondermaschinenbauer arbeiten musst.
Dort kannst du dann in einer Woche einen kleinen Montagetisch mit 2 Ventilen und RFID Anbindung programmieren,
in der nächsten Woche eine Maschine die Hühnereier mit einer Kamera sortiert,
und in der übernächsten Woche machst du eine Anlage mit 25 Servosachsen, Programmierstil und Antriebshersteller wird vom Kunden vorgegeben.
Da kannst du dann mal schauen wie weit du mit deinem unverrückbarem Standard kommst.

 

[ducati]

Du vergibst also innerhalb der Instanz absolute Namen (BMKs) für deine Ventile? Musst Du dann nicht von Projekt zu Projekt immer was ändern?

Unserer Programmierstil sieht anders aus wie Deiner...
Die Ventilbausteine werden nicht geändert, aber beim Aufruf der Ventilbausteine müssen ja die Eingänge, z.B. Auto versorgt werden.

Die Ventilbausteine werden bei uns in einem FB aufgerufen, Pro Ventil ein Netzwerk.
Die Logik zum Ansteuern (z.B. Auto) des Ventils befindet sich auch in diesem Netzwerk.
Für die Logik werden Stat. Variablen benötigt, für Setzen/Rücksetzten, Flankenerkennung, was auch immer... Diese befinden sich dann in einem Struct, welches z.B. Ventil1 heisst... Also Pro Netzwerk ein Struct!
Da wir eher verfahrenstechnische Sonderanlagen bauen, muss da eh immer von Projekt zu Projekt geändert werden.

Und da sich während der IB und auch später an der Logik immer was ändert, ist es notwendig im Betrieb der Anlage, zusätzliche Bools für z.B. ne Flankenerkennung mit in diese Struct einfügen zu können... Klar kann ich dafür dann auch irgend einen Speicherplatz verwenden! Ich legt mir einfach nen Merkerbereich 100-200 an, wo dann alles drinliegt, was bei der IB oder später noch notwendig geworden ist. Coole Sache.

Gruß.

 

[DeltaMikeAir]

Danke Paul,
endlich einem dem es wie mir geht, bei jeder Anlage was anderes. Bei mir ist stoppen der Steuerung im laufenden Betrieb nicht möglich.
Die Anlagen müssen laufen. Stopps und Änderungen sind am Sonntag zu machen. Vorrausplanen, was an der Sondermaschine die nächsten
Monate und Jahre umgebaut wird kann auch niemend.

Mit Grüßen

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Antwort vom Siemens-Support will ich hier auch noch mitteilen:
nachdem es einige Anläufe brauchte, bis sie meine Frage überhaupt verstanden, kam dann das hier:

außer mit Hilfe der "Speicherreserve" haben Sie keine Möglichkeit den Compiler von TIA zu überlisten den Datenbaustein nicht zu Reinitialisieren.

 

[hucki]

Sorry, OT:

Servosachsen

Die muss ich mir bei meinem nächsten Besuch im Nachbarland mal ansehen.



Schicker Vertippsler!
:s1:

 

[Mediator]

Ich bemängle nur, dass bei Programmentwicklungen nicht mehr oder weniger auf Recourcen geachtet wird.
...
Vielleicht stehe ich auch alleine mit meiner Meinung.

Mit Grüßen

Da bin ich ganz Deiner Meinung. Allerdings gibt es halt schon viele Möglichkeiten, den reichlicher als früher verfügbaren Speicher für sinnvolle oder manchmal auch unverzichtbare Zwecke zu verwenden, z.B. um Änderungen im laufenden Betrieb machen zu können.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, dem stimme ich zu.

 

[ducati]

den reichlicher als früher verfügbaren Speicher ... zu verwenden, z.B. um Änderungen im laufenden Betrieb machen zu können.

Tja, nur leider ging das früher in Classic (besser), und mit TIA nicht mehr... Also ich kann mit mehr Speicher trotzdem nicht das machen, was früher mit weniger Speicher noch funktionierte...

Oje....

 

[vollmi]

Genau wegen solcher Dinge, habe ich mir jetzt einen Baustein gebastelt, der mir einen riesigen DB im Ladespeicher anlegt. Meinen Arbeitsspeicherdb da komplett reinkopiert. Dann kann ich meinen geänderten DB laden und der Ladespeicherdb wird wieder zurückkoppiert in meinen aktuellen Arbeitsspeicherdb (in der Länge des arbeitsspeicherdbs). Man muss dann aber selber aufpassen das sich keine Adressverschiebungen ergeben haben.

Für einen 15kb DB braucht die Steuerung aber ein paar Zyklen zum sichern. Zurückschreiben mach ich automatisch indem ich auf ein Bit im ArbeitsspeicherDB schaue das 0 wird wenn der DB initialisiert wurde. Und 1 wenn der Ladespeicherdb sauber rückgelesen wurde.

mfG René

 

[Paul]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe eigentlich gedacht, mit der 1500er und "Optimierten DBs" wäre das Thema reinitialisieren vom Tisch.
Scheint aber nicht so.....

Ich habe bis jetzt mit TIA nur 300er gemacht.
Kleinere Dinger wo halt mal ein paar Zählerstände oder so was plattgemacht werden wenn man mal wieder sämtliche DBs übertragen muss.
Da habe ich ja schon öfter geschrieben, dass das für eine größere Anlage ein absolutes NO GO wäre.
Es hat dann immer geheißen, mit der 1500er und optimierten DBs ist das kein Thema mehr.

Wir habe jetzt eine große Anlage die Erste mit 1500er.
Mit mehreren (austauschbaren) Modulen, jedes eine eigene 1500er CPU, alles vernetzt
mit einem Roboter und einer echt aufwändigen Rezepturverwaltung (wegen der Modularen Bauweise).
Soll das jetzt wirklich heißen ich kann auch bei der 1500er keinen Buchstaben in einem DB ändern, ohne das der wieder plattgemacht wird ????????

Irgendwie wird mir grad schlecht........

 

[JesperMP]

Das ging früher schon nicht ohne initialisieren. [...] Ich versteh aber ehrlich gesagt auch nicht, wieso das ein codesys basierendes System hin bekommt

Bist Du sicher? Meinst Du wirklich, in Codesys-Systemen kann man FB ändern und einspielen ohne Aktualdatenverlust?

Das ist mir auch aufgefallen das bei Codesys geht angeblich "Online change mit maximalen Datenerhalt", d.h. Online Change von geänderte Deklarationen. Wenn das stimmt hat Codesys wirklich ein Vorteil.

Wie wir es macht mit Classic und in die Zukunft mit TIA:
Alles voraus so weit getestet und simuliert, das wir ein "Standard Framework" haben von Funktionsbausteine welche in der Theorie nicht geändert werden soll.
Wenn ein FB trotzdem geändert werden soll, geht das ohne Problem so lange das man den Deklarationsteil nicht ändert.
Wenn der Deklarationsteil von ein FB nicht-desto-trotz geändert werden soll, dann haben wir in jeder FB eine Menge Reserve Bits, Integers und Timers, so das wir von der Reserve unbenutzte Variabeln nehmen kann. Nur fehlt es dann die richtige Variabelnamen.
Wenn auch das nicht genug ist, es muss tatsächlich der Deklaration von ein FB erweitert werden, dann versuchen wir es in das Wartungsinterval von das Anlage reinzuschleichen. Unsere Kunden produzieren in Prinzip 24/7, aber in der Realität ist das oft 23½/6½.
Als allerletzte Abhilfe müssen wir eine reale Onlince Change im laufender Betrieb durchführen, mit aufwendigen kopieren hin-und-her von die Instanzdaten zwischen alte und neue Funktionsbausteine. Das ist aber äusserst selten.

 

[miasma]

Genau der richtige Weg um riesige, aufgeblähte Monsterprogramme zu schaffen, bei denen außer dem (den) Entwickler keiner mehr durchsieht.
Das Ganze noch schön gespickt mit Pointern und Skripten, die aus der Visu im Ablaufprogramm rumhantieren, so dass Querverweise nutzlos sind, dann wird's richtig lustig.

Ich wünsche dir, dass du einmal ein Jahr bei einem kleinen Sondermaschinenbauer arbeiten musst.
Dort kannst du dann in einer Woche einen kleinen Montagetisch mit 2 Ventilen und RFID Anbindung programmieren,
in der nächsten Woche eine Maschine die Hühnereier mit einer Kamera sortiert,
und in der übernächsten Woche machst du eine Anlage mit 25 Servosachsen, Programmierstil und Antriebshersteller wird vom Kunden vorgegeben.
Da kannst du dann mal schauen wie weit du mit deinem unverrückbarem Standard kommst.

Ich arbeite seit 10 Jahren in Sondermaschinenbau und bin mit meiner Bibliothek immer gut gefahren.
Die ist dokumentiert und wurde auch schon öfter durch 3. in Betrieb genommen, weil eben keine Pointer, Skripte oder andere unsichtbare Überraschungen vorhanden sind.
Wieso muss denn immer der individuelle Programmierstil der bessere sein bzw. sinnvollere sein?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Soll das jetzt wirklich heißen ich kann auch bei der 1500er keinen Buchstaben in einem DB ändern, ohne das der wieder plattgemacht wird ????????

Jo, genau so ist es !!!! Im Prinzip schlechter als bei 300er mit Classic.

Gruß

 

[ducati]

Es hat dann immer geheißen, mit der 1500er und optimierten DBs ist das kein Thema mehr.

Die Marketingaussagen von Siemens zum TIA kann man im Prinzip einfach negieren ...

 

[rostiger Nagel]

Die Marketingaussagen von Siemens zum TIA kann man im Prinzip einfach negieren ...

sage ich doch schon seit Jahren:

"Automatisieren Sie mit TIA in Fünf Minuten, was früher nur eine gedauert hat"

Der Multiplikator ist immer 5, gleich bei kleinen oder großen Projekten.