More logs ! :)

[amoineau]

Describe the solution you'd like

Hi !

In order to better understand the problems the operator is facing and how he is using the application, we would like to get the logs. I've noticed that there is already logs being saved but if I understand correctly you only save the 5 last sessions. However, we often close the software when not needed, plus, when there is a problem, the first thing we try is often closing / reopening the software. So, unfortunately, most of the time 5 sessions don't cover more than half a day.

Would it be possible to have a folder dedicated to logs, that would save as many logs as we want ? Until we clean it up.

Also, a weirder request : would it be possible to have an indicator of how much time the spindle was ON, like a mileometer on a car ? In our case the spindle is mostly used for a laser, and lasers like the one we use need to be recharged in gas after a while. So, for maintenance purposes, we need to be able to know how long it has been running. It can be very vaguely estimated and it can be based on the time up, the distance travelled with the spindle on, the [size of the file] x [% executed] or anything you can think of. Really, any solution you could offer is welcomed.

Thank you for considering my requests.

[svenhb]

Check new release for logs and spindle rum time counter: https://github.com/svenhb/GRBL-Plotter/releases

[amoineau]

Thank you for this great update ! I'll try it today :)

[amoineau]

Would it be possible to have a log for the other serial communications ? With rx, tx and the timestamps if possible ? It would really make the diagnostic complete if we could match the commands sent to the 3rd console with what is happening in the other logs.

Just to make sure I understand correctly : the difference between logSendBuffer and logStreamGCode is that the first is updated in real time to match what is actually sent, while the second is simply a copy of the gcode made when the file is opened ?

[svenhb]

logStreamGCode is the whole gocde from the editor. logSendBuffer logs the just sent code lines and fills up during the streaming. When streaming is finished, both logfiles should show identical content (also the logGrblEcho file)

[amoineau]

Hi,

While looking for an exception that crashed the software :

I noticed a recurring warning in the logs :

Warn  | GrblPlotter.ControlSerialForm  | processGrblOkMessage  fix overflow  IndexConfirmed:6  Count:5

And a recurring error :

Error | GrblPlotter.ControlSerialForm  | ### grblBufferFree too big! 255 rx:'ok' in processGrblOkMessage() - fix | last RX:'$$' RX-1:'$10=2' RX-2:'$10=2'

The warning can take various value of Index and Count and seems to always be preceded by the error, something like that :

Error | GrblPlotter.ControlSerialForm  | ### grblBufferFree too big! 255 rx:'ok' in processGrblOkMessage() - fix | last RX:'$$' RX-1:'$10=2' RX-2:'$10=2'
Info  | GrblPlotter.ControlSerialForm  | sendBuffer snt:  0  cnfrmnd:  1  cnt:  4  BFree:255  lineNr:0  code:'$$' state:alarm
Info  | GrblPlotter.ControlSerialForm  | strmBuffer snt:  0  cnfrmnd:  0  cnt:  0  BFree:255  lineNr:0  code:'' state:alarm
Info  | GrblPlotter.ControlSerialForm  | Feedback> [VER:1.1ISP.20170802:] 
Info  | GrblPlotter.ControlSerialForm  | Feedback> [OPT:VNMZT,35,255] 
Warn  | GrblPlotter.ControlSerialForm  | processGrblOkMessage  fix overflow  IndexConfirmed:5  Count:4

or that :

Error | GrblPlotter.ControlSerialForm  | ### grblBufferFree too big! 255 rx:'ok' in processGrblOkMessage() - fix | last RX:'$G' RX-1:'$G' RX-2:'$G'
Info  | GrblPlotter.ControlSerialForm  | sendBuffer snt:  1  cnfrmnd:  2  cnt:  1  BFree:255  lineNr:0  code:'$G' state:idle
Info  | GrblPlotter.ControlSerialForm  | strmBuffer snt:  0  cnfrmnd:  0  cnt:  0  BFree:255  lineNr:0  code:'' state:idle
Warn  | GrblPlotter.ControlSerialForm  | processGrblOkMessage  fix overflow  IndexConfirmed:2  Count:1
Warn  | GrblPlotter.ControlSerialForm  | processGrblOkMessage  fix overflow  IndexConfirmed:1  Count:0 `

I don't think the crash and this error are related at all because the crash is exceptional while the error in the log happens very often, I just wanted to share both and ask if you had any idea about one or the other ?

Edit : Considering our discussion on the other issue, I'm thinking it my be related to the "invisible alarm" buffer situation and might be fixed in 1.6.4.0. Sorry if that's the case.

[svenhb]

I know this recurring error - I hope it has no effect. Problem: I received more 'ok' from grbl as expected.

I think the screenshot is more important - I have no clue what the reason is, because I get no information where it happens - usually I get file-name, method-name and line number. Any idea what you did, when the error appeared?

[amoineau]

I wasn't the one using the software but I think I have the right log : log_20220105.1.txt

line 2590 you have the exception with the stack trace, surrounded by a lot of streaming errors...

Hope it helps :/

[svenhb]

This could help - thanks

[amoineau]

Also, in the logs, the buffer size tend to switch between 127 and 255 quite randomly. Is it normal ?

[amoineau]

The main form ThreadException happened again while I was using the machine. It was a different file than last time. I did it a first time without problem and it happened at the end of the second run. Nothing specific happened before, I just :

• Opened GRBL Plotter
• Did a homing
• Opened the file
• Ran the file

But at some point this happened : I don't know if it has anything to do with the issue.

[amoineau]

The problem hasn't occurred since then and it wasn't the topic of this issue, so maybe you can close it if you want to clean up your issues. Should it come back, we can always open a dedicated issue.

Thank you for the logs, it has really been helpful.

[svenhb]

More logs are implemented