1
Modulentwicklung / DLOG_STORE_FILE_CSV questions
« am: 04. Februar 2018, 18:23:17 »
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.
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.