DLOG_STORE_FILE_CSV questions

Begonnen von AntonZan, 04. Februar 2018, 18:23:17

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 1 Gast betrachten dieses Thema.

AntonZan

Apologies for writing in English, I'm not very fluent in German.

I find myself using the data log functionality all the time. Mostly writing to files on local flash memory, using FTP every now and then to read log files when issues have been reported. It is a very useful tool for me. There are two features that I would very much like to see added to the data logger.

First, I'd like to be able to switch logging on and off. Having it switched off most of the time, switch it on for a while if problems are mentioned, gather some data, switch it off when the issue has been resolved. I know I can enable/disable calls to the function blocks or triggers (this is actually what I currently do). But due to buffering of writes, disabling it entirely causes the last buffer to not be written until the next time the function blocks are reenabled. Or it gets lost at a power cycle. And if I only leave out the trigger, then a new empty file is written anyway when the file name changes (I mostly use daily filename change, sometimes hourly). This would lead to filling up the file system with mostly empty files. Implementing an automatic cleanup routine that deletes older files is an option, but not an elegant one IMO. And it would cause a PLC to constantly write to flash memory, not good for longevity.

Second, and somewhat related to the first, I want the ability to force a write. When I make updates to a PLC program that cause a fresh download, the currently buffered data are lost. Or I have a program that only writes data when some feature is running but since it is not running all the time, it does not always write. It can thus take a long time for the last chunk of data to actually be written to the file system. For me it would be very useful if there were a means for "overriding" the write buffer and trigger a write to the file system despite the buffer not being completely filled.

Not sure if these requests fit in with the structure of the components. If it is an easy addition then please take these requests into account.

I'm also open for hints on how to make my own modified versions if you feel these changes would overcomplicate things for most users.

peewit

hello

1.
the first point is rather complicated and I don't have a good idea.
I didn't integrate the automatic deletion of old files because there are simply too many different types of application and also because not all platforms support the search for files. when transferring via FTP etc. there is the automatic deletion after transfer.

2.
with "auto_close" you can specify the maximum idle time from when the data buffer is to be written. also disabling the data logger triggers
a data write.

3. Please also use the latest oscat_network 1.35 beta.
    http://www.oscat.de/community/index.php/topic,2546.msg13223.html#msg13223


AntonZan

Thank you very much, peewit, much appreciated. I will get me the 1.35 beta version and dive into the code to see if I can make it do what I want. If it comes to something useful, I will report back with my changes.

Also once more a big thumbs up for the Oscat libraries. They serve me in two ways: as useful additional tools in my toolbox, and as a source of inspiration to make my own.

AntonZan

Just a quick note to confirm that the DLOG_STORE_FILE_CSV block from the 1.3.5 beta version does work very well indeed for my needs. Thanks again peewit for your help, much appreciated.


Deviating slightly from your suggestion in this post, I have set NETWORK_BUFFER_LONG_SIZE to a value of 8191. There is probably a good reason for the original to be 4095 = (2^12)-1, so I made my version 8191 = (2^13)-1.
VAR_GLOBAL CONSTANT
   NETWORK_BUFFER_LONG_SIZE : UINT := 8191;



Also, I get plenty of warnings about slightly different types between OSCAT_BASIC and OSCAT_NETWORK. Implicit type conversions and "possible change of sign". From INT to UINT, DINT to UDINT, UINT to INT, INT to UDINT, pointer to BYTE and pointer to DWORD/UDINT, etc.  One of either might need to be adapted for a better fit between the two libraries. Thinks working despite the warnings, but I'm only using a small portion of the network lib at this time.


Last but not least, the released version has documentation translated to English. So far docs for 1.3.5 are German only. That would be just about the only thing missing before release as far as I'm concerned.
Thanks again, Oscatters 8)