Bug? Going into SD card menu creates new log file.

[ryanneve]

Subject of the issue

If you go into the main menu's SD card sub-menu, the OLA will always create new a log file.

Steps to reproduce

This behavior may be on purpose, but I'm not sure why. It would be easy to fix. I can push the change.

Expected behavior

If it's not time to generate a new data file based on the setting of openNewLogFilesAfter, going into a menu shouldn't do it.

Actual behavior

We would like to have daily logs, but we want to use the SD card menu to regularly download the data collected so fat to upload to a website. This leads to the daily data being broken up into multiple smaller files.

the Fix

I think you could just comment out thestrcpy()calls as below and the OLA would keep using the previous log file until it's time to open a new one.

        if (online.dataLogging == true)
        {
          //strcpy(sensorDataFileName, findNextAvailableLog(settings.nextDataLogNumber, "dataLog"));
          beginDataLogging(); //180ms
          if (settings.showHelperText == true) printHelperText(false); //printHelperText to terminal and sensor file
        }
        if (online.serialLogging == true)
        {
          //strcpy(serialDataFileName, findNextAvailableLog(settings.nextSerialLogNumber, "serialLog"));
          beginSerialLogging();
        }

Both beginDataLogging() and beginSerialLogging() look like they handle opening existing non-empty files.

[PaulZC]

Hi Ryan (@ryanneve ),

Apologies for the very slow reply. (I hope all is well and that you escaped the worst of the winter storm.)

There's something at the back of my mind saying that opening a new log file was both intentional and necessary. I think because changing some of the SD card settings absolutely requires a new file to be opened. It was easier to always open a new file than to figure out which options need it and which don't.

I'll add this as a feature request, but I can't guarantee if/when we'll be able to implement and test it.

Very best wishes,
Paul

[PaulZC]

Hi Ryan (@ryanneve ),

This is resolved in v2.5 with Tony's PR #146. Thank you @whipple63 .

Apologies - I reverted the reset-log-count changes as I couldn't find a 'nice' solution for that.

Best wishes,
Paul