gCode sending too slow? CNC stutters...

[McNugget6750]

Hey guys,

Great work on this, I love the software and I have been using it for quite some time now. However, I noticed when milling PCBs with it, very small segments get stuck and the mill comes to a halt in a regular basis.

At first, I believed it was a MARLIN issue because it's been known for a while but my research shows this has been fixed. Since I want the mill to run smooth the entire time I got GRBL for Cyclone to work since I'm working on a Mega256 + RAMPS1.4.

Everything works but I still get the same stuttering with very small line segments.

This couldn't be, and since I already developed my own fast gCode sender for my grbl based laser cutter controller and I knew what the behavior of the CNC under buffer underrun looks like, I started digging into your java code to check if I could optimize the gCode sender.

However, I can't find it. Where do you store your gCode list after optimization? Where do you actually run through the entire list and send all the commands? Where do you wait for the ok from the controller firmware?

Since I already have a strategy for fast sending, I just need to port my C code into your sender and it should work better and without the stuttering.

Could you please point me to the right files/classes/lines?

Thanks a lot!

[McNugget6750]

Ok, I tested my gcode sender that I specifically designed to push out as many gcodes to grbl as possible, and the milling runs smooth as butter. However, that thing is console based and doesn't have such a nice gui. I'd really like to implement my algorithm into cnc-gcode-controller. You can find it in my github under SimpleG as well. https://github.com/McNugget6750/SimpleG

[im-pro-at]

Hello, Nice to hear :-) If I understand your code correct you try to fill the RX buffer of the grbl firmware as much as possible. Can you test if there is the same effect just to be 3 commands ahead? (If possible) or do ist really make a difference to fill it as much as possible? I used this program only for CNC milling so I decided to be on the safe side in case of an error. When you get an error and you already streamed ahead there can be unexpected consequences ... Or if you have a problem with the USB communication it's hard to recover the last send data.... Furthermore I have not implemented any error tracing functionality to handle any streaming ahead errors ... Nevertheless I also built a laser cutter and have also speed problems. I tried to Port grbl to Arduino mega without any speed improvement .... but I did not understand that the command sending is the bottelneck! Thanks for that input!!!!!! I will implement a new variant of the communication controller to stream ahead. I will report back on that soon. Greetings Patrick

…

On Sun, Jun 18, 2017, 03:53 Timo ***@***.***> wrote: Ok, I tested my gcode sender that I specifically designed to push out as many gcodes to grbl as possible, and the milling runs smooth as butter. However, that thing is console based and doesn't have such a nice gui. I'd really like to implement my algorithm into cnc-gcode-controller. You can find it in my github under SimpleG as well. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/pknoe3lh/cncgcodecontroller/issues/30#issuecomment-309251418>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFOCTZOCGmI8Y0EJoOaIB_4gb4eWPutOks5sFIMMgaJpZM4N9Wmo> .

[im-pro-at]

Added new releases 6.2=>
Activate stream ahead option under settings+
Choose JS:COMX as comport (it should be faster!)

I did a 50x50mm image with 0.1mm resolution in 40 minutes :-)

[McNugget6750]

Yeah! That's amazing!
Yesterday I did a lot more testing and I realized that I get an error once in a while when I allow my PC to use the entire RX buffer of grbl (set at the top to 127 bytes). When I reduced it to 96 bytes no error showed up.
I assume, grbl needs some time to work as well and filling the buffer up to the top produces some bytes not being read from uart properly. Setting it to a lower buffer size and just use that to the fullest solved the issue. However, I read through the grblController code today and they specifically mention that grbl has a very long ISR and if bytes are sent too quickly, they get lost. So they added a throttle to the byte sending.

BTW: Since I couldn't get my head around your Java project (I never really enjoyed Java if I'm honest) I forked grblController and added PCB functionality that I need for my mill to be able to mill double sided PCBs. I also fixed pcb-gcode for eagle so that it is now possible to mill the outlines up to a certain depth in a number of predefined steps. I just registered in their forum there so that I can share the code. I'm surprised the guys didn't implement that years ago. Many people are asking for that. Maybe that is also interesting for you!
pcb-gcode-3.6.2.4.zip

Cheers, and keep up the great work! Your software is awesome and I'd like to use it.
Timo

[im-pro-at]

I know I also use PCB-gcode ;-)
Maybe: http://reprap.org/wiki/Cyclone_PCB_Factory
could also be interesting for you.
They use my software a lot to optimise the code produced from PCB-gcode (it uses a lot more travel moves then necessary)

Yeah ... I'm using 2 layers for the communication one supports different low level libraries (NR and JS) and the other different firmwares like Marlin or grbl ... That makes it quit complicated. When you used to program C++ Java is just a lot easier ... I really love it more than C++,C# and VB ... the only downside is it's slowness ... But in the other hand it's portable and that's the winning point for me

Keep up the good work pcb-gcode needs some help I think :-)

Greetings
Patrick

PS: did you try 6.2 I released yesterday? Is it faster?

[McNugget6750]

Hey Patrick,

I'd like to pick this back up.
Pushing three commands forward is an improvements but it's not solving the issue. There are more aggressive ways to feed the data that also work better in return.

Method 1:
In one of my own gcode senders, I send a line once I get 'ok' for a past one. So as long as I get 'ok' I send a new message. However, I have to keep track of the available character buffer in grbl when doing that. If the line I want to send is too long to fit into the GRBL RX buffer, I wait for another 'ok' to arrive. This is reasonably fast but can still lead to stuttering when driving high speed with lots of commands.

Method 2 (super aggressive but also highest reward):
Send individual bytes as long as the GRBL RX buffer allows receiving them. This requires strict byte counting and the grbl receive buffer should probably never be filled all the way for reliability reasons. However, once an 'ok' arrives for a 20 character long message, one can push 20+ characters over to grbl regardless of the length of the command. That can mean sending 3/4 of a single command or 1.75 commands or even more commands if they are very short! GRBL will always check for line endings and never cares about what's actually waiting in the buffer. This method is likely the fastest possible but also needs to most care during implementation.

The RX buffer size should be a configurable parameter since grbl can run on various different systems with different memory configurations.

I was wondering if you could point me to the code where the actual sending happens. I wasn't able to dig that up.

Cheers
Timo