-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gCode sending too slow? CNC stutters... #30
Comments
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 |
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>
.
|
Yeah! That's amazing! 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! Cheers, and keep up the great work! Your software is awesome and I'd like to use it. |
I know I also use PCB-gcode ;-) 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 PS: did you try 6.2 I released yesterday? Is it faster? |
Hey Patrick, I'd like to pick this back up. Method 1: Method 2 (super aggressive but also highest reward): 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 |
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!
The text was updated successfully, but these errors were encountered: