escride1
Level-1
- Beiträge
- 1.110
- Reaktionspunkte
- 262
-> Hier kostenlos registrieren
Beim FB/DB einfach mit Einstellwerten arbeiten und das Thema ist passé.
TIA S7-1500 nicht optimierten DB laden ohne Stopp
- Ersteller MaurerT
- Erstellt am
-> Hier kostenlos registrieren
und wie sieht dann das Vorgehen aus, wenn man zwar mit der Sicherung eines DBs arbeitet, diesen dann modifiziert, am Programm arbeitet und bis zur Inbetriebnahme des Ganzen eine gewisse Zeit vergangen ist, sprich man wieder die neueren Aktualwerte aus dem Online DB im jetzt modifizierten DB benötigt? Da hilft ja dann nur noch händisch hineinkopieren. Ein "automatischer" Abgleich, in wie vielen einzelnen Schritten er auch immer ausgeführt werden müsste, kann jetzt ja aufgrund der geänderten Struktur nicht mehr stattfinden.
Ein weiteres generelles Problem was ich habe ist das Arbeiten mit globalen Variablen in einem DB. Was früher Merker waren, sind heute in einem DB. Eine neue globale Variable hinzufügen bedeutet, selbst wenn man vor Ort ist, die Anlage steht und die Sicherungsthematik hier kein Problem ist, dass aufgrund der projektweiten Referenzen bis ins F-Programm die CPU kurz in den Stop muss. Sehr ärgerlich.
Ein weiteres generelles Problem was ich habe ist das Arbeiten mit globalen Variablen in einem DB. Was früher Merker waren, sind heute in einem DB. Eine neue globale Variable hinzufügen bedeutet, selbst wenn man vor Ort ist, die Anlage steht und die Sicherungsthematik hier kein Problem ist, dass aufgrund der projektweiten Referenzen bis ins F-Programm die CPU kurz in den Stop muss. Sehr ärgerlich.
escride1
Level-1
- Beiträge
- 1.110
- Reaktionspunkte
- 262
-> Hier kostenlos registrieren
Man kann es sich auch schwer machen oder Gründe suchen.
Büroarbeit:
- Kopiere Deinen DB 2 mal
- Ändere am neu erstellten, also der Kopie, den Variablennamen, füge neue hinzu, füge welche ein.
Baustelle:
- Gehe online
- Momentaufnahme des alten DB erstellen, kopieren und in die Startwerte des veränderten, darauf aufpassen das bei eingefügten oder entfernten Variablen die Struktur stimmt, entsprechend öfter kopieren bei eingefügten Variablen.
- Gehe offline
- Lösche alten DB
- Benenne geänderten so um das er anstelle des alten tritt: Umbennenen und _1 entfernen
- Gehe online
- Laden und übersetzen
- Startwerte vom 2. kopierten in den DB kopieren
- Lösche 2. Kopie
- Laden und übersetzen
Es kommt gar nicht dazu das Momentaufnahmen sich ändern wenn man nicht gerade Zeiten oder andere sich verändernde Werte im DB hat, da die Momentaufnahme ja vor Ort erstellt wird. Nach den Änderungen, vor dem Laden.
Den Stillstand kann man wie beschrieben umgehen. Wenn ich einen Stillstand hinnehmen kann muss ich auch nicht den Weg nutzen und kann einfach alles umschreiben und die Anlage von vorne neu anlaufen lassen.
Und wenn man nicht bis ins F-Programm referenziert, dann kommt auch das auch hier nicht vor. Schließlich trennt man das ja auch strikt voneinander. Sollten sich aber die DBs ändern die im F-Teil mir referenziert werden dann kommt man eben nicht um den Stop herum. War das mal anders?
Was heißt hier sich schwer machen oder Gründe suchen? Das was du beschreibst ist doch schlussendlich das händische Kopieren von Werten, was ich eben angesprochen habe. Das muss nicht, kann aber fehleranfällig sein. Selbst wenn in einer Struktur nur unten eine neues Element angeflanscht wurde, erkennt TIA nicht mehr, dass der Rest konsistent geblieben ist. Das ist sehr unschön. Natürlich mache ich das Übernehmen von aktuellen Werten so bzw so ähnlich wie du es beschreibst, das Vorgehen will ich auch gar nicht bemängeln , aber Kritik am Datenhandling seitens TIA wird ja wohl erlaubt sein, schließlich handelt es sich hier um Vorgänge die nicht so selten durchgeführt werden müssen.
Die Anzahl der Schritte PRO DB machen es aber per Definition zu einer "KRÜCKE" ....
- Beiträge
- 21.961
- Reaktionspunkte
- 6.835
-> Hier kostenlos registrieren
... und es funktioniert nur mit DB wo sich die Werte zwischen Momentaufnahme und neu einspielen nicht ändern. Was wenn in dem DB z.B. eine Schrittkette liegt?
Soll womöglich bei jedem DB erst für jede Variable untersucht werden, ob sie sich vielleicht irgendwann ändert?
Harald
Soll womöglich bei jedem DB erst für jede Variable untersucht werden, ob sie sich vielleicht irgendwann ändert?
Harald
escride1
Level-1
- Beiträge
- 1.110
- Reaktionspunkte
- 262
Speicherreserve aktivieren -> Variablen hinzufügen -> Laden -> fertig.
Das hinzufügen ist gar kein Problem. Nur das ändern der Struktur und Variablennamen macht die Schritte erforderlich.
Klar kannst Du das. Ich sehe nur das Problem nicht, erklär mir deutlich wo das Problem am Datenhandling sein soll, denn egal wie ich versuche darüber nachzudenken oder was auch immer ich programmiere, ich komme nicht in eine Problemstellung das es unumgehbare Stillstände gibt (wenn wir jetzt mal von Hardwareänderungen, Safety,... absehen und nur beim "normalen" Programm bleiben).
Wenn man sehr viel ändert - ja. Aber es geht letzten Endes ja darum etwas ändern zu können. Es geht immer komfortabler. Die Schritte lesen sich auch nach viel, sind allerdings nur wenige Steps die in kurzer Zeit durch sind. Kommt halt auf die Änderungen an.
Ja, das ist richtig. Aber wie soll man das lösen durch die Programmiersoftware? Welche Intelligenz muss in einer Programmiersoftware sein die erkennen muss das an dem DB Offset, Name und Datentyp verändert wurden und das richtig zuordnen muss.
Wie macht Ihr das denn jetzt? Wie ändert ihr einen DB mit sich ändernden Werten in Länge, Struktur und Offsets zur Laufzeit ohne Stop? Alles durch Knopfdruck in Classic/CodeSys/TwinCat/...? Wer macht es aktuell besser und wie?
Ich bin gerne bereit mir von Euch anzuhören(lesen) wo es besser läuft, gerne nehme ich auch eine Problemstellung an, also einer erklärt was er ändern will und dann sehe ich - oh, das meint er, das geht natürlich nicht oder nur "sch...". Aber ich sehe es echt nicht wo bei kleinen vorzubereitenden Änderungen im Büro das Problem ist. Oder reden wir hier von 500.000 Änderungen und anstelle einer Förderstrecke haben wir nun ein Atomkraftwerk?
Mit den Programmen (mehr fremde wie eigene, da mein Kerngebiet darin liegt Fremdanlagen in Wartung und Service zu übernehmen, erweitern und optimieren) mit denen ich in den letzten Jahren konfrontiert wurde hatte ich nie unlösbare Probleme, nur richtig umständliche Lösungen aufgrund der Programmiersoftware, aber seit TIA V13 ist für mich alles bedeutend einfacher geworden in der Siemens-Welt, da einfach sehr viel gemacht wurde.
Meine große Problematik besteht eher darin was AWL-Coder hinterlassen. Die tippen manchmal einen ganzen Haufen Mist ein, kommentieren nada und glauben das sei ein super wartbares Programm. Die schreiben auch heute noch alles in AWL statt in SCL weil sie glauben es sei übersichtlicher bei der Fehlersuche, ist es nur leider aber nicht wenn man einmal raus hat was man beobachten muss.
Insgesamt finde ich einiges bei anderen Herstellern sehr viel umständlicher.
Für diesen Threadtitel ist aber das eigentliche Problem gelöst oder sehe ich es falsch? Ein DB, nichtoptimiert, sollte ohne Stop/Reinit geändert werden. "Einer". (Will hier nicht abwürgen, wir können gerne weiter schreiben.)
Bin für heute aber nimmer da, gleich noch Essen und dann muss ich zur nächtlichen Anlagenänderung (darf beim aktuellen Projekt nur in der Nachtschicht die Anlage auseinanderbauen ^^).
Bis denn
Eben nicht. Die Speicherreserve (übrigens eine hervorragende Bezeichnung von Siemens...) ist Murks. Die gewünschte Funktionalität greift nicht bei Elementen innerhalb eines Structs. Also (fast) unbrauchbar.
Vielleicht bin ich da etwas eigen, aber ich sehe den händischen Abgleich von ganzen DBs bei der hier mehrfach angesprochenen Thematik als Problem. Man möge mir das verzeihen. Und nein, ich erwarte nicht dass das Ganze funktioniert, wenn der DB komplett umgeschrieben wird. Das ist nicht das Thema.
Zuletzt bearbeitet:
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
-> Hier kostenlos registrieren
ich hab aufgegeben zu Hoffen, dass Siemens das Problem löst... Wie man ja hier in der Diskussion sieht, versteht wahrscheinlich auch Siemens das Problem mit dem Reinitialisieren garnicht...
Und optimierte DBs sind der Murks schlechthin.
Und die Speicherreserve ist der Oberwitz... Man kann am Ende Variablen hinzufügen, toll
Aber bestehende Variablen kann man nicht umbenennen
Eigentlich gehts einfach nur, wenn man wirklich Merker für alles verwendet.
Der RettungsDB den wir verwenden, funktioniert eigentlich auch nur zum Ändern von Variablennamen... Aber immerhin... Nur Sicher ist das ganze nicht, falls z.B. jemand aus Versehen ne Variable mitendrinn hinzugefügt hat...
Grundsätzlich könnte man die Variablen einfach durchnummerieren, also bool1 bool2 usw. Die Bedeutung dann im Kommentar eintragen und genügend Reserven vorsehen... Dann gibts auch kein Reinitialisieren... Aber Symbolisch ist das dann nicht wirklich.
Also ingesamt ein riesen Rückschritt zur S7-300/400 und eigentlich ein nogo für die S7-1500 in der Prozessautomatisierung....
Gruß.
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
echt coole Vorgehensweise um einen Tippfehler in nem Variablennamen zu korrigieren...
Ich denke mit TIA dauert das Programmieren der ganzen Anlage nur 5min...
Ohjeeee
Diese Vorgehensweise wär mir auch viel zu heiß an ner Anlage die produktionsrelevant ist und bei nem Ausfall mehrere zig tausend Euro Schaden verursacht...
Das ist das Problem von allen händischen Rettungsvarianten, viel zu umständlich und fehleranfällig...
Zuletzt bearbeitet:
- Beiträge
- 9.711
- Reaktionspunkte
- 2.787
und wenn in dem DB Bool Werte sind, die im Programm gesetzt bzw. Rückgesetzt werden oder z.B. Variablen die hochzählen, dann kannst die Momentaufnahme komplett vergessen...
Ente
Ente
- Beiträge
- 8.328
- Reaktionspunkte
- 1.898
-> Hier kostenlos registrieren
Mir wäre es genug wenn es 'anwendbar' ist. Es braucht nicht perfekt zu sein.
Z.B:
Bestehende Variabeln, Name, Startwert oder Aktualwert ändern. Typ darf nicht geändert werden.
Bestehende Variabeln dürfen nicht gelöscht oder verschoben werden.
Neue Variabeln kann 'am unten' nach die bestehende Variabeln eingefügt werden.
Damit konnte ich absolut leben. Das sollte für die TIA Pogrammierer machbar sein.
Z.B:
Bestehende Variabeln, Name, Startwert oder Aktualwert ändern. Typ darf nicht geändert werden.
Bestehende Variabeln dürfen nicht gelöscht oder verschoben werden.
Neue Variabeln kann 'am unten' nach die bestehende Variabeln eingefügt werden.
Damit konnte ich absolut leben. Das sollte für die TIA Pogrammierer machbar sein.
skorpion37
Level-2
- Beiträge
- 159
- Reaktionspunkte
- 54
Ja. So einfach könnte es sein.
Klar, muss natürlich sauber programmiert werden und kostet auch Zeit und Geld. Das scheint aber vorhanden zu sein um eine Funktion wie "Speicherplatzreserven" zu programmieren.
Ich habe mir das mit den "Speicherplatzreserven" auch tatsächlich wohlwollend angeschaut. Macht sich auf der Siemenes Powerpoint ja echt super. Für die Praxis habe ich aber leider nur ein Minenfeld aus Stolpersteinen und Limitierungen gefunden. Das Grundproblem hierbei ist, dass man beim Erstellen der Software festlegen muss, wie viel Speicherreserve man in welchen Bausteinen für die in 5 Jahren kommende Änderung braucht. Wobei man natürlich berücksichtigen muss, dass kleinere Änderungen in den Jahren dazwischen auch die Reserven aufbrauchen. Wer hat sich so einen Quatsch aus dem Kopf gedrückt???
Da sind die altbekannten Krücken für die Praxis leider immer noch die einzige Wahl.
Manchmal hat man den Eindruck, dass die primären Kunden der Entwicklung die 5 min Youtube Showcase Programmier sind...
Offtopic: Warum kann sich TIA keine Multiuserverser Passwörter merken? Warum kann sich TIA im Commissioning Mode keine CPU-Passwörter merken. Kostet viele, viele Stunden...
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Als die neuen CPU heraus kamen mit den ersten Artikeln zu dieser "optimierten Datenablage" dachte ich ja, das ist genau dafür da um bei Programmänderungen die Aktualwerte behalten zu können.
Ich meine, wenn die Programmiersoftware und die CPU schon im Hintergrund für die Speicherverwaltung sorgt, dann sollte sie auch in der Lage sein die Aktualwerte zu behalten. Andernfalls habe ich als Anwender überhaupt keinen Vorteil davon. Wenn ich eine neue Variable anlege, dann wird für diese eben irgendwo im verfügbaren Speicher entsprechend Platz reserviert, warum muss das auch alle anderen Variablen betreffen? Das ergibt überhaupt keinen Sinn dann andere Variablenwerte zurückzusetzen, vor allem auch nur durch eine Änderung des Bezeichners.
Das einzige was sich durch so eine Speicherverwaltung mit dem Laufe der Zeit ergibt, ist eine Fragmentierung des Speichers. Aber die größte 1500er CPU hat 4 MByte Code und 20 MByte Daten, wenn ich in die CPU 200 MByte für Daten für diese dynamische Verwaltung zur Verfügung habe, dann muss ich schon viele Änderungen vornehmen damit dieser Platz gefüllt ist. Zudem könnte die CPU im Hintergrund in kleinen Stücken defragmentieren. Ist alles nicht ganz einfach, aber dafür bezahlt man Siemens den Krams schließlich auch.
Das hat mich früher bei Codesys immer genervt, dass man keine Kontrolle darüber hat wann Werte zurückgesetzt werden. Ich meine das funktioniert bei Codesys aber mittlerweile zuverlässiger als bei den neuen Siemens 1200/1500er Steuerungen.
Ich meine, wenn die Programmiersoftware und die CPU schon im Hintergrund für die Speicherverwaltung sorgt, dann sollte sie auch in der Lage sein die Aktualwerte zu behalten. Andernfalls habe ich als Anwender überhaupt keinen Vorteil davon. Wenn ich eine neue Variable anlege, dann wird für diese eben irgendwo im verfügbaren Speicher entsprechend Platz reserviert, warum muss das auch alle anderen Variablen betreffen? Das ergibt überhaupt keinen Sinn dann andere Variablenwerte zurückzusetzen, vor allem auch nur durch eine Änderung des Bezeichners.
Das einzige was sich durch so eine Speicherverwaltung mit dem Laufe der Zeit ergibt, ist eine Fragmentierung des Speichers. Aber die größte 1500er CPU hat 4 MByte Code und 20 MByte Daten, wenn ich in die CPU 200 MByte für Daten für diese dynamische Verwaltung zur Verfügung habe, dann muss ich schon viele Änderungen vornehmen damit dieser Platz gefüllt ist. Zudem könnte die CPU im Hintergrund in kleinen Stücken defragmentieren. Ist alles nicht ganz einfach, aber dafür bezahlt man Siemens den Krams schließlich auch.
Das hat mich früher bei Codesys immer genervt, dass man keine Kontrolle darüber hat wann Werte zurückgesetzt werden. Ich meine das funktioniert bei Codesys aber mittlerweile zuverlässiger als bei den neuen Siemens 1200/1500er Steuerungen.
-> Hier kostenlos registrieren
Bei TC2 ging das ja auch schon. Variable hinzufügen, OnlineChange machen und alles läuft weiter. Bei TC3 geht das eigentlich auch problemlos.
Ich denke mal, SIEMENS ist einfach noch nicht so weit, wie die anderen. Da helfen auch die Krücken wie Speicherreserve nicht, die man dann auch noch händisch aktivieren muss.
Am Anfang wollte ich es eigentlich nicht glauben, aber inzwischen glaube ich immer mehr, dass im TIA-Portal im Hintergrund doch ganz viele alte Systeme laufen und dass das Vollsymbolische nur übergestülpt ist.
Und deshalb funktionieren diese Sachen, wie sie dieser Thread beschreibt, nicht gut. Da ist zu viel altes mit zu viel neuem vermischt, alles soll kompatibel sein, alte Zöpfe wurden nicht konsequent abgeschnitten. Das tut einer Software einfach nicht gut. Am Ende ist keiner zufrieden.
Ich denke mal, SIEMENS ist einfach noch nicht so weit, wie die anderen. Da helfen auch die Krücken wie Speicherreserve nicht, die man dann auch noch händisch aktivieren muss.
Am Anfang wollte ich es eigentlich nicht glauben, aber inzwischen glaube ich immer mehr, dass im TIA-Portal im Hintergrund doch ganz viele alte Systeme laufen und dass das Vollsymbolische nur übergestülpt ist.
- Die Sache mit den Nummer, die überall immer wieder auftauchen
- Die Instanz-DBs, die immer angelegt werden und niemand weiß, wofür die sichtbar sind
- die komische Unterscheidung in "optimierte" und nicht-optimierte DBs, die ich bis heute nicht verstehe
Und deshalb funktionieren diese Sachen, wie sie dieser Thread beschreibt, nicht gut. Da ist zu viel altes mit zu viel neuem vermischt, alles soll kompatibel sein, alte Zöpfe wurden nicht konsequent abgeschnitten. Das tut einer Software einfach nicht gut. Am Ende ist keiner zufrieden.
Leute, was erwartet ihr?
Wie sind doch im Zeitalter von Industrie 4.0 und da ist doch aus bei der Ausschreibungsphase eines Projektes die Funktion der Steuerung schon klar, wie Aufgabe ist es doch lediglich, das ganze noch hinein zu tippen. Was ihr zu tippen habt ist ohnehin im Pflichtenheft definiert, wieso wollt ihr an euren Programmen an der laufenden Anlage noch was verändern?
In den automotiven Standards wie Integra, Powertrain, Vass usw. sind fix und fertige Bausteine für alles drinnen, die braucht ihr doch nur zusammenzusetzen und die ganze Anlage läuft. Da gibt's dann sogar eine fertige Dokumentation von Siemens dazu.....
OK, Sarkasmus aus!
Leider entwickelt Siemens im Bereich SPSen viel zu sehr auf Zuruf einiger großer Automobilisten, und technische Entscheidungsträger haben leider nicht mehr praktische Erfahrung als einen VASS-Kurs oder so. Dann gibt's noch in der Industrie so wahnwitzige Standards wie Powertrain, welche auf einer Architektur aufsetzen, die aus den 1990er Jahren ist. Wenn dann Siemens sowas wie optimierte DBs und ein System ohne AWL auf den Markt bringt, welches es erfordern würde, solche Standards anzupassen, übt man als Automobilist schon mal Druck aus und droht sogar Siemens mit Rauswurf.... Dann können leider wieder solche Konstrukte raus wie es halt die S7-1500 jetzt ist.
Meiner Meinung nach ist einer der Hauptgründe, warum so viele Programmierer mit dem Tia-Portal so kämpfen, ist, daß sie selbst nicht bereit sind, alle Zöpfe abzuschneiden. Ich selbst habe 2015 damit begonnen, alte Software auf S7-1500 zu portieren, und dabei haben natürlich meine Rockwell Studio 5000 und B&R Automation Studio Erfahrungen sehr geholfen. Beide Systeme kennen nur noch eine offene Speicherarchitektur und haben so ihre Schwächen mit der Datenhaltung, wenn man an der laufenden Anlage was ändern muss. Das hat dazu geführt, dass ihr mir bei jeder abwegig zuerst mal Gedanken über die Datenhaltung gemacht habe, und das bei der Programmportierung mit betrachtet habe. Mir ist klar das es wahnsinnig lästig ist, wenn man plötzlich nicht mehr in jedem x-beliebigen DB Einstelldaten, remanente Daten und Ablaufdaten mischen kann, auch wenn es das TIA-Portal mit seinen optimierten DBs suggeriert.
Mir ist auch bewusst, dass nicht jeder Programmierer es schafft, seine über Jahre zusammengebastelten Standards auf eine neue Architektur zu portieren.
Was ich damit sagen will: Ich bin mit dem TIA-Portal als Entwicklungsumgebung sehr zufrieden. Wenn man bereit ist, seine Arbeitsweise umzustellen und seinen Code an die Architektur anpasst dann kann man damit eigentlich alles machen, was in classic auch machbar war. Leider machen das nicht viele...
Wie sind doch im Zeitalter von Industrie 4.0 und da ist doch aus bei der Ausschreibungsphase eines Projektes die Funktion der Steuerung schon klar, wie Aufgabe ist es doch lediglich, das ganze noch hinein zu tippen. Was ihr zu tippen habt ist ohnehin im Pflichtenheft definiert, wieso wollt ihr an euren Programmen an der laufenden Anlage noch was verändern?
In den automotiven Standards wie Integra, Powertrain, Vass usw. sind fix und fertige Bausteine für alles drinnen, die braucht ihr doch nur zusammenzusetzen und die ganze Anlage läuft. Da gibt's dann sogar eine fertige Dokumentation von Siemens dazu.....
OK, Sarkasmus aus!
Leider entwickelt Siemens im Bereich SPSen viel zu sehr auf Zuruf einiger großer Automobilisten, und technische Entscheidungsträger haben leider nicht mehr praktische Erfahrung als einen VASS-Kurs oder so. Dann gibt's noch in der Industrie so wahnwitzige Standards wie Powertrain, welche auf einer Architektur aufsetzen, die aus den 1990er Jahren ist. Wenn dann Siemens sowas wie optimierte DBs und ein System ohne AWL auf den Markt bringt, welches es erfordern würde, solche Standards anzupassen, übt man als Automobilist schon mal Druck aus und droht sogar Siemens mit Rauswurf.... Dann können leider wieder solche Konstrukte raus wie es halt die S7-1500 jetzt ist.
Meiner Meinung nach ist einer der Hauptgründe, warum so viele Programmierer mit dem Tia-Portal so kämpfen, ist, daß sie selbst nicht bereit sind, alle Zöpfe abzuschneiden. Ich selbst habe 2015 damit begonnen, alte Software auf S7-1500 zu portieren, und dabei haben natürlich meine Rockwell Studio 5000 und B&R Automation Studio Erfahrungen sehr geholfen. Beide Systeme kennen nur noch eine offene Speicherarchitektur und haben so ihre Schwächen mit der Datenhaltung, wenn man an der laufenden Anlage was ändern muss. Das hat dazu geführt, dass ihr mir bei jeder abwegig zuerst mal Gedanken über die Datenhaltung gemacht habe, und das bei der Programmportierung mit betrachtet habe. Mir ist klar das es wahnsinnig lästig ist, wenn man plötzlich nicht mehr in jedem x-beliebigen DB Einstelldaten, remanente Daten und Ablaufdaten mischen kann, auch wenn es das TIA-Portal mit seinen optimierten DBs suggeriert.
Mir ist auch bewusst, dass nicht jeder Programmierer es schafft, seine über Jahre zusammengebastelten Standards auf eine neue Architektur zu portieren.
Was ich damit sagen will: Ich bin mit dem TIA-Portal als Entwicklungsumgebung sehr zufrieden. Wenn man bereit ist, seine Arbeitsweise umzustellen und seinen Code an die Architektur anpasst dann kann man damit eigentlich alles machen, was in classic auch machbar war. Leider machen das nicht viele...
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Zu Step7-300/400 Zeiten hatte ich z.B. für Antriebe diverse DBs, einen für Befehle, für Befehlsrückmeldungen, für Meldungen, für Sollwerte. Ich wollte bei TIA davon eigentlich weg weil es unnötig aufwändig ist, darum habe ich alles was zu einem Antrieb o.Ä. gehört in eine UDT gepackt. Das macht viele Dinge bei der Programmierung schneller und einfacher. Auch die HMI-Erstellung ist viel komfortabler. Identisches HMI-UDT erstellen, Bildbaustein für den Typ, Bildbaustein instanziieren und mit UDT verschalten, fertig. Das hat mir bei TIA dann doch sehr gut gefallen, weil ich auch ohne automatische Codegenerierung händisch sehr schnell ein Programm und HMI in der Grundstruktur erstellen kann.
Bis man dann auf die Nachteile stößt, und erkennt, dass man aufgrund der Probleme mit dem bisherigen Classic-Verfahren sogar besser fahren würde.
-> Hier kostenlos registrieren
Um auf die eigentliche Fragestellung einzugehen:
Ein Stopp einer S7-1500, wenn man einen DB geändert hat tritt nach meiner Erfahrung nur in 2 Situationen auf:
1. die Programmänderung ist so groß, dass sie im Speicher nicht Platz hat. Das tritt vor allem dann auf wenn der Speicher ohnehin schon knapp ist oder wenn auf den DB so viele Bausteine zugreifen, das faktisch die halbe Steuerung neu geladen wird.
2. auf den DB greift das Sicherheitsprogramm zu.
Die Funktion "Laden ohne Reinitialisierung" und das Thema Speicherreserve ist in der Hilfe sehr detailliert beschrieben und man sollte sich die Funktion sehr genau ansehen und bevor man sowas "auf Verdacht" einsetzt.
Du hast leider das Problem, dass du jetzt grade wo nacharbeiten musst, was von der Architektur her schlampig aufgezogen ist. Schnell mal Änderungen machen und eine Kleinigkeit unterschieben ist mir modernen Systemen immer mit Schmerzen verbunden....
Wir hatten in der Classic-Welt die Geschichte mit einem UDT, in dem für einen Antrieb alles drinnen ist, je in DB, Bildbaustein mit DB-Multiplex usw.
In der optimierten Tia-Welt wurde das alles auf eine Vielzahl von UDTs aufgeteilt, verschachtelte UDTs, viele kleine Hilfsfunktionen, aber nur 4 DBs für alle Antriebe gemeinsam.
Für das HMI gibt's einen UDT (der dann ein Bibliotheks-Typ ist) und einen Mapping-FB, der pro HMI aufgerufen werden muss sowie einen Bildbaustein.
In der PLC kann man somit weiter schalten und walten und muss ggf. nur den Mapper anpassen....
Sorry aber die Diskussion hat doch mit all dem was du schreibst gar nichts zu tun. Du bringst das auf eine Ebene, als ob die hier beschriebenen Probleme mit zusammengebasteltem altem Code zu tun haben, von Programmierern die zu dumm sind die neue Architektur zu verstehen. Das ist doch Blödsinn.
