cheton
commented
7 years ago // https://github.com/cncjs/cncjs/blob/master/src/app/controllers/Grbl/GrblController.js#L112
this.sender = new Sender(SP_TYPE_CHAR_COUNTING, {
// Consider periodic commands ('$G\n', '?') to make sure the buffer doesn't overflow
bufferSize: (128 - 4) // The default buffer size is 128 bytes
});Grbl has 128 bytes of buffer space by default. I deducted 4 bytes from the buffer size to exclude periodic commands (i.e. len('$G\n') + len('?') = 4), but I'm afraid that may not be safe enough to prevent from buffer overflow.
Could you provide me the following information? Thanks.
- Which version of cncjs you're currently using
- Your Grbl version ($I) and settings ($$)
- Attach some of your g-code file files that can even sometimes reproduce the buffer overrun issue
-
Try change the buffer size lower than 124 and test again. That said, a buffer size of 120 bytes should be safe enough. You have to find actual file location this way:
$ dirname `which cncjs` /Users/cheton/.nvm/versions/node/v6.9.4/bin $ cd /Users/cheton/.nvm/versions/node/v6.9.4/bin $ cd ../lib/node_modules/cncjs/dist/cnc/app/ $ vim index.js // Find the line of "bufferSize: 128 - 4"
andrewismoody
I'm not 100% sure on this, but I've been troubleshooting an issue with my gcode files being sent to GRBL incorrectly. I get weird responses back about missing words and incorrect number fomats, which leads me to believe the buffer is overflowing. I poked around quite a bit today trying to understand what's going on, and the best I can tell, the issue is with the periodic status queries that are sent on a timer outside of the sender queue, written directly to the serial port. I'm looking at GrblContoller.js, line 319 and 324. I don't think, the way it's written, that these commands are being counted toward the buffer count. I think it would be better to inject them into the sender queue and allow the buffer counter to include those bytes to prevent buffer overflow. But I might not be reading it correctly. After thinking about this for a few minutes, I thought that maybe the status queries should be injected at regular intervals into the sender queue as part of the file parser. This would eliminate race conditions and the hypothesized buffer overflows as well. Or maybe once every time the sender queue while loop is entered so it doesn't get called too frequently for many very small commands.