Logging
-
+1 for this feature, but only if it will not affect print performance.
Also it's possible to write counters in log (filament length printed, total hours of print time and so on).
edit: g-code commands to write something into logfile or to redirect next command output into logfile also would be helpful.
-
Yes, this would be fantastic. Perhaps this could be integrated into the G-Code Console section in the web interface, so that you see previous messages that occurred while the web interface wasn't even loaded, and which persists after closing and re-opening it.
-
I agree this would be very helpful. If it does not impact performance too much having a file for "information" such as counters and cumulative log for "errors/notifications" would make it easier to assist with troubleshooting.
-
I also check the results of the command M122 from time to time, it would be helpful if M122 will be able to write results into log file after print finished.
-
Perhaps this can be combined with an option to recover after power failure?
Although I realise there will have to be a hardware component to this. Like a small battery.
-
The real question is: how difficult is it to write to the SD card while also doing time-critical things like moving stepper motors?
I am picturing making available to the code a "log" function that takes a string. It has to be quick so that it can be called from anywhere, so it can't actually do any writing to the SD card. But it could store the message to a modest-sized buffer, and the buffer could be written to the disk when there is time, just as file transfers are.
Similarly, a machine-state file could be updated in memory and written to SD card when there's time. Recovering from power failures would mean keeping the 5V circuit alive long enough to use the pause mechanism and then write the saved state to disk.
-
The latency when writing data to SD card is very variable. It will be a lot easier to implement logging when we use a RTOS in RepRapFirmware for DuetWiFi. Unfortunately, on the older Duets there is not really enough RAM to use a RTOS. So it will become much more expensive to keep the firmwares for the different Duet variants in step.
-
Ah, I see from looking at the code that fatfs doesn't offer any kind of non-blocking write, so one dare not write to the SD card while printing. That does complicate things.
-
A few firmware versions ago I added support for an idle callback function while the file system is waiting for DMA to complete. So it should be possible to keep the Move system running while writing the log file even without using a RTOS.
-
Ooh, that would be great. In the meantime, though, the G-code console is an okay log for when the web browser is connected. Would it be possible to add a button to the web interface to save that log to disk? That would be something users could attach, maybe with M111 active, when they were reporting problems.
-
I have asked Christian to look into adding this to DWC as an interim measure.
-
Any uodate on this?
I checked all open and closed DWC issues, but found no mention:
https://github.com/chrishamm/DuetWebControl/issues?utf8=%E2%9C%93&q=is%3AissueWould it be too burdensome to add all feature requests as issues on github? I can see the advantage - mainly to the community - and the disadvantage to the devs - especially if its down to devs to add such requests as issues. On the other hand, not doing so increases community effort to search for requested features and dev time explaining on the forum that a feature is already requested or in the pipeline; interested to read your thoughts.
-
I'll look at adding logging in the 1.19 release for the Duet WiFi and Duet Ethernet. I'm planning to switch to use a RTOS for that release, which along with the extra RAM available will make logging easier to implement.
-
Great, thanks dc42.
