TIA SD-Karte (MicroMemoryCard) als Datenspeicher nutzen.

A

Aksels

Level-2
Beiträge
257
Reaktionspunkte
9
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo liebe Mitleser,
ich habe einen Archivbaustein geschrieben, der es mir ermöglicht die Dauer und die Anzahl von z.B. Einstau eines Beckens in einem DB zu speichern. Im HMI kann man dann die Daten Tages-, Monats- oder Jahressummiert anzeigen lassen.
Leider frisst der Baustein sehr viel Platz. Nun wollte ich die Daten auf der SD-Karte auslagern. Aber die Befehle READ_DBL WRITE_DBL erfordern, dass der Baustein aktiv in das Programm eingebunden ist. Dann spare ich keinen Speicherplatz.
Mit der Befehlsfamilie um DataLogWrite kann ich nur Daten schreiben, aber nicht lesen.
Gibt es wirklich keine Möglichkeit die Memory Card als Auslagerspeicher zu verwenden?

Wie sieht es im HMI unter VB-Script aus? Leider geht das wieder nur für Comfort-Panels.
Ein Jammer.......


Aksels
 
Meinst du Micro Memory Card (MMC) für S7-300, oder Simatic Memory Cards (SMC, bassiert auf SD-Karten) für S7-1200/1500 ?
Die SMC-Karten sind ja viel grösser und billiger als die MMC Karten.
 
Aus der Online Hilfe:
The instruction "WRIT_DBL" is used to transfer the contents of a DB or a DB area from the work memory to a DB or a DB area in the load memory (Micro Memory Card). The source DB must be relevant for execution, which means it must not be created with the Only store in load memory attribute.
Zum Vergrößern anklicken....
Also, ich verstehe es so dass der Ziel-DB muss nicht unbedingt in Arbeitsspeicher geladen werden.

edit:
Aber selbst wenn es in Prinzip geht, dann ist es vielleicht nicht empfehlenswert:
Aus der Online Hilfe:
Note"WRIT_DBL"is not suitable for frequent (or cyclical) writing of tags in the load memory. This is because the Micro Memory Card technology limits the number of write accesses that can be made to a Micro Memory Card.
Zum Vergrößern anklicken....
Wenn ich dich richtig verstanden habe, dann brauchst du sehr viele Schreibzyklen.
 
Zuletzt bearbeitet:
Übersetzt: "....darf nicht mit dem Attribut nur im Ladespeicher anlegen erstellt werden." Bedeutet für mich, der Baustein muß auch im Arbeitsspeicher stehen. Read_dbl und write_dbl dienen also nur dazu Ladespeicher und Arbeitsspeicher zu synchronisieren. Wozu gibt es aber das Attribut nur im Ladespeicher anlegen?

Gesendet von meinem GT-I9301I mit Tapatalk
 
Aksels schrieb:
Die DB ist riesengroß. Die paßt nicht mehr in den Arbeitsspeicher.
Zum Vergrößern anklicken....
Das heißt für mich: für die Aufgabe wurde die falsche CPU ausgewählt oder es wird versucht etwas zu tun, wofür SPS generell nicht gut geeignet sind, oder es wird zuviel überflüssiger Müll gespeichert.

Was für eine CPU hast Du? Wie groß ist "riesengroß", wie groß soll der DB sein? Was wird in den DB gespeichert?

Aksels schrieb:
Wozu gibt es aber das Attribut nur im Ladespeicher anlegen?
Zum Vergrößern anklicken....
Das SPS-Programm kann generell nur in/aus DB im Arbeitsspeicher schreiben/lesen. WRITE_DBL kopiert die Aktualwerte eines DB im Arbeitsspeicher in einen DB im Ladespeicher (MMC). READ_DBL kopiert einen DB vom Ladespeicher in einen DB im Arbeitsspeicher. Dabei dürfen sich die DB-Nummern von Quelle und Ziel unterscheiden, was z.B. für Rezepturen vorteilhaft ist: Auf dem Ladespeicher können sich viele Rezepturen befinden (z.B. DB101, DB102, DB103 ..., jeweils mit der gleichen Struktur), welche bei Bedarf immer in den selben DB (z.B. DB100) im Arbeitsspeicher kopiert werden. Zur Platzersparnis brauchen die Rezepturen nicht alle gleichzeitig im Arbeitsspeicher liegen - dafür ist das Attribut "nur im Ladespeicher" gedacht.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Überflüssiger Müll/falsche CPU: Es geht um Einstau, Überlauf und Durchflussimpulse von Regenüberlaufbecken. Den Baustein hatte ich geschrieben, damit, sollte die Fernwirk-Verbindung für eine Weile ausfallen, man diese Daten am HMI ablesen kann. Die Daten wurden 2 Jahre täglich,2 Jahre Monatlich und 4 Jahre als Jahressumme gespeichert.
Dann wurde das Programm für die RÜBs überabeitet, neue Fernwirk, und schwupps ist der Speicher zu klein. Ich habe dann die Speicherungszeiten verkürzt bzw. die Tagessummen entfernt. Der Kunde bettelt aber, dass ich das wieder einbauen soll, das war ja so praktisch. Die CPUs sind also schon da, mit denen muss ich leben. Datenmüll? Die Beurteilung muss ich wohl dem Kunden überlassen.

