Nachträglich Variablen in DB einfügen

s3amdrer

Level-1
Beiträge
210
Reaktionspunkte
17
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo alle zusammen.

Ich schreibe gerade ein Programm für eine Maschine mit 4 Unterstationen.
Es ist ein "DBX_HMI" für alle Stationen vorhanden. Da ich nun immer mal neue Variablen in diesen DB einfügen muss, möchte ich dies im DB an bestimmter (sinnvoller) Stelle durchführen.

Z.B. 10 Variablen sind im DB bereits vorhanden und an Stelle 5 (wegen der besseren Übersichtlichkeit) möchte ich eine neue Variable einfügen, ohne das sich das bereits programmierte Programm verändert.

Habe im Moment das Problem, das nach dem Einfügen einer neuen Variablen, die Variablen sich im bereits programmierten Programm verschieben.

Ist das Einstellungssache oder geht das nicht?
 
rechter Mausklick auf Bausteine-Ordner > Objekteigenschaften > Operandenvorrang > (x) Symbol hat Vorrang
Für detaillierte Erklärungen in dem Dialog [Hilfe] aufrufen.

Oder für Änderungen aus den betroffenen Bausteinen eine AWL-Quelle generieren und die DB-Änderungen in der AWL-Quelle vornehmen.

Gruß
Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
rechter Mausklick auf Bausteine-Ordner > Objekteigenschaften > Operandenvorrang > (x) Symbol hat Vorrang
Für detaillierte Erklärungen in dem Dialog [Hilfe] aufrufen.

Oder für Änderungen aus den betroffenen Bausteinen eine AWL-Quelle generieren und die DB-Änderungen in der AWL-Quelle vornehmen.

Gruß
Harald

Er muss nur beachten, das er dann alle FCs in denen Werte aus dem Datenbaustein verwendet werden neu übertragen muss, und nicht nur den DB!
 
Da ich fast immer Änderungen an laufenden Anlagen ohne CPU-STOP vornehmen muß, nutze ich den Symbol-Vorrang nicht.
Wenn tatsächlich mal Verschiebungen der DB-Adressen nötig sind, dann mache ich die Anpassungen manuell oder über
die AWL-Quelle. Das Laden ALLER betroffenen/geänderten Bausteine in die CPU ohne STOP erfordert dann immer ein
individuelles planvolles Vorgehen. Das überlasse ich nicht irgendwelchen Step7-Automatiken.
Mit anderen Worten: Mit dem "Symbol-Vorrang" habe ich keine ausreichenden Erfahrungen.

Gruß
Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich verwende ausschlieslich Symbolisches Adressen-Priorität.
Aber ich benötige auch das Programmänderungen in RUN durchgeführt werden kann.
Es bedeutet das wenn ich den grossen Anteil von meine Projekte erstelle, dann programmiere ich nur offline, und verwende regelmässig den Funktion "Block Konzistenz überprüfen" um alles Sauber zu halten.
Wenn das Projekt ist in Betrieb bei den End-Kunde, kann ich auch Programmänderungen in RUN machen, nur ist es nicht ohne weitere erlaubt Änderungen in die Deklarationen von UDTs, FBs, und FCs zu machen (*). Den Code-Teil kann man ändern ohne Probleme.

*: Es ist möglich, aber nur mit Vorsicht, und es bedeutet mehr Aufwand.
 
Ich verwende ausschlieslich Symbolisches Adressen-Priorität.
Aber ich benötige auch das Programmänderungen in RUN durchgeführt werden kann.
Das mache ich auch so.
Es kommt auch hin und wieder vor das ich die Datenstruktur zur Laufzeit ändern muss.
Konsistenzprüfung > Vergleichen > geänderte Bausteine übertragen.
Wichtig 1:
Beim übertragen der Bausteine ist aber die Reihenfolge sehr entscheidend:
Erst Datenbausteine ; dann Bausteine ; dann Bausteinaufrufe.

Wichtig 2 (Erfahrungsbericht):
Ich hatte jetzt aber schon zweimal schlechte Erfahrung mit der neuen 315-2DP (6ES7-315-2AH14),
und zwar wenn es zu viele Bausteine sind die ich zur Laufzeit übertragen will, ca. 40, dann gehen bei der CPU alle 6 Lichter an und sie ist "TOT".
"Rien ne va plus" Nichts geht mehr, ein Urlöschen ist angesagt.

Aber wie gesagt nur bei vielen Bausteinen, bei "weniger" ist das auch kein Problem.
Leider habe ich keine genau Zahl, wird wahrscheinlich auch auf die Bausteingröße ankommen.
 
OK danke für die Tipps.

Hab schon was umgestellt. Mal sehen wie ich damit so zurecht kommen.

Wenn Ihr in irgendwelchen DB's Variablen ergänzen müsst, deklariert Ihr die neuen Variablen einfach am DB Ende dran, auch wenn das unübersichtlich scheint?
 
Wenn dir schon klar ist, dass du in Zukunft Variablen einfügen wirst, warum legst du dann keine Platzhalter in deinem DB an?
Lg Gerhard

Mache ich für meinen OP/HMI DB auch immer so, eine Menge Bool, Int, dInt und Real Variablen auf Reserve.

Das hat auch den Vorteil das man den DB bei Änderungen nicht neu auf die SPS übertragen muss und somit die Aktualwerte erhalten bleiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum denn das? :confused:
Ein Array mit n Bytes reicht doch auch. Du kannst dann ja beim Erweitern entscheiden, was daraus werden soll.


Ist bei uns auch so, der Nachteil wenn du ein Array anlegt und nachträglich die Datentypen änderst kannst du den Datenbaustein online nicht mehr anschauen ohne einzuspielen.
 
Warum denn das? :confused:
Ein Array mit n Bytes reicht doch auch. Du kannst dann ja beim Erweitern entscheiden, was daraus werden soll.

Dann fängt immer das rechnen an, ich habe 2 Bool, 1 real und 3 Int hinzugefügt ... :roll:
Und wenn dann noch das Reserve Array in der Mitte des DBs ist.
Ich finde das so am praktikabelsten

Diese ganzen Reserve Variablen bleiben eine Krüge, egal wie man es löst.
 
Zurück
Oben