Sorry, but not sure where to post this problem. Please move if needed. My setup is a self built CNC router machine that is controlled via Openbuilds Blackbox X32. Some info here to setup my problem. I have a sign that I designed in VCarve Pro. VCarve outputs 4 gcode files, one for each different size bit. If I have VCarve output using either "Openbuilds Grbl" code or generic "Grbl" code, the below happens. The first file is for a 1/4" downcut endmill. Runs - no problems. Second is for 1/8" downcut endmill. Runs - no problems. Third if for 1/16" downcut endmill. Consistently loses steps (but not always at the same place while running the file BUT always in the Y axis) Forth file is just the profile cut and always runs without any problems. Now the kicker here is, if I output the code to generic gcode, absolutely not problems with any of the files. I attached the file that fails. I guess my question is...I don't know...is this a problem with my settings?, something in the gcode?. It only happens with Grbl code. I've reproduced this about 10 times (can show the scrap wood). Failure is ALWAYS with the Grbl code, third file and will occur quite quickly into the file, just not always at the same place. p.s. I've done all the "losing steps" debugging. Slowed down the feed, lowered the acceleration, checked and rechecked grub screws, double, triple checked the wiring (even removed some connectors and directly soldered them), Made sure no EMI. Problem is only with the one file which I think is the most complex one, lots of direction changes and small cuts.
DOC is a little bit aggressive for a 1/16" bit at 2.2 mm per pass. Could you post the file from the generic grbl post processor for comparison? Alex. PS, you said you lowered the feedrate - it's 2032 mm/min - what was it before? that seems a bit high for such a small bit also.
The 1/16 bit is just cleaning up the edges and adding a bit more definition. That feedrate is not what is set in the X32 controller (can't check the actual setting right now, running a job but it's around 1000 or maybe even 800 at this time). What takes precedence? Vectric's feedrate or what is set in Grbl on the X32? The generic Grbl file also fails. Attached is the file that works.
The max feedrate set in the grbl settings on the blackbox take precedence. Alex. PS, I wouldn't expect doc to cause missed steps with that bit - more likely that you would snap the bit if you were pushing it too hard. EDIT:- Those two files appear to be identical - just to clarify, the grbl post processor that comes with Vectric produces a file that works, the file produced by the Openbuilds post processor doesn't work?
Didn't know I could check those settings while a job is running. Anyway, it's set to 700, down from whatever the defaults are (2500) Right now it crawls...but runs if I use the generic g-code.
Opps! LOL. I edited and changed the file above. The post processor files ending in .gcode (grbl files, either from Vectic or Openbuild) does not work. The file ending in .tap does work. i.e. none of the grbl files works, but the generic g-code files do work.
I know, I've been pulling my hair out with this problem for the past week. I kept eliminating one thing after another until the only thing left was the files themselves. So I looked at the files and thought, lets change the post processor from Openbuilds Grbl to the generic Grbl (both are in VCarve). No change. So I thought, lets go back to the generic gcode that used to work (old controller). BAM, file ran perfectly. I can reproduce this over and over. I however, don't understand why.
Just for clarity, in the screenshot attach, the top two post processors work, the bottom 4 don't work.
You have a problem with tiny arcs - you need to linearise small arcs - an option in the Openbuilds grbl post processor I believe. The *.tap post processors are not a good choice as they don't output all the commands for the header of the g-code file that are really needed - see pic - grbl post processor output on left. These are the lines that are causing issues; Alex.
Soooo, what I gather from above and then reading much of the internet today (LOL), is I have to modify the post processor file (OpenBuilds_mm.pp or OpenBuilds_inch.pp) and add the following line to that file "MIN_ARC_RADIUS = 0.01" or some value similar to it so that VCarve will make small arc as lines. I see PetervdWalt has updated this file so maybe he can chime in here if I've got that right.
Just to follow up, while I haven't tested the file on my machine yet, attached is the new "Openbuilds GRBL (mm) (*.GCODE)" file. Note that the "J" commands are gone. I had to set MIN_ARC_RADIUS to 1.00 or basically 1mm. Hopefully this solves my problems in the long run. Thanks Alex. You pointed me in the right direction (as in, I didn't even know what to search for). p.s. I modified my "Openbuilds GRBL (inches) (*.GCODE)" file just in case I'm tempted to work in inches. I added the line "MIN_ARC_RADIUS = 0.04" and that did the trick in that format.
the dejavu is strong with this topic, I am sure I typed this out just the other day.... somewhere.... it looks like Vcarve has formulas in it that generate arcs proportional to the bit diameter, I know Fusion360 does this and it causes issues with very small arcs that are about bitdiameter/10 in radius. so, the smaller the bit, the smaller the arcs. but small arcs come with an increased sensitivity to differences in the start and end radius, and GRBL detects this and gives an error 33. the solution is to linearize all arcs that have radius less than the bit radius. your MIN_ARC_RADIUS of 1mm approximates exactly that setting for your 1/16" bit.
