gCode sending too slow? CNC stutters... about cncgcodecontroller HOT 6 OPEN

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

from cncgcodecontroller.

from cncgcodecontroller.

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 :-)

from cncgcodecontroller.

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

from cncgcodecontroller.

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?

from cncgcodecontroller.

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

from cncgcodecontroller.