To be able to capture large amounts of data it would be nice to have multiple log files downloaded automatically to a memory stick. The only way I could implement this was to write the log file to the memory stick and then read it back in to copy to another file. This used a counter to produce a series of files. Is it possible to access the logfile via a script to simplify this process?
In a previous answer to a similar post a directory was specified: /fs/etfs/script.
What is the relevance of this directory?

You can open and read text files via scripts using the file object add-on
http://www.angelcode.com/angelscript/sd ... _file.html
The add-on is already included.

If you create a text file from a script it will be located in the directory "/fs/etfs/script"

Thankyou for the reply.
Yes, but what I wanted to know was if it were possible to access the file that the Data Logging application is writing. Then when the file has reached its Max Log Size it could be copied to a memory stick and then logging could recommence.

You cannot access the logfile inside the display.

You can monitor the variable "UserDefinedVariable.Datalogger.LogSize" and execute the action "Datalogger.Output" to copy the logfile to a usb drive when it reaches its maximum size. After that you can execute "Datalogger.Clear" and "Datalogger.Start" to continue logging data.

When the logfile is in the usb drive you can use the functions "copyFromUSB()", "copyFile()", and "CopyToUSB()" to change the name of the logfile in the usb drive.

Is this what you are doing already?

Regards,

ksaenz

Is there any chance we could get an example of how to construct the renaming of the log file so multiple log files can be stored on a usb drive?

tthomas wrote:Is there any chance we could get an example of how to construct the renaming of the log file so multiple log files can be stored on a usb drive?

Hi All,

I need to do exactly the same. IS there any way to rename files automatically using an index or something similar?

Thank you in advance,

Hello,

There is not a direct access to the data log file. You will have to do what is in the previous post

The only way I could implement this was to write the log file to the memory stick and then read it back in to copy to another file.

Here is a simple config that assumes there is a file on the USB with the filename "LogFile.csv" which is the default file name for the data logger. The file is copied from the USB into flash memory on the display.

A string variable is manipulated to have different values used for a new file name. The file in the display memory is copied to the new filename and then copied out to the USB.

To do this with any file, it is important that the display has enough remaining memory to accomodate two copies of the file.

Thank you for your answer Sara.

Finally, it is working well and now I can generate several logged files.

For my application it would be interesting if I can keep the files also in the flash memory from the display. Is it possible? I assume that if yes, I have to manage the available memory in the display.

I am imagine that my customer probably looses the USB stick, and I need to recover the logged files...

Best regards,

Hello,

We always imagine the worst, don't we?

You can keep files in the flash memory, just like the data logger file is kept in memory.

If your display is a PV780, you have about 2Gigabytes for the configuration and data files. HOWEVER, using the data logger with the 500 milliseconds update, a moderate amount of saved parameters and sized config, it can add up. As I mentioned previously, copying the files means using twice the memory.

One of the things that I didn't do in the config I posted was to delete the file that was copied over from the USB. It wouldn't be needed after being copied to the other file and put on the USB.

Memory management is extremely important and mostly left to the config writer when manipulating the files in flash. Corrupting the file system by going over the available flash memory is a dead display.

PV450s doesn't have as much memory to work with, so be even more cautious with it.