Write_dbl/Real_dbl:
Zur Platzersparnis brauchen die Rezepturen nicht alle gleichzeitig im Arbeitsspeicher liegen - dafür ist das Attribut "nur im Ladespeicher" gedacht.
Zum Vergrößern anklicken....
Genau das ist doch der Punkt! In der Anleitung steht:
The source DB must be relevant for execution, which means it must not be created with the Only store in load memory attribute.
Zum Vergrößern anklicken....
Das widerspricht Deiner Aussage. Ich hab es deswegen gar nicht versucht, da die Anleitung mir eindeutig erschien.

Ich werde das heute wohl mal selber ausprobieren müssen.
Danke für's mitdenken.
Aksels
 
Sowas könnte man ja auch so lösen das man z.B. einen DB als Aufzeichnungsziel nimmt im Arbeitsspeicher. z.B. für einen Monat. Dann nach abschluss des monats die Aktualdaten in einen DB des Ladespeichers kopiert. Im Ladespeicher z.B. für jeden Monat ein DB.
Per Panel wählt man dann den Monat aus und in der CPU liest man dann die Daten aus dem Ladespeicher und kopiert sie in einen DB für die Anzeige im Arbeitsspeicher.
Das geht eigentlich ganz gut. Ich habe eine CPU auch schon so malträtiert. Braucht halt ne entsprechend grosse Speicherkarte und RAM für zwei DBs, einen für die Anzeige, einen für die Aufzeichung über den gewünschten Zeitraum.

mfG René
 
So habe ich mir das vorgestellt, ja.
Dummerweise habe ich jetzt festgestellt, dass der Kunde nur Vipas hat. Da diese der 300 entsprechen wird das nix mit READ_DBL und WRITE_DBL.
Oder gibt es da entsprechende Befehle?

Aksels
 
The source DB must be relevant for execution, which means it must not be created with the Only store in load memory attribute.
Zum Vergrößern anklicken....
Es bedeutet, der Quell-DB in Arbeits-Speicher/RAM (wovon du nach den Ziel-DB in Lade-Speicher/SMC kopieren willst), darf nicht mit den genannten Attribut generiert werden.
Den Ziel-DB in Lade-Speicher/SMC kann mit Only store in load memory generiert werden.

Aber wie schon genannt, man soll nicht sehr viele Schreibzyklen ausführen. Wieviele es erlaubt ist weis ich nicht, aber den Hinweis von Siemens steht nicht da ohne Grund.
 
Ach sooooo! Das war der Text vom Write_DBL. Alles klar!

Ich denke einen Schreibzyklus pro Tag wird die SD schon aushalten!

Aksels
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Aksels schrieb:
Dummerweise habe ich jetzt festgestellt, dass der Kunde nur Vipas hat. Da diese der 300 entsprechen wird das nix mit READ_DBL und WRITE_DBL.
Zum Vergrößern anklicken....
Die S7-300 kann READ_DBL und WRITE_DBL.

Ist ja toll, daß man schon auf Seite 2 der Diskussion einen Hauch einer Andeutung bekommt, daß es sich wahrscheinlich nicht um Siemens-CPU sondern um nicht näher spezifizierte VIPA-CPU handelt... :roll:

Die VIPA-CPUs haben gar keine SFC83 READ_DBL und SFC84 WRIT_DBL, die Diskussion über ablaufrelevant/nur im Ladespeicher erübrigt sich also. Die VIPA-CPUs haben VIPA-spezifische FC/SFC zum lesen/schreiben von Files auf der MMC.

Zielgerichtet "mitdenken" kann man nur wenn man detailliertere Informationen hat.

Welche CPU hast Du (genaue Bezeichnung/Bestellnummer)?
Welches HMI hast Du (genaue Bezeichnung/Bestellnummer)?

Und nochmal die Nachfragen, weil nicht beantwortet:
Wie groß ist "riesengroß", wie groß soll der DB sein?
Was wird in den DB gespeichert? (wie ist die Struktur und das Format der Daten)
Was passiert mit dem Archiv, muß das auch irgendwie angezeigt werden?


