Was passiert eigentlich, wenn Du den DB aus dem Arbeitsspeicher in den Ladespeicher kopierst unter einer Nummer, welche es im Projekt nicht gibt? (also den DB nicht im Projekt anlegen und nicht in den Ladespeicher laden). Geht das überhaupt?
Gibt es bei der S7-1200 nicht auch eine Möglichkeit, Data Logs oder Rezepte auf die MMC zu schreiben und vielleicht sogar wieder zurückzulesen?
Harald
Leider muss man immer eine Momentaufnahme machen und dann als Startwert kopieren. Habe das S. schon in der V11 mitgeteilt, dass das konsistent Laden oft gar nicht zielführend ist. Online nach Offline kopieren gibt es auch nicht mehr. Und beim Laden einen Baustein abwählen geht auch nicht, obwohl es ja im Lade Dialog möglich wäre, nur ist dann der Lade Button deaktiviert.
Denen braucht man nichts mitzuteilen, wir interessieren die nicht.
Ich denke mal, Siemens wird sich in den nächsten Jahren, wie so viele Andere, "dem Kerngeschäft zuwenden"!
Dann stampfen die den SPS-Bereich ein, macht eh Sinn, wenn die weiter solchen Schrott an ihre Kunden (wir???) ausliefern.
Denen braucht man nichts mitzuteilen, wir interessieren die nicht.
... sag mal Ralle, ist das Dein Hobby täglich abzulästern, oder spekulierst Du auf einen hochdotieren Beratervertrag bei BigS?
Hi all
wenn du mit WRIT_DBL den Ladespeicher eines DB änderst, dann ist der DB geändert. Damit bleibt einem On-Off-Vergleich gar nix anderes übrig, als den Baustein als unterschiedlich zu markieren. Das stört erst, wenn du jetzt einen anderen Baustein laden musst, denn das TIA-Portal will ja immer mit aller Gewalt alles konsistent machen.
Bevor du den anderen Baustein auf die CPU schickst, muss man den geänderten ins Projekt holen. Danach, kannst du den anderen auf die CPU laden ohne, dass deine Startwerte verloren gehen.
Glücklich macht mich das auch nicht.
Schlimmer noch, der DB wächst in der Größe an und zwar drastisch! Im meinem DB ist ein Array of UDTsoundso. Ich habe keine Startwerte gesetzt. Der DB benötigt etwa 120kB Ladespeicher. Werden nun durch das Programm Werte geändert und ich lade dann den DB wieder zurück in das Projekt, dann braucht er plötzlich 800kB Ladespeicher :-(
Je mehr ich das Array fülle desto mehr Ladespeicher braucht der DB. Wenn dann alle Plätze im Array gefüllt sind, dann braucht der DB 1,2MB Ladespeicher. Von nun an wächst er nicht mehr.
Dieses Verhalten ist in meinen Augen richtig großer Blödsinn. S. sagt aber das muss so sein :-(
Der Zuwachs an Ladespeicher kommt durch die zurückgelesen Werte zustande, die werden aus dem Binären-Puffer mit dem die CPU arbeitet in richtigen Text gewandelt. Und zwar für alle Werte die zum vorgegebenen Wert im UDT unterschiedlich sind. Aus einem schlichten einfachen BOOL mit dem Wert TRUE wird der String TRUE. Aus einem Byte machen die mehr als 6 -- heul.
'n schö' Tach auch
HB
Würdest Du für andere Suchende und auch mich selbst kurz aufzeigen, wie genau Du das umgesetzt hast?Mit Rezepten funktioniert es nun super, wie gewünscht.
Die Remanenz im DB schützt mich vor Spannungsausfall und die Rezeptur wird einfach nach jedem Speichervorgang exportiert und nach jedem Hochlaufen der CPU (z.B. nach vollständigem Laden) neu importiert. So werden die verlorengegangenen Daten sofort wieder in den DB geschrieben.
Danke nochmal!
Klar, kein Problem.Würdest Du für andere Suchende und auch mich selbst kurz aufzeigen, wie genau Du das umgesetzt hast?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?