I don’t know if this is a common occurrence or not. When running jobs after a decent amount of code has ran (like 2-3 carved signs) the arduino (grbl .9g) becomes very unresponsive. So for instance an normal G sent is followed up by an OK relatively quickly. When it gets to the point of unresponsive, a sent code can take upwards of one minute to be executed. Reseting the arduino, killing the json server, and refreshing chiliPeppr helps (until another job is ran), but does not fix the problem. A reboot does fix the problem. Could be a windows COM issue. I was just wondering if any of the other windows grbl users here have the same problem.
i haven’t seen that, but I’ve been putting off upgrading GRBL to 0.9 after I keep reading of all the problems folks are having. Can’t say that I’ve seen anything like that with 0.8 though.
also, the Serial port console can get really big… i’ve heard John recommend just disabling the serial port console on weaker machines… perhaps that is where your slowdown in the browser is coming from. Something to try anyways.
It’s hard to really know what is slowing you down. I’ve run really long jobs and things have been fine, but I do know that the browser can get bogged down. Disabling the 3D viewer can really help as it saves about 50 to 70% of the CPU processing. I wouldn’t worry about the serial port console as that auto-truncates, but that disable button in the serial console can save you about 3% processing.
I am still working the issue where the new garbage collection on SPJS seems to be too intense for the Raspberry Pi. That causes a disconnect on the websocket, although your job does keep running ok.
I’ll take your suggestions to the shop with me on Monday and report back.