Mit "überflüssigem Müll" meine ich z.B. ob Zeitstempel als String[20] oder als DATE_AND_TIME gespeichert werden oder andere ungünstige Formate oder redundante Daten verwendet sind oder Strukturen mit ungünstigem Padding. Oder ob immer ganze Datensätze archiviert werden oder nur das was sich geändert hat.

Harald
 
Hallo Harald.
Ich habe diverse CPUs aus dem 300er 1200er und 1500er Bereich auf denen der Baustein laufen soll (ca 15 verschiedene Typen).
Beim HMI: 5", 7" und 15" aus Basic und Comfort-Schiene.
Riesengross: So gross, dass er bei manchen CPU/MMC/Programmkombinationen nicht mehr in der Arbeitsspeicher passt. Und soll noch größer werden, dass der Kunde auch in Zukunft bei Ausgau der Anlagen alle gewünschten Schaltspiele speichern kann.
Im DB werden nur UDINT gespeichert.
Anzeige programmiere ich gerade.
Mal schauen, ob ich es heute fertig bekommen. Dann stelle ich es mal ein.

Aksels
 
Also, du bist ein bisschen verwirrt, oder .. ?
In Beitrag #3 hast du geschrieben das es (nur) um S7-1200/1500 handelt.
Jetzt schreibst du:
Aksels schrieb:
Ich habe diverse CPUs aus dem 300er 1200er und 1500er Bereich auf denen der Baustein laufen soll (ca 15 verschiedene Typen).
Zum Vergrößern anklicken....
Das hättest du ja im ersten Beitrag erklären können. Plus das es auch in ein VIPA CPU laufen soll.

Zum "Riesengross": Warum erklärts du nicht genau welchen grösse das du benötigst ?

Ich habe den Gefühl. das deine Aufgabe passt besser zu ein PC Datenbank als in ein SPS. Und wenn kein PC/Datenbank Lösung, dann lieber über ein Flashkarte in ein Panel als das Flashkarte in der SPS.
In beide Fallen hast du kein Problem mit unterschiedliche SPS Typen. Und wenn das Flashkarte defekt geht wegen zu viele Schreibzyklen, dann steht deine Anlage nicht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem verwirrt kann sein.
Riesengross: Jeder Kunde will mehr oder weniger Daten da drin haben. Deswegen programmier ich die Größe gerade dynamisch (mit Konstanten einstellbar). Bin gespannt ob es euch gefällt.
Ja, das mit der DB hab ich mir auch schon überlegt. Für ein Siemens HMI kann ich einen RPi mit FullHD Display und Touch kaufen. Wenn ich mal Zeit für die Entwicklung habe würde ich das zu gerne mal machen.
Flashkarte und Panel: geht wieder nur bei Comfort HMI, was den kleineren Teil meiner betreuten Anlagen ausmacht.....

Aksels
 
Also, wenn es ein beliebigen SPS und beliebigen grössen sein kann, dann glaube ich das du das abspeichern auf der SPS Flashkarte vergessen kann.
Besonders bei die MMC Karten auf S7-300 ist der Möglichkeit auf das Flashkarte zu schreiben nie gemeint als Speicher für grossen Datenmengen.

Ein KP700/TP700 Comfort Panel ist teurer als ein KTP700 Basic Panel, aber nicht viel. Ein grossen Flash-Karte für S7-300 ist teuer, und geht zu max 8 MB.
Ich sehe das Datenlogging auf ein billigen Flashkarte in ein Comfort Panel als die Lösung der deine Anforderungen am einfachsten beseitigt, ohne Probleme mit mehrere Varianten, ist billig, kann ohne weitere GB abspeichern, und das Anlage muss nicht still gelegt sein wenn das Karte gewechselt warden muss.
 
Ich würde bei der Anforderung zu einen Comfort Panel gehen, die es
sogar in 4" Ausführung gibt. Da besteht sogar die Möglichkeit die
Daten in ein externen Massenspeicher zu exportieren. Das exportieren
über ein Panel oder durch externe Software (Deltalogic) ermöglicht es
gleich die Daten sofort in ein gängiges Format darzustellen, das zur
Aufarbeitung für den Kunden viel geeigneter ist (zB CSV)

Somit könnte man sich diese ganze gehampel mit den unterschiedlichen
CPUs ersparen. In Sumne wird ein Comfort Panel richtig eingesetzt einiges
Preiswerter als eine Monatelange Fehlendwicklung.

Durch verfolgen des Themas zeigt das der TE nicht einmal in der Lage sich ein
vernünftiges Lastenheft zu erstellen und einfach mal den Extremfall des
Speicherbedsrfes zu definieren.
 

Similar threads

R
CodeSys 2.3 Webvisu Zugriff auf SD-Card 750-880 klappt nicht
Antworten
6
Aufrufe
4K
Rewe2000
R
Zurück
Oben