I've recently upgraded my machine and that meant re-flashing my arduino and resetting all parameters from scratch with the new machine's spec. On some g-code files when the machine is moving it does so with a slightly jerky movement, it's definitely not mechanical, rather it seems that the interface is unable to send g-code fast enough so the machine speeds up and slows down erratically. I've been using CamBam and tried converting arcs to lines in the post processor but that has not made any change. I'm using the latest build of GRBL and I use UGS platform to send. I've tried on two computers and the issue persists I've attached the file that is creating the problems (arcs as lines) it does the same things if I use the arcs. It seems that there are lots of small arcs and that might be the problem. Is it something I need to change in the post-processor? any ideas?
When this kind of thing has happened to me, there have been two causes: (1) Sometimes this happens as a result of ramps that I set up. On most profiles, you can see the machine slow down for the ramp and then speed up for the level cutting. But on smaller profiles (like a screw hole cutout), the whole machine can start looking a bit jerky as it switches between ramping and 'normal' in relatively quick succession. In my experience, this is typically fine. (2) The other times that this has happened, it is because the input DXF/DNG to my CAM program had a ton of (unnecessary) control points. Maybe it was a circle and instead of treating it as 4 arcs, it treated it as 400 arcs. When that happens, each line is so short that it underfills the GRBL controller. In cases like these, I ended up re-creating the file in my CAD program. I imported the old file into CAD, then drew a new sketch with just a few control points while using the imported file to lock down constraints. For example, if you have a circle in the orignal file that has many points, draw a new circle somewhere and then do a circle/point intersection constraint on three points to lock the new circle in place. And when you later export your new circle, it will only be represented as a few arcs in the DXF. I've only had to do this when pulling in design files I did not create myself. So perhaps the exporter in some programs adds too many points, or perhaps it went through an intermediate STL stage where the circle was represented as a ton of little triangles. In my case, it didn't just cause jerkiness. It also caused melting plastic because it meant my cutter wasn't moving fast enough through my stock and it was generating more friction heat than it was dissipating. But I couldn't find a way to fix it in the CAM itself, which is why I had to go back and remake the geometry in CAD. -Jonathon Duerig
Hi Jonathan, looking at my g-code file I think your second option is exactly what has happened: tons of tiny arcs that then flood the arduino. I'm going to have to see what I can do...it is only this particular file that I've seen this on. Brent
Ji Justin, I'm going to have to look at CamBam documentation to see how to do this, or rework the design in cad. <edit> OK so I played around quickly CamBam has an option that can GREATLY resize the file and should make a big difference. Will check