Still having issues with the OX machine stalling in the middle of a job. Running the tinyg version 440.20 and SPJS 1.86. Here’s a video of it stalling. Hitting pause takes several seconds to take effect. It’s like the controller buffer is being starved or something. Any ideas?
I can’t see any video? It’s like it wasn’t uploaded when you posted.
I don’t see it either. I’ll try a link.
It looks like perhaps you changed your defaults to something too slow with respect to how quickly lines are sent to your controller, or your Gcode is of the nature where it needs way more upload speed than the default. From the video it looks like you may still be on the default of 50 lines each second. Maybe your corners are so badly generated from your cam software that they chew through massive lines of gcode to get almost nowhere. Your straight lines seem good and thus the timing of the Gcode widget should keep up. So, to solve this just double/triple/quadruple the amount of lines uploaded on each interval. Make this change under the cog wheel icon in the Gcode widget.
Yeah it was on 50 lines per second. I changed it to 100 to see if that helps. The corners are arc segments and they don’t look too bad. The gcode was generated with Cambam. It’s usually an issue with more detailed jobs like guitar body outlines, 3D carved tops, etc, which makes sense. This project is a bunch of letters for a sign and the outlines are fairly complex. Thanks for the help John.
I also see buffer starving sometimes when other stuff is running on the ChiliPepper computer. You might confirm that there are no other app using CPU, and perhaps turn down the 3D frame rate.
I was thinking that may be a possibility as well Matt. This is a dedicated computer for the CNC, and I only run Chrome, SPJS in a terminal window, and I have my file browser open. I’m also running Xubuntu so the OS is pretty light on resources.
So far so good here on upping the lines per second. Nice and smooth so far.
I wonder if there is any way to detect this. Could CP detect if all the GCODE lines have completed with ok responses before the next set is being sent? If so, a warning overlay could show up that you could click for more info.
There could possibly be a way to detect, but it might be easier to just up the default settings which I think are 25 lines each 1 second. Maybe we jump to 100 lines each 1 second as the new default.
I had never looked at the setting and it was 50 per second so I assume that was the default. 100 seems to be working well for me. How big is the buffer in the TinyG?
That doesn’t feed the TinyG buffer, rather it feeds the Serial Port JSON Server buffer which is allowed to have 200,000 lines in it.
Right, I forgot about the SPJS.
I think it must have been the browser that wasn’t feeding lines to SPJS quick enough. I find that the browser gets extremely laggy as a job progresses. Looking at it right now the coordinate display updates maybe every 10-15 seconds. Is this normal behaviour or is my computer just a POS?
In the end though, it would still be dependant on the GCODE not having tons of lines that take almost no time to execute.
The browser lags or doesn’t lag depending on the complexity of the gcode. I have found that if you have a basic gcode file around 500k or less things are fine. When you get near 1mb or higher, you have so many points in your 3d view that the frame rate updates put your browser and computer at the upper limits of today’s computing power and browser capabilities. So, this more has to do with the complexity of your gcode file and the amount of points in the file. Keep in mind though that complexity is even more so based on g1’s vs g2/g3’s because every g2/g3 arc creates 24 additional points. So it’s not based on the amount of lines or size of the file, rather the amount of points generated.