I’m using a Ramps 1.4 board (‘standard’ 2560 clone with ch340 driver) connected to a macbook pro via usb and i usually use Repetier or laserweb for laser work/and recently cncjs to send the gcode to my ramps setup. I have noticed for a while now when doing small detailed movements my machine often is a bit ‘jerky’, for laser work often times it’s spending too much time in the detail sections (enough so it ends up burning the piece).
I always forget you can ‘print’ from SDCard, so today i popped one in and realized 100% of these speed/jerkiness issues is due to my usb connection. I ran a couple of different gcode jobs from sdcard and compared it to usb and sdcard jobs run nice and smooth, no slow down doing details or jerkiness whatsoever.
I even tried cncjs w/ a raspberry pi just to compare, and it’s no better then sending in from my mac. I was thinking of picking up a ‘better’ 2560 clone (not sure exactly what this means - maybe like a keestudio or something) as i was thinking maybe mine has a noisy usb (i tried a bunch of different cables already). Wondering if anyone else had this issue?
As an additional piece of info, G2/G3 use does help this a lot also - and i’m learning to try and use this more with fusion but i think this is more of a band aid solution now that i know the hardware is only limited by the usb in my situation.
I used to have this problem with my 3D printer, but not since I started using 250k speed. I would get little warts on the outside of detailed prints. The laser probably goes much faster than my 3D printer though.
Your basically running out of buffer in the planner because it’s finishing the moves faster than they are being sent through usb/uart. The arc command makes sense, because replacing an arc with a bunch of points will make it need more characters to send. CNC.js has a display for the remaining buffer, but that might only be for grbl.
Octoprint, at least, supports uploading the files to the sd and printing from the sd. It takes a lot longer to upload, but that’s delay that’s not in your CNC later. I haven’t used that feature in a while, YMMV.
Another SDCard feature that i’ve never used I use Octoprint on 3 3d printers and I don’t think i ever realized there was an ‘upload to sdcard’ option. Also it looks like if you use octoprint to ‘print’ from a file on sdcard it uses m23/m24 which is pretty cool.
I did place an order last night for a keestudio 2560 which does use the same/similar usb driver the genuine Arduinos use, hopefully it fixes it otherwise i think i’ll have to start shopping for an alternative (was thinking of giving a Rearm a shot, or of course I assume the rambo doesn’t have this issue)
Now that I think about it, it was using repetier firmware. I can’t imagine they haven’t gotten it to work with Marlin, but my experience shouldn’t be trusted :).
I can’t imagine the uart chip matters, unless you can push the baudrate up in your configuration. 250kbps is the limiting factor, right? Can you configure it to 500k? Or what’s a standard one 384?
I just tweaked marlin for 500kbps (next up from 250) as well as down to 57.6kbps and actually no difference at all on my test gcode (other then having to adjust repetier - so definitely was running at the two bitrates).
I guess on the plus side, uploading to sdcard w/ 500kbps is a bit faster
I don’t have high confidence the different 2560 will fix it, but I’m stumped as to where the issue is… As a sanity check I attached the first part of the gcode I’m using to test to this post. It’s a simple helical path that is used prior to an adaptive (from fusion 360). Obviously there are lots of tiny movements on all 3 axis but the whole thing is only 31Kbytes, which at 250kbps would only take around a second to send the whole thing. Obviously there’s handshaking/planner/etc going on but in realtime the path takes ~20s to run so should be plenty of time.
And yeah - every time I test with the baud rate, i do an SDcard test run with the same gcode and it’s completely smooth. When using usb every circular motion of the helix has a brief pause (or two) that’s probably 100-200ms. It’s not a big deal on the helical entry stuff but when it actually starts doing the adaptive clear it ends up adding in a lot more vibration then necessary as it’s constantly doing small stop/starts.
So - it was the 2560 board after all, I swapped in the new Keyestudio 2560 (with standard uart) and using the same firmware i’m now cutting over usb just as smoothly as with the SD. I really should have dug into this earlier, from the very early crown pen days i thought it looked laggy but being new to CNCs I figured there was probably a reason…
I don’t know if it was the ch340 uart, or something else on the board. It’s about as generic as they come, not a single brand name/etc on it… I think when purchased it was sold by BIQU but they don’t even have them on amazon any more (was for a still to be completed addition 3d printer build)…
Anyway something for folks to watch out for if your config uses a ramps.
I use Octoprint on 3 3d printers and I don’t think i ever realized there was an ‘upload to sdcard’ option. Also it looks like if you use octoprint to ‘print’ from a file on sdcard it uses m23/m24 which is pretty cool.