DLOG in Schleife beschreiben.

Begonnen von VincentVega, 31. Mai 2016, 19:23:36

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 1 Gast betrachten dieses Thema.

VincentVega

Guten Abend.

Erst einmal herzlichen Dank für OSCAT - wirklich tolle Arbeit.

Zu meinem Problem :

PFC200 und Network 130 für PFC200.

Es sollen 32 Instanzen von je 7 REAL Datensätzen + einem Zeitstempel + ein paar DINT und BOOL Einzeldaten in einer CSV Datei gespeichert werden.

Leider stehen meine Daten nicht in den erwarteten Spalten, sondern um eine Spalte versetzt, bzw. auch völlig falsch.

Darf ich EINE Instanz von DLOG_REAL mit 234 verschiedenen Spaltennamen in einer Schleife aufrufen, danach noch ein paar andere Spalten hinzufügen
und dann 1x DLOG_STORE_CSV ausführen ?

In der Angehängten CSV sollten nur in den "inv_6" Spalten Daten vorhanden sein, nicht in den anderen.
Alle anderen Datenpunkte sind 0.

PS: Im angehängten Text habe ich pro Datentyp mehrere Instanzen der DLOG Bausteine benutzt. Auch mit EINER Instanz pro Datentyp ergibt sich das gleiche Bild.

Vielen Dank für eure Hilfe !

Gruß
Vince









[gelöscht durch Administrator]

peewit

#1
unter bestimmten bedingungen ja aber das ist ein ritt auf messers schneide !

zu allererst versucht mein datalogger baustein festzustellen wieviele dlog_x bausteine (anzahl der datenspalten)
vorhanden sind.

dazu wird ein signal an alle dlog_x bausteine ausgegeben und jeder dieser bausteine erhöht einen zähler
sodass am ende feststeht wieviele dlog_x bausteine es sind bzw wieviele datenspalten

hier passiert ziemlich sicher schon der fehler

in der datenstruktur "x" gibt es den eintrag
ID_MAX  USINT Anzahl der DLOG_* Bausteine

diesen solltest du mal überprüfen, ziemlich sicher stimmt dieser wert nicht mit der anzahl an datenspalten zusammen

nächstes problem ist die anfallende datenmenge bei einem speicherzyklus
je nachdem wie die spaltenüberschriften sind und die 234 datenwerte kann es leicht sein das in summe mehr als 4096 bytes auf einmal anfallen, und dann gibt es datenverlust !

ich arbeite gerade an einer verbesserten version die diese probleme so nicht hat und auch diverse fehlermeldungen diesbezüglich ausgibt.
dort gibt es dann auch einen dlog_real_64 baustein
da kannst du mit einer bausteininstanz 64 realwerte über eine datenstruktur verarbeiten
und würde dein problem elegant lösen


auf jeden Fall begibst du dich mit der momentanen version an die leistungsgrenze

probiere mal das ganze mit nur 100 spalten
mal sehen ob es noch die gleichen fehler gibt


VincentVega

Guten Morgen.

Vielen Dank für deine Antwort.
Das habe ich befürchtet, die Anzahl an Spalten ist ja auch am Limit.
Ich habe die Puffergröße wie in einem anderen Beitrag erklärt auf 32735 Byte erhöht.
Das alleine hat aber keine Besserung gebracht.

Jetzt habe ich die Aufrufe auf 32 Instanzen des DLOG_REAL verteilt, der Baustein wird also
für jede Spalte mit einer eigenen Instanz aufgerufen.

TRIG_T steht auf 30S, AUTO_CLOSE ebenso.

Jetzt scheint es zu tun, was es soll :
Alle 30 Sekunden die Messreihe eintragen, alle 30 Minuten wird der Dateiname geändert und der FTP Transfer ausgelöst.

FTP Retry_Time und Timeout sind 1 Minute, RETRY = 5. Damit wird nur in der Aufzeichnungsphase ein Transfer wiederholt,
nicht wenn schon eine neue Datei verschickt werden soll.

Beim Wechsel des Dateinamens verschiebt sich aber etwas.
Der Zeitstempel wird plötzlich zusammen mit einem anderen Wert ( REAL ) in eine falsche Spalte geschrieben, ab dort
ist die NEUE Datei dann verschoben.

Muss ich beim Dateiwechsel das ENABLE für den STORE Baustein wegnehmen ?

Gruß
Mark






peewit

das verschieben bei dateiwechsel kenne ich

nachdem der 30 sekunden trigger und der dateinamenwechsel genau in der gleichen sekunden auslösen
sind beim dateiwechsel noch viele daten im buffer.
beim dateiwechsel wird wieder ein scan nach der anzahl der dlog_* bausteine gemacht und in dem moment stimmt diese zahl nicht und der datenlogger nimmt eine falschen anzahl an spalten an

diesen fehler habe ich in meiner "arbeitsversion" schon lange gefixt

DLOG_STORE_FILE_CSV

00:   IF ENABLE THEN
      aw_enable := AUTO_CLOSE >= T#5s;
      wd_time := SEL(X.LOAD_TIME_MAX > T#0s, T#5ms,X.LOAD_TIME_MAX);
      fn_last := fn; (* aktuellen Dateinnamen speichern *)
      IF X.ID_MAX = USINT#0 THEN (* nur einmal nach Satellitenbausteinen scannen *)
         X.ADD_COM := 01; (* ADD INFO *)
         X.STORE_TYPE := BYTE#2; (* CSV-Modus *)
      END_IF;

      step_1 := 10;

VincentVega

Nochmal : Top Arbeit die hier geleistet wird, arbeite immer gerne mit den Libraries.

Das mit der Überschneidung Daten / neue Datei ist mir später aufgefallen, nachdem ich das Ganze
auf ein Logging unter Verwendung von _BUFFER und SysFileWrite umgebaut habe.
Nun schreibe ich alle 5 Minuten die Daten in den Puffer und dann sofort in die Datei.

Das ist bei weitem nich so elegant wie mit DLOG, aber für meine Zwecke reicht es hier aus.

Im Grunde liest der PFC nur 32 * 4 Leistungsmessklemmen über Netzwerkvariablen ein und loggt die
Mittelwerte in der CSV.

Alle 30 Minuten wir dann per FPT_CLIENT die Datei verschickt.

Läuft jetzt, aber ich werde gerne in Zukunft DLOG verwenden.

Nochmal zum Verständis :

Wenn ich z.B. ein Array mit 32 * 7 Werten loggen möchte, muss ich dann für jeden SPALTENNAMEN eine eigene
Instanz von DLOG_REAL verwenden, oder löst DLOG_STORE_CSV die Struktur X intern nach Spaltennamen auf,
es handelt sich ja um 32*7 unterschiedliche Spaltennamen ?

Also entweder 1 oder 32*7 Instanzen von DLOG_REAL ?



peewit

nachdem du gerade mit dem thema "nutzung von vielen dlog_real" beschäftigt bist
gebe ich dir ausnahmsweise vorab einen baustein der genau die aufgabe einfach erledigt

der dlog_real_array besitzt eine datrnstruktur für 64 real werte
dort kannst du spaltenüberschriften und real_werte eintragen
am baustein kannst du noch angeben wieviele real werte du nutzt (64 max)
durch mehrerer dieser bausteininstanzen kannst du dann jweils 64 real werte loggen



[gelöscht durch Administrator]


VincentVega

Vielen Dank. Werde ich bei Gelegenheit testen, das Projekt läuft schon beim Kunden.

Habe einen IPC-C6 über, damit probiere ich es aus.

Gruß
vince