I had a question actually.

I had a question actually. Sometimes chilipeppr starts to stutter and starves the machine for data. This mostly happens if you have some trochoidal slotting paths that use tons and tons of small arcs. I’m not sure whether it’s the 3d viewer, the serial port console, or the actual sending. It also seems to happen more often if chilipeppr isn’t the active tab in the browser.

This is with the SPJS running locally on a Macbook Air and chilipeppr in Chrome. I usually have to resort to using multiline upload, even with the 3d viewer and serial console disabled. I don’t like this because it introduces a long delay in the feedhold button, making it basically useless.

Are there any obvious performance tweaks I can do to help this?

a bit offtopic but for example in jscut you can reduce the minimum amount of segment, that may reduce the number of lines needed to define an arc.

Well, a screenshot during the stuttering would have helped, because it’s really key to keep SPJS loaded with lines. It can handle up to 200,000 lines in memory so you should push it to about 100,000 lines. My gut is telling me you are starving SPJS and thus TinyG of Gcode lines because you’re uploading them too slow. I would bet that your SPJS queue sits at 0 most of the time which is pure starvation.

to me it happened without starvation of the buffer… just too many very short segments to create an arc, but I would say that that it is more of a g-code generatio problem than a SPJS issue

@Simone_Marin your issue then would have been that if SPJS can only feed the microcontroller at 115kbaud then that is a ceiling.

good call, i ll take a video on next cut

@jlauer Yeah, upping the multiline seems to work, but then a feedhold seems to get stuck in the same queue. The feedholds bypass the planner queue in G2, but they don’t seem to bypass anything in SPJS (which I assume is just a straight buffer upload). As a consequence, hitting the feedhold button in chilipeppr can then take like a minute to respond, which is really bad. (This might be alleviated by using the hardware feedhold input that should be functional in the latest G2 edge, though. I think I prefer a physical feedhold button anyway since you can mash that a lot faster than you can click a UI button.)

Feed hold does bypass the queue in spjs. The slowness you see is from the TinyG guys. My main feedback to them for last 6 months is slowness of feed hold and I would suggest you add to the fire as well by posting to them.

I also have some issues with stuttering or the machine beeing stuck for minutes. I mean the machine stops moving during a milling job and chilpeppr and chorme are also stuck. I can not click any buttons nor enter commands.
Any idea on this issue?
(g2core on Arduino Due, Chrome on Windows 10, newest SPJS version)