Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 23

Thema: Grossen DB vor Verlusten schützen

  1. #11
    Registriert seit
    21.02.2014
    Ort
    Sachsen-Anhalt
    Beiträge
    1.392
    Danke
    221
    Erhielt 226 Danke für 208 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Mediator Beitrag anzeigen

    Sekündliches Logging ist übrigens nicht unbedingt ein Problem. Es kommt auf die Datenmenge an und auf die Größe der Speicherkarte bzw. den freien Speicher für die Log-Dateien:
    https://support.industry.siemens.com...view/109482591
    Das kann man theoretisch noch weiter entschärfen, indem man immer mindestens Daten in Blockgröße der Speicherkarte schreibt, da auch beim Schreiben eines einzelnen Byte immer ein kompletter Block gelöscht und neu geschrieben werden muß.
    Im Beispiel von Siemens kommt also eine irre große Zahl bei 160 Byte raus. Ist die physikalische Blockgröße z.B. 512 Byte wird jedes Byte 4 mal geschrieben, bevor der Block voll ist (wearleveling hat also viel zu tun!). Bei der physikalischen Blockgröße eines Flashmediums bin ich mir nicht sicher, daher schreibe ich mindestens 4kB am Stück.

  2. #12
    Registriert seit
    13.10.2007
    Beiträge
    11.950
    Danke
    2.746
    Erhielt 3.245 Danke für 2.143 Beiträge

    Standard

    wie währe es den, wenn du den Umweg über das Panel nimmst und mit ein
    paar Scripten die Daten auf einen Sicheren Medium speicherst.

    Siemens währe mir für deine Anwendung zu kribbelig, da ja mal wieder der
    Generationswechsel V13 -> V14 ansteht.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  3. #13
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.570
    Danke
    755
    Erhielt 637 Danke für 485 Beiträge

    Standard

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    wie währe es den, wenn du den Umweg über das Panel nimmst und mit ein
    paar Scripten die Daten auf einen Sicheren Medium speicherst.
    Das wäre eine Möglichkeit. Ich hab schon an einen Sekundengenauen Trend gedacht den ich dann Stündlich in Energie umrechne und per Skript ablege. Aber das würde dann so richtig aufwändig werden. Das Panel müsste auch immer da sein. Und wenn zwei Panel da sind gibts motze wenn die verschiedene Werte Aufgezeichnet haben. Hatte ich schon mit zwei WinCC OA rechnern die den Report selber gemacht haben. Da hatten die einen Rechner für Wochen nicht am netz und Jahre Später ist ihnen dann aufgefallen das der Energiereport auf beiden Kisten unterschiedliche Daten liefert.

    Siemens währe mir für deine Anwendung zu kribbelig, da ja mal wieder der
    Generationswechsel V13 -> V14 ansteht.
    Darum wäre mir ein CSV das man per Webserver auch wegspeichern könnte recht symphatisch gewesen.
    Aber die Logs lassen kein Lesen aus der CPU zu. Und die Rezepturen verlangen noch einiges an Einarbeitung meinerseits. Aber ich denke auf die dürfte es rauslaufen.

    Aber z.B. das Zitat aus der Hilfe finde ich schonmal niederschmetternd.
    Zitat Zitat von Export
    Als Dateiname der erstellten CSV-Datei wird der Name des Datenbausteins verwendet. Wenn bereits eine CSV-Datei mit dem gleichen Namen vorhanden ist, wird diese beim Export überschrieben.
    Zitat Zitat von Import
    • Der Name der CSV-Datei muss mit dem Namen des Datenbausteins am Parameter RECIPE_DB identisch sein
    Ich will doch nicht zwingend einen ganzen DB in eine Rezeptur sichern. Und zurücksichern will ich ja nur in einen Teil eines Arrays nicht einen kompletten DB überbügeln.

    Aber ich geh mal davon aus, dass die Hilfe noch nicht wirklich fertig ist.

    mfG René

  4. #14
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.570
    Danke
    755
    Erhielt 637 Danke für 485 Beiträge

    Standard

    Zitat Zitat von RONIN Beitrag anzeigen
    Auf der 300 war das einfach, auf der 1500 mit optimierten Datenbausteinen geht das aber nicht mehr wirklich.
    • Speichert WRIT_DBL auf DBs die schon auf der MMC existieren (mit TIA geladen wurden), dann werden die Zeitstempel verändert.
    • Man kann dem WRIT_DBL optimiert nicht den ganzen Datenbaustein, sondern nur einzelne Variablen/Strukuten etc. übergeben.


    Bin auch auf der Suche nach was neuem...
    Das geht bei der 1500er schon auch.
    Ich hab das z.B. mal so angedeichselt.
    Code:
    #dummy := READ_DBL(REQ := NOT "EnergysaveDB".Init, SRCBLK := "EnergysaveDB_save", BUSY => #readBusy, DSTBLK => "EnergysaveDB");
    
    
    IF NOT #readBusy THEN
        "EnergysaveDB".Init := true;
    END_IF;
    
    
    #dummy := RD_LOC_T(#DatenTime);
    
    
    IF #DatenTime.DAY <> #Daysave THEN
        #SavetoDB := true;
        #Daysave := #DatenTime.DAY;
    END_IF;
    
    
    #dummy := WRIT_DBL(REQ := #SavetoDB, SRCBLK := "EnergysaveDB", BUSY => #writeBusy, DSTBLK => "EnergysaveDB_save");
    IF NOT #writeBusy THEN
        #SavetoDB := false;
    END_IF;
    Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen. Sobald die CPU aber einmal auf diesen was sichert wird er von TIA als unterschiedlich erkannt und TIA will diesen dann IM LADESPEICHER initialisieren. Das heisst TIA löscht dann den SicherungsDB UND den DB im Arbeitsspeicher.
    EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet (was ja noch sinnvoll wäre, dann sind die Bausteine immer gleich)

    mfG René

  5. #15
    Registriert seit
    24.03.2010
    Ort
    Westerwald
    Beiträge
    155
    Danke
    39
    Erhielt 13 Danke für 7 Beiträge

    Standard

    Wie wäre es denn eine "Hybrid" Lösung zu machen. Also die Daten in der CPU Puffern und dann über die HMI per Script in eine .csv exportieren. So wäre auch bei zB einem Reboot der WinCC die Aufzeichnung in Betrieb und keine Daten gingen verloren.
    Vielleicht hilft dabei dieser Thread, da hat PN/DP einen Lösungsweg geäußert Prozessdaten einer CPU 317 auf Speicherkarte eines TP277 6'' speichern
    Gruß Florian

    Programmierer in sechster Generation

  6. Folgende 2 Benutzer sagen Danke zu plc_typ für den nützlichen Beitrag:

    testuser (18.08.2016),vollmi (18.08.2016)

  7. #16
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard

    Zitat Zitat von vollmi Beitrag anzeigen
    Das geht bei der 1500er schon auch.
    Ich hab das z.B. mal so angedeichselt.

    Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen. Sobald die CPU aber einmal auf diesen was sichert wird er von TIA als unterschiedlich erkannt und TIA will diesen dann IM LADESPEICHER initialisieren. Das heisst TIA löscht dann den SicherungsDB UND den DB im Arbeitsspeicher.
    EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet (was ja noch sinnvoll wäre, dann sind die Bausteine immer gleich)

    mfG René

    Den Konflikt mit dem TIA-Portal könntest Du vermeiden, indem Du den DB in der CPU anlegst (mit der Instruktion CREATE_DB). Der DB ist dann allerdings nicht optimiert, d.h. die Daten müsstest Du dann über Serialize/Deserialize übertragen.

  8. #17
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.268
    Danke
    439
    Erhielt 661 Danke für 498 Beiträge

    Standard

    Zitat Zitat von vollmi Beitrag anzeigen
    Das geht bei der 1500er schon auch.

    Das problem ist. Der EnergysaveDB_save DB ist nur im Ladespeicher abzulegen.
    EnergysaveDB_save und EnergysaveDB sind bei mir Optimierte DBs aus einem UDT abggeleitet
    Haha, das ist ja mal wieder spannend, hab grad ein wenig probiert.

    • Nicht optimierter Datenbaustein kann komplett an WRIT_DBK übergeben werden
    • Optimierter Datenbaustein geht nicht
    • Optimierter Datenbaustein aus UDT abgeleitet geht schon

    Aus UDT-abgeleitet geht, Standard-Db nicht. Sogar irgendwie logisch.

    Alles was mit UDT ist, ist im Endeffekt nur teiloptimiert, da diese im Speicher immer als ganzer Block abgelegt werden.
    Mann kann ja bei UDT-Daten die Remanenz ja auch nur für den Block festlegen. Das lässt sich leichter als Block übergeben.

    Um einen Optimierten-Standard-DB als ganzes an WRIT_DBL zu übergeben müsste man alles in eine Gesamt-Struktur packen.
    Die Idee finde ich nicht besonders spannend.

    Das nächste Problem ist dann wie oben angesprochen der geänderte Zeitstempel.
    Wie von Mediator gemeint kann man zwar auf ein Duplikat mittels CREATE-DB sichern, aber das macht es auch nicht viel besser.

    Wenn ich 20 DBs mittels WRIT_DBL sichern möchte, müsste ich folgendes machen:
    • Alle Daten in DBs in eine übergeordnete Struktur packen. Das widerspricht sich gewaltig mit den optimierten DBs.
    • 20 CREATE_DB_Aufrufe ausprogrammieren. CREATE_DB könnte man zumindest in einer Schleife aufrufen, müsste die DBs aber mit ordentlich Reserve erstellen. Man kann während der Laufzeit bei optimierten DBs keine Bytegröße mehr auslesen um die Größe des erstellten DBs optimal zu dimensionieren.
    • 20 WRIT_DBL-Aufrufe programmieren. Die muss man wirklich programmieren. Kenne keinen Weg um die symbolische Übergabe der DBs zu dynamisieren.
    • 20 READ_DBL-Aufrufe programmieren. Irgendwer muss ja die Daten zurückladen.


    Ein Arsch voll Arbeit, man muss die komplette Datenstruktur danach ausrichten und die MC muss auch doppelt so groß sein.

    Hierzu muss ich noch sagen dass er mir hierbei eher nur darum geht dass die Daten/Einstellwerte beim CPU-Tausch nicht futsch sind.
    Je nachdem wie viele Anlagenteile man hat können das schon mal schnell 20/30 DBs sein. Auf der 300 machen wir das mit nem Mini-FB der WRIT_DBL in einer Schleife aufruft.
    Einfach DBNr100 bist DBNr150 sichern, Start, Danke.

    Sowas würd ich halt auch gern mit optimierten FBs vernünftig können.
    Geändert von RONIN (18.08.2016 um 14:33 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  9. #18
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.570
    Danke
    755
    Erhielt 637 Danke für 485 Beiträge

    Standard

    äh da kommt mir grad noch das unter:
    Zitat Zitat von CHREATE_DB
    • Bit 2 = 0: DB remanent (nur bei DBs, die im Ladespeicher erzeugt werden). Der DB gilt als remanent, wenn mindestens ein Wert remanent gesetzt wurde.
    Ja super. Dann nimmt mir ein DB den ich nur auf der Karte hab, auf den ich nicht direkt zugreifen kann und sonst zu nix nütze ist, trotzdem Remanenzspeicher weg?
    Bin ich denn bescheuert?

    mfg René

  10. #19
    Registriert seit
    15.03.2013
    Beiträge
    187
    Danke
    6
    Erhielt 35 Danke für 30 Beiträge

    Standard

    Zitat Zitat von vollmi Beitrag anzeigen
    äh da kommt mir grad noch das unter:


    Ja super. Dann nimmt mir ein DB den ich nur auf der Karte hab, auf den ich nicht direkt zugreifen kann und sonst zu nix nütze ist, trotzdem Remanenzspeicher weg?
    Bin ich denn bescheuert?

    mfg René
    Nein, brrrr
    Es war so gemeint : Du erzeugst mit CREATE_DB einen nicht remanenten DB, der nur im Ladespeicher liegt und groß genug für alle Datensätze ist, die Du dort speicher willst. Später kannst Du mit WRITE_DBL einen Datensatz dort sichern oder von dort lesen. Da der DB nicht optimiert ist, must Du vor dem Schreiben eines Datensatzes den Datensatz serialisieren (serialize) und vor dem Lesen deserialisieren (deserialize). Hierfür brauchst Du im Programm einen nicht optimierten DB, der einen Datensatz aufnehmen kann.

    Ich hatte Dich so verstanden, dass Du im Programm immer nur einen Datensatz brauchst, aber auf der Karte zwölf Datensätze.

  11. #20
    Avatar von vollmi
    vollmi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    22.11.2006
    Ort
    CH
    Beiträge
    3.570
    Danke
    755
    Erhielt 637 Danke für 485 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Mediator Beitrag anzeigen
    Nein, brrrr
    Es war so gemeint : Du erzeugst mit CREATE_DB einen nicht remanenten DB, der nur im Ladespeicher liegt und groß genug für alle Datensätze ist, die Du dort speicher willst.
    Dann verstehe ich die Hilfe nicht.
    Zitat Zitat von CHREATE_DB
    • Bit 2 = 0: DB remanent (nur bei DBs, die im Ladespeicher erzeugt werden). Der DB gilt als remanent, wenn mindestens ein Wert remanent gesetzt wurde.
    Wenn ich DBs die im Ladespeicher erzeugt werden nur als remanent oder nicht remanent auswählen kann. wozu dann einen im Ladespeicher erzeugen. Ich war der meinung dbs im Ladespeicher können eh nur mit writedb geschrieben werden und diese werte sind sowieso nur so veränderlich also müssen keinen Remanenzspeicher haben da sie ja im Ladespeicher also auf der Speicherkarte fest geschrieben also unveränderlich sind.


    Später kannst Du mit WRITE_DBL einen Datensatz dort sichern oder von dort lesen. Da der DB nicht optimiert ist, must Du vor dem Schreiben eines Datensatzes den Datensatz serialisieren (serialize) und vor dem Lesen deserialisieren (deserialize). Hierfür brauchst Du im Programm einen nicht optimierten DB, der einen Datensatz aufnehmen kann.

    Ich hatte Dich so verstanden, dass Du im Programm immer nur einen Datensatz brauchst, aber auf der Karte zwölf Datensätze.
    Ich muss ja die Datensätze nicht optimiert ablegen. Also ist deserial nicht zwingend nötig.
    Das hast du richtig verstanden. Ich arbeite immer nur mit dem aktuellen Monat, den kann ich dann täglich auf der Karte sichern und rücklesen bei firstrun oder init.

    Ich muss mir das nochmal ansehen. Lesen und schreiben in eine CSV hätte mir aber besser gefallen.
    Das wäre dann wohl die Panellösung. Allerdings habe ich von Scripten derzeit noch sowas von keine Ahnung.

    mfG René

Ähnliche Themen

  1. Antworten: 4
    Letzter Beitrag: 16.09.2014, 10:50
  2. OHP-SPS vor Gedächtnisverlust bei Stromausfall schützen?
    Von shevek im Forum CODESYS und IEC61131
    Antworten: 5
    Letzter Beitrag: 30.08.2011, 10:14
  3. Instanz DB vor Zugriff schützen
    Von Pinky im Forum Simatic
    Antworten: 9
    Letzter Beitrag: 05.07.2010, 21:42
  4. USB-Lizenz-Stick vor löschen schützen
    Von neibeck im Forum Simatic
    Antworten: 17
    Letzter Beitrag: 23.10.2009, 11:52
  5. Datenbaustein vor Überschreiben von PG schützen
    Von scrolllkock im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 31.01.2007, 14:12

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •