We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
This has happened to me a number of times when doing complex topo map cuts: Any relatively flat part cuts fine, but once it gets to any area with high-frequency detail( like mountainous regions, the whole machine will pause, start, pause, start, etc. This pausing significantly increases my cut times, arguably adding 1/3 more time than it should.
Originally I’d been using Chilipeppr to send the gcode, and I thought maybe it was an issue with that software. But switching to Universal GcodeSender still has the same issues.
Talking on the Chilipeppr formums, it was suggested that the old 8-bit Arduino uno/grblshield just couldn’t keep with the amount of data being thrown at it, and it would pause until it could clear it’s buffer: When watching UGS send the code, I can see how the whole codeflow stops & starts just like the machine.
If this is the case (or if it’s something else), other than ‘cutting slower’ (which I’m trying to do the opposite of), is there a solution based on my existing hardware? Or is it change out the electronics to something more powerful, like Smoothie or something?
This one, for example, does not suffer this problem, probably because while the overall shapes are complex, there is’t a lot of high-frequency detail packed in one place:
It is probably too many nodes present in the code requiring it to clear memory before it can continue.
Another time factor for heavy 3D carving is the Z-axis acceleration and max travel rate. By default it is set lower than X & Y. Might be worth checking
I’ve doubled my z-speed in firmware to help with cut-time as well. In fact, z-travel is the biggest gate to speed on these cuts. But the stuttering problem is still present with default\slow z-travel.
Thanks for the compliments!
So if it’s ‘too many nodes’, what’s the solution? Presumably its only ‘too many nodes’ because the electronics can’t handle it, there’s nothing wrong with the data inherently?
I design in Maya, but that shouldn’t matter, the gcode is generated via MeshCAM.
To reiterate though, this issue only shows up when cutting the high-frequency detail parts of terrain. I can watch UGS send the gcode, and it’s physically stopping and starting both on-screen, and on the machine at the same time.
Cut for 3 seconds, pause for 1, cut for 4, pause for 2, cut for 5, pause for 1, etc.
Once it hits a ‘smoother’ section (less instructions being sent per second) it cuts just fine.
If it was a USB cable issue, I feel like it’d be happening all the time. But this is super localized to high-detail regions in those type of cuts.
I should also note, it’s not the roughcut (far fewer instructions being sent) that has these problems, it’s only the finish pass: I can visualize the gcode, and it looks fine (of course, there could be non-visualized code issues still present). When I watch the gcode stream & start/stop, it all looks like normal g commands, but passing them in chunks, rather than a stream.
Robert, how fast are you cutting? The last piece I did had XY@210"/min, and Z@40"min. I’m pretty confident if I slowed that down, it would stop all the pausing. But probably take way longer to cut overall at that point.
Yah, I’ve been doing a lot of speedtests to see how fast I can push it. It’s been doing fine for all cuts expect… high frequency detail for an extended period. On the flats it just tears through the material, the result is great as you can see from the above pics.
Note the Z can go at that rate just fine : For example, a “single mountain” (or even a few in a row) it’ll have no problem cutting with no pausing. You stack 10 in a row though, and it’ll start the pause-dance. But when it actually cuts, it cuts just fine.
I export from Maya as stl, which is what MeshCAM likes to eat.
I found my old post on the Chlipeppr forums (Oct 2016, when I first hit this), this was John Lauer (the author of that software) reply at the time:
Somebody will have to port the TinyG buffer over to the Grbl buffer in SPJS to fix the locking issue. It’s been discussed a few times prior that the Grbl buffer has always had a potential for deadlock. TinyG buffer used to have this and was fixed about a year ago. Hitting resume does seem to kick the Grbl buffer so it proceeds, but you can hit the deadlock again.
Now that was more of a chlipeppr-centric response, but it still makes me feel like there’s an issue in grbl.
I do. Personally, the mesh isn’t that detailed relative to the size of the bit IMO. Here’s a shot of it from my ‘the bay’ cut:
It was a lot heavier when I initially captured it, that’s a signifiant adaptive (not linear) decimation.
And if you consider the section in the middle (SF) is maybe 3" across, it seems, to me, to be a reasonable amount of mesh for the cut.
I should also note, another reason I feel grbl is having a hard time ‘taking the data-stream’:
The finish pass was along Y (top to bottom) : As it cuts up, through the water, it’s fine. And as it goes up onto the land, it’s fine, but after an extended period on the land, when it hits a more mountainous region, it starts the pausing. Later on the ocean it does fine, and on the flatter areas (regardless of height) it does fine. But when it starts to encounter a lot of relative z-change for an extended period, that when it starts to choke.
I’ve not had an issue with any mesh so far. If you would like to email a copy, I can bring it in and see. I deal with secure files all the time so yours would be kept confidential.
Thanks JDM: What I think I’ll do first is see if I can make a (small) torture test that causes this issue to become apparent. If I can repro it on that, I’ll pass it along.
Yep, per my other thread where you suggetsed this:
I bumpted that number up to 40. Tried bigger numbers, but that didn’t work out so well Thanks for that tip though.
SO, last night I did a test cut where I extracted a 3x3" square of the most mountainous region from the above design, and re-cut it with the exact same settings.
It just just fine. So, I’m back to square one now of trying to figure out what’s causing this. To date, this only happens on really long cuts during the finish pass. And if happens whether or not I split up my gocde into a rough/finish pass files, or lump it all into one file. But it happens immediately on the finish pass, could even be the first leg it makes, which made me think my above-mentioned torture test would trigger it.
Sigh… “calibration”
Thanks for that tip though.
