Skip to main content
D
draco
Explorer
December 6, 2024
Solved

How to reset the time in saved log file?

  • December 6, 2024
  • 1 reply
  • 1310 views

Hallo,

 

I am saving the log files of the chart in the CUBEMonitor software. I read certain values from the MCU through Cube Monitor and save them as .CSV. However I've noticed that the first file I save after opening the software does start from 0 seconds. In case I stop the data acquisition and clear the chart and start it again. A new log file is created with advanced time i.e. although the chart does show the time scale to be from 0 seconds. 

This problem doesn't occur if I restart the software, but it is tedious everytime to restart the software. Is there a way I can reset the time for every acquisition made?

 

Thanks

      This topic has been closed for replies.
      Best answer by stephane.legargeant

      Hello @draco 

      The time of the logs are set to zero for the first log element after starting the tool.

      The exact behavior is :Launch tool or deploy flow, then start acquisition -> the log timestamp is set to zero when the first data is stored in the log file. The timestamp will never be reset after. (until tool restart or new deploy)

       

      For the graph, it is reset at startup or when a "clear" message is received (topic="clear").  But the "clear" message is not managed by processing node, so timing is reset only at launch or "deploy"

       

      One workaround is to re-deploy the flow to reset the log counter. You may have to move an element in the flow, and then you can click on deploy. This is faster than restarting the complete software.

       

      I am discussing within CubeMonitor team on how to improve for long term. There could be different solutions  :

      • Start each log file with timestamp at zero. ( Independent of chart time )
      • Have the possibility to reset the timestamp with a "clear" message ( similar to the chart "clear"). with this option, chart and log file would have aligned timing. 

      @draco : would it solve your point ?

      Question for everyone : what would be your preferred option ?  Would it be an interesting improvement for your use cases ?

      Best regards

      Stephane

       

      1 reply

      S
      stephane.legargeantAnswer
      ST Employee
      December 10, 2024

      Hello @draco 

      The time of the logs are set to zero for the first log element after starting the tool.

      The exact behavior is :Launch tool or deploy flow, then start acquisition -> the log timestamp is set to zero when the first data is stored in the log file. The timestamp will never be reset after. (until tool restart or new deploy)

       

      For the graph, it is reset at startup or when a "clear" message is received (topic="clear").  But the "clear" message is not managed by processing node, so timing is reset only at launch or "deploy"

       

      One workaround is to re-deploy the flow to reset the log counter. You may have to move an element in the flow, and then you can click on deploy. This is faster than restarting the complete software.

       

      I am discussing within CubeMonitor team on how to improve for long term. There could be different solutions  :

      • Start each log file with timestamp at zero. ( Independent of chart time )
      • Have the possibility to reset the timestamp with a "clear" message ( similar to the chart "clear"). with this option, chart and log file would have aligned timing. 

      @draco : would it solve your point ?

      Question for everyone : what would be your preferred option ?  Would it be an interesting improvement for your use cases ?

      Best regards

      Stephane

       

      D
      dracoAuthor
      Explorer
      December 10, 2024

      Hi @stephane.legargeant, 

      I think that solutions provided will work.

      The option to restart the timer at 0 at chart and logFile would be a great idea as sometimes in past I did have certian measurements that I ran although the data was being pooled all the time.

      Nevertheless, more options does provide flexibility to other use cases and thanks for the hint of re-deploying the flow. That will work for now!

       

      Best regards,

      Melwin

      Terms & ConditionsAccessibility statement