It seems that we always ask for the log file whenever people run into issues that we try to solve.
Would it make sense to create a parser for the log file? It could implement several features for analyzing the log file. I would implement it as a online tool for people to upload their file to and get feedback on.
Brainstorm thoughts:
Output a gcode file from the log (Would that even be possible?)
Warn about decimal resolution being to “high”
Output where the “buffer” keyword is found, including the previous / next 5 lines for each hit.
Let me hear what you think about that. I would be able to create a proto type of the this to show of, before we spend to much time on it.
Why do we need the constant out flow of:
[PE:0.09,0.19,64]
<Idle,MPos:33.51,2.86,-13.00,WPos:0.000,0.000,0.000>
?
It’s kind of annoying testing grbl compatibly and checking the logs, plus creating a huge log file.
We either need a simpler log file, only containing the information we need to troubleshoot or we need some tools to help us doing the initial analysis.
Theoretical via script, yes.
Challenges: To catch “sending” as well as “ending” with the missing ‘S’ and the lines with gcode that don’t have a sending or ending in front. From a linux perspective all tools needed are installed by default.
Edit: sure this can be done via batch on window as well
Still had to remove a lot of text like ‘turning spindle of or on’, ‘not supported and ignored’ and other stuff.
The buffer overflow needed to be removed. Looks good from a quick view, but has issues. No time left today. loggcode.nc (127.4 KB)
We either need a simpler log file, only containing the information we need to
troubleshoot or we need some tools to help us doing the initial analysis.
we don’t know what info we need in the file until we have a description of the
problem
What about 2 log files?
what do you put in one rather than the other?
issues tend to come is bursts, we start having people run into a problem, we
diagnose it and implement a fix, and that problem stops showing up as much.