I am new here and looking to purchase the new MK2, so reading about gSender as a good choice for sending gcode is comforting.
So, in gSender, how many lines of code can be spooled without reaching a limitation, that may cause a pause in toolpath movement?
Thanks to all that reply.
@RustyR Rusty: As far as I know there are no file size limitations in gSender itself. It may depend somewhat on the capabilities of your PC. However, I could easily be mistaken. 
I’ve moved your question to the gSender category of the forum. While the techs at Sienci monitor all the categories of the forum, there is a group there that specifically deals with gSender issues and questions and having your question here will bring it to their attention.
Thanks @gwilki , I have several questions about gSender so I will go find that category.
So this question is a little unclear, but I’ll take a stab at it.
gSender itself doesn’t have a limit on file size/number of lines for a program. Most hobby CNC files tend to be on the smaller size, but our test files include examples as large as 29mb/1.5 million lines, and I know files even larger than that have been successfully run on the platform.
The GRBL firmware does, however - it can hold at most 16 different lines totaling 128 bytes (where one character from a line is a single byte). gSender tracks this and takes care of it for you though - like most sender software options - it won’t send a line until it knows it won’t overflow the planning buffer.
Any sender software that supports GRBL will work similar to the above.
Hopefully that covers what you’re asking, but if not feel free to clarify.
Kevin
@KGN Tks much for this, Kevin. The same issues was raised on the Facebook page and incorrect information was provided - not by you, obviously. I copied your reply there.
Thanks @KGN , greatly appreciated. In a previous home-built cnc router life my gcode files were over 500,000 lines of code, running Mach3, with no issues/no pauses. Moving forward to put together a MK2 Longmill and using gSender I just want to identify if there will be any gcode streaming issues because I will be doing similarly as large of gcode files. I can always adjust my designs and tool paths to make provisions for any glithes.
@KGN Kevin: Since you posted, I’ve been reading and trying to understand more about this limitation in grbl.
Just as a matter of interest, if somehow there was one line of gcode that exceeded that 128 character limit, would that freeze grbl, or would gSender simply split the line into smaller chunks?
We don’t do line splitting, just character counting per line. There is not a realistic scenario where a single gcode line is 128 characters or longer of actual gcode words where that would matter, and splitting lines could result in non-functional commands if not done 100% correctly and is generally a bad idea.
I don’t want to get too deep into how serial buffers work, but you can think of the GRBL RX buffer like a long tube - information (characters) go in from one end (the sender) and the tube fills up. The firmware grabs those letters off the other end of the tube one at a time until it has something that it recognizes as a complete gcode line - this is indicated by a newline (\n character). It then processes that line, sends either an OK or an error, and will repeat the process.
If the firmware never sees that newline, the tube just fills up. At that point it will stop grabbing characters since the firmware itself tracks how many characters are in the buffer and knows it’s full. However, since it doesn’t have a complete “line” yet that it can process, it just waits for a newline that will never come - this would be seen as a “freeze”. The sender wouldn’t send any more information since it’s tracking the number of characters sent and knows it’s at 128 without hearing an “OK” response that means a line has been processed and it can send more. The firmware also won’t process the information it has in its RX buffer since as far as it’s concerned it doesn’t have a complete line yet since it hasn’t seen a \n newline.
In that situation, both side would just sit there - GRBL won’t throw an error since it doesn’t think it has a line to process yet, and the sender is waiting for a response from the firmware before it continues sending information.
In a real-world situation this won’t matter since it’s not really possible to have a valid gcode line be that long.
We did fix a regression in gSender where comments weren’t properly being removed from the gcode before being sent to the firmware that could potentially cause this issue - gcode words themselves won’t be that long, but gcode words followed by a very long comment might. That’ll be fixed in the next build.
The above example is very simplified since technically GRBL has two different buffers (one for receiving, one for planning) but that probably covers what you’re asking I hope.
@KGN It definitely covers what I was asking about. Tks much, Kevin.