Logging
-
Most Duets will have SD cards with gigabytes of space and fast transfer rates. How reasonable is it to log everything to a file on the SD card?
I am thinking of all the things that appear in ephemeraly pop-up windows, plus things like network problems (where there's no direct way to let the user know) or boot failures. I realize that the Duet doesn't know what time it is (unless someone feels like implementing NTP), but even a stamp of "time since boot" would help identify problems.
I'm picturing, for example, a log that included both "0:08:57 File calicat.g started printing" and "0:35:22 Stall detected in X stepper" or "0:35:22 Thermal shutdown of X stepper driver". I realize those last two probably aren't available as messages at the moment (though I bet that's available over SPI from the stepper drivers) but certainly thermal shutdowns and warnings are known by the firmware and logging them to SD card would make tracking down thermal issues a lot easier. Or if autoprobe output was logged, a user with calibration problems could go back and see how stable the autoprobe settings had been for the last ten or twenty prints.
If log files risk becoming awkwardly large, they could be renamed to a numbered sequence, perhaps even on every boot. (That is, the current log is duet.log, and there are a series of previous ones duet.log.0, duet.log.1, …)
-
I could appreciate a feature like this at times, as long as it doesn't sacrifice any performance of the motion system. I know that previously, simply reading from the SD card would interrupt the print momentarily.
-
+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.
