TIA S7-1200 Datenbausteine im Ladespeicher ablegen

[Otwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich bastel gerade an einem Langzeitarchiv für Verbrauchsmesswerte.
Da der CPU-Remanenzspeicher leider etwas begrenzt ist, hab ich mir gredacht, dann schreib ich die Datenn halt einmal am Tag in den Ladespeicher auf die MMC.
Ich habe mir also einen UDT "Langzeitarchiv" mit diversen arrays (Tages,Monats,Jahreswerte usw) angelegt und einmal in einem DB im Arbeitsspeicher und einmal in einem DB im Ladespeicher eingefügt.
Im Ladespeicher sollen es dann mehrere dieser UDTs werden, die nach Bedarf zum bearbeiten in den Arbeitsspeicher kopiert werden können.

Zum Anzeigen auf dem HMI würden diese Daten dann auch nach Bedarf in den Arbeitsspeicher kopiert, sodass immer nur die Werte eines Verbrauchers im Arbeitsspeicher liegen müssen.

Jetzt kann ich die Daten von der MMC in den Arbeitsspeicher kopieren, bearbeiten und danach wieder zurück auf die MMC schreiben.
Soweit noch kein Problem.

Aber:
Wenn ich den Datenbaustein auf der MMC geändert habe, zeigt mir TIA im Onlinevergleich, das der DB geändert wurde und beim nächsten Laden in die CPU überschreibt mir TIA den DB mit den Startwerten.
Was soll denn das? Ich kann den DB nicht beobachten, weil er ja nur im Ladespeicher liegt, aber überschrieben wird er einfach so.

Ich hab schon überlegt mit dem Rezept-export zu arbeiten, aber so wie ich das sehe, müsste ich dabei die kompletten Daten auf einmal umkopieren, was dann wieder Probleme mit dem Arbeitsspeicher bringen würde.

CPU ist eine 1212 DC/DC/DC V3.02
TIA V13SP1

Kennt da jemand eine Lösung für das Problem?

Oder hat wer das Problem mit grossen remanenten Datenmengen anders gelöst?

Gruß
Otwin

 

[Gleichstromer]

Hi,
bei einer 1214C/TIAV12SP1 Basic habe ich einen Ringspeicher aus 8 DB im CPU-internen Ladespeicher (4MB), wie bei dir wird ein UDT mit mehreren Arrays abgespeichert, allerdings werden diese Daten nicht mehr vom Programm zurückgelesen. Die Daten in den Ladespeicher-DB kann man per "Momentanaufnahme der Beobachtungswerte" in TIA auslesen. Du müsstest dann wahrscheinlich mit "Momentanaufnahme als Startwerte übernehmen" die alten Startwerte ersetzen und wieder in die CPU laden.
Allerdings verstehe ich nicht ganz deine Schilderungen, was meinst du z. B. mit "Wenn ich den Datenbaustein auf der MMC geändert habe ..." bzw. das eigentliche Problem. Das beim Laden in die CPU die Startwerte neu initialisiert werden ist doch normal.
Vielleicht musst du mehrere DB nutzen, einen mit den erforderlichen Startwerten füs Programm und andere zum Speichern deiner Verbrauchsdaten.

Gruß,
Gleichstromer

 

[Otwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
Vielleicht hab ich mich etwas unverständlich ausgedrückt
ich habe das so gemeint:
Ich erstelle im TIA einen DB mit dem Attribut "Nur im Ladespeicher ablegen".
Über einen FB kopiere ich werte aus einem normalen DB in den Ladespeicher-DB. Das funktioniert.
Ich Schalte die CPU auf STOP und wieder auf RUN. Die Werte im normalen DB sind Weg, weil ja nicht remanent.
Jetzt kopiere ich die Werte aus dem Ladespeicher-DB in den normalen DB. Werte sind wieder da, weil ja auf MMC gespeichert und somit remanent.

So war der Plan, aber leider hat S was dagegen.

Im TIA bin ich online auf der CPU. Sobald ich jetzt über mein Programm Daten in den Ladespeicher-DB kopiere, sagt mir TIA im Online-Vergleich, das der Datenbaustein unterschiedlich zur Offline-Version ist.
Warum macht TIA das denn, wenn ich Daten in einen normalen DB schreibe, sagt TIA ja auch nicht, dass On- und Offline-Version verschieden sind und überschreibt ihn bei jedem Programm-Download.
Klar, wenn ich einen Datenbaustein übersetzte und in die CPU lade, werden die Werte mit den Startwerten überschrieben.
Das Problem ist aber, dass TIA mir diesen Ladespeicher-DB jedesmal überträgt, weil sich ja angeblich was geändert hat. Damit ist die Idee, den Ladespeicher-DB als remanenz-Speicher zu missbrauchen ja hinfällig, ich will ja nicht jedesmal vor dem Downloaden den DB sichern
(was bei mir irgendwie auch nicht funktioniert)

Ich werde jetzt wohl doch die Sache mit den Rezepten probieren, auch wenn ich dann leider alle Daten im Arbeitsspeicher halten muss. Zum testen muss ich aber erst warten, bis meine neue 1214er da ist, mit den 50kB Speicher der 1212V3 komm ich da gar nicht zu recht.
Schade, das Speicher im Jahr 2015 immernoch so knapp ist Andere Hertseller haben da mehr zu bieten, da könnte man fast neidisch werden.

Gruß
Otwin

 

[PN/DP]

Frage Siemens, ob es in dem TIA irgendwo eine Option zum Abschalten dieses Verhaltens gibt (ich kenne TIA nicht genug) bzw. frage, wie Siemens sich die Lösung Deiner Aufgabe bei der S7-1200 vorgestellt hat.
Dieser ganze ständig-online-vergleichen-"Comfort" ist imho der größte Mist, der Siemens jemals eingefallen ist.

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

 

[Otwin]

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

So wie ich das sehe, kann man erst ab den 1500er CPUs Datenbausteine im Programm erzeugen.

DataLogs auf die Karte gehen schon, ist aber leider ein One-Way-Ticket. Zurücklesen geht nicht.

Rezepte exportieren und wieder importieren ist mein nächster Plan, geht aber leider erst mit ner Firmware V4. Da muss ich mit dem testen leider warten, bis die neue CPU da ist.
Dafür gehe ich dann stark davon aus, dass mir TIA die exportierten Rezepte in Ruhe lässt.

Gruß
Otwin

 

[HelleBarde]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[inspectorgadjet]

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.

 

[Ralle]

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.

 

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

... sag mal Ralle, ist das Dein Hobby täglich abzulästern, oder spekulierst Du auf einen hochdotieren Beratervertrag bei BigS?

 

[inspectorgadjet]

Denen braucht man nichts mitzuteilen, wir interessieren die nicht.

Ja leider...

 

[Ralle]

... sag mal Ralle, ist das Dein Hobby täglich abzulästern, oder spekulierst Du auf einen hochdotieren Beratervertrag bei BigS?

Nein, ich bin frustriert, das hat auch nichts mit Lästern zu tun, was ich mache, sondern ist bitterer Ernst. Im Gegensatz zu den Siemens-Figuren muß ich den Sch... zum Laufen bringen und dann auch für die Funktion der Maschinen den Kunden gegenüber gerade stehen. Ich hab keine Ahnung, was die sich dabei denken, aber das Alles ist kein Selbstzweck und kein Spaß, da hängen Arbeitsplätze und z.Teil auch die Gesundheit von Menschen dran, die sich die Nerven mit dem ganzen Datenmüll ruinieren.

PS: Wie ich ohnehin schon schrieb, ist Siemens Beratungsresistent, die brauchen mich zu Allerletzt!

Zusatz: Es ist einfach so, wir diskutieren hier seit Jahren, wirklich seit Jahren immer wieder den selben Mist, von einer Version zur nächsten werden die wirklich wichtigen Dinge, teilweise ganz einfache kleine Sachen, einfach von Siemens ignoriert. Das endet in Mega-Frust, in Wut und am Ende und in der Suche nach Steuerungsbauern die vielleicht einfach kapieren, was zu tun ist.

Ich erinnere nur an die Siemens-Handysparte, das lief nicht genauso ab, aber Ähnlichkeiten sind vielleicht nicht doch nur zufällig.

 

[Otwin]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Hi,
erstmal Danke für die vielen Antworten!

Sowas wie HelleBarde geschrieben hat, hab ich schon befürchtet.
Das macht die Sache leider unbrauchbar für mich. Da kann ich ja drauf warten, bis ich vergesse die Daten zu sichern (müsste ich ja bei jeder kleingkeit, die ich irgendwo im Programm ändere) und alle Daten weg sind.
So macht das keinen Spass!

Was rauchen die Jungs bei Siemens eigentlich, um sich so einen Krampf auszudenken?

Gruß
Otwin

 

[Lukas_57]

Hallo zusammen,
habe ein ähnliches Anliegen wie @Otwin damals.
Ich möchte mit meiner 1500er CPU und TIA v17 gern zuvor eingelesene Seriennummern sicher ablegen.
Einfache Remanenz im DB reicht leider nicht aus, weil nach einem vollständigen Laden des Projektes die Daten immer wieder weg wären.
Schreibe nun auch mit WRIT_DBL die Seriennummern nach dem Einlesen in die Startwerte des Speicher-DB. ...Mit der Folge, dass mein Projekt dann auch im Online/Offline Vergleich nicht mehr konsistent ist.
Wie @HelleBarde oben schrieb, macht mir das dann auch Probleme, weil vor einem erneuten Laden immer erst der Speicher-DB hochgeladen werden muss, damit man nicht anschließend beim Herunterladen die Startwerte wieder mit Leerstellen überschreibt.

Gibt es dazu mittlerweile einen Lösungsansatz oder funktioniert das in TIA heute noch so wie 2015...?
Danke und VG

 

[MFreiberger]

Moin Lukas_57,

ich habe mir jetzt den Thread nicht durchgelesen, aber kann man nicht im Anwenderprogramm eine Datei erstellen (=> FileWriteC)?
Diese Datei sollte doch sicher abgelegt sein oder wird sie beim Übertragen wieder überschrieben?

VG

MFreiberger

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du könntest die Daten als RecipeExport oder DataLog auf der Speicherkarte der CPU ablegen. Da sollte das TIA nicht drin rumpfuschen.
Siehe TIA Hilfe "Rezepturen und Data Logging"

Harald

 

[Lukas_57]

Danke für die schnellen Antworten, werde mir das mal ansehen.

**EDIT**
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!

 

[Otwin]

Ich kann da leider nichts mehr zu sagen, bin schon vor Jahren auf Wago umgestiegen und habe seither keine Probleme mit limitiertem Speicherplatz mehr gehabt

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

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!

Würdest Du für andere Suchende und auch mich selbst kurz aufzeigen, wie genau Du das umgesetzt hast?

 

[Lukas_57]

Würdest Du für andere Suchende und auch mich selbst kurz aufzeigen, wie genau Du das umgesetzt hast?

Klar, kein Problem.

Aufgabenstellung:
Seriennummern von Schlüsselchips sollen eingelesen und durch einen FC sicher abgelegt werden. Diese Schlüsseldaten müssen sicher sein vor Spannungsausfall und einem Komplettladen des TIA Projektes, falls an anderen Programmteilen in Zukunft Änderungen gemacht werden.

Lösung:
Der Einlesemodus wird aktiviert. Seriennummern werden eingelesen. Ein freier Speicherplatz im Schlüsseldaten Array wird ermittelt. Seriennummern werden auf freiem Array Feld als String abgelegt. Nachdem der Einlesemodus beendet wurde, wird mit dessen fallender Flanke die gesamte Datenbank (das gesamte Array) mit allen Schlüsseldaten mit RecipeExport als CSV Datei auf der Memory Card abgelegt. Die alte CSV Datei wird überschrieben.


Szenario 1:
Ausschalten der Spannungsversorgung. Der Speicher DB ist remanent, deshalb bleiben die Daten gespeichert.

Szenario 2:
Wird das Programm neu in die CPU geladen, verschwinden alle Seriennummern im DB, weil diese natürlich nicht fest im Projekt stehen, sondern nur als Momentandaten in den Speicherzellen im RAM. Nach jedem Neuanlauf der CPU wird also mit RecipeImport die CSV Datenbank wieder auf den Speicher DB geladen. Alle Werte werden mit denen von der CSV Datei überschrieben.

Achtung: Die Beschaltung des RecipeImport ist zu Testzwecken noch provisorisch. Der "EKS_IBN_TEST".i_trigger_mmc_read lässt sich per Hand aber steuern. Nach dem Import stehen alle Daten wieder im Datenbaustein EKS_SN_String_Array.

 

[PN/DP]

Danke für die Beschreibung der Lösung.
Tipp: bei der S7-1500 heißen die Speicherkarten nicht MMC sondern SMC