SketchUCam problem

Hi

Here is the meaning of the error message
Invalid GCode ID: 33 · Issue #619 · grbl/grbl · GitHub
in short, GRBL doesn't think the arc starts and ends where the code says it does.

I have just loaded it in NC Corrector (which normally moans about the slightest thing) and it is happy so the problem must be elsewhere.

googling a bit indicates that some GRBL controllers try to truncate the precision and that will throw arcs off for sure.
SketchUcam outputs 4 decimal places for arcs because they are needed, especially for small arcs as you have here, the radius is 0.9mm!

Maybe @Sonny Jeon can shed some light on this?

 

BTW CAMotics is very fault tolerant, in other words, it will not complain about errors in the Gcode at all >-:
Maybe I should dig out my LinuxCNC box and see what it says, it is very good at finding problems in arcs.

 

I solved this problem by realigning the holes in the drawing and regenerating Gcode. seems the specific spacing and position of the holes creates a set of arc parameters that GRBL just cannot handle.

 

Grbl follows the LinuxCNC definition of arcs and checks for errors according to their specifications. So, if it doesn't work on Grbl, it shouldn't work on LinuxCNC either.

However, I've found that some Grbl GUIs automatically truncate some higher significant digits of values to "help" reduce data traffic, but this has led to Grbl throwing back an error on G2/3 arc time to time. This is because the G2 and G3 arc definitions are horribly posed mathematically. The radius definition is the worst offender. Try using only IJK offset arcs and a different sender, if you still have problems.

EDIT: Seems I have repeated what you said already. It's also possible that your CAM doesn't generate proper arcs as well. Such that, minor realignments makes error in the G2/3 arcs small enough. I've also seen using mm-mode, rather than inches-mode, make a difference as well.

 

Interesting to know. Havn't fired up the LinuxCNC box yet but will have to try it and see.

The plunge hole code from SketchUcam always uses IJ format, and uses 1/4 arcs by default though one can force it to use full circles, I do not recommend that.

Plain arcs use R format, but they are short segments. I did try to migrate to using IJ but that gets messy real quick because of the way Sketchup edits arc segments. It works just fine for a full circle or a natively drawn arc, but if you edit the end points of the arc the begin and end points no longer match the radius and every controller I tried flags errors.

Metalguru's code is in mm.

SketchUcam increases the decimal digits from 3 to 4 for mm mode, and 4 to 5 in inch mode (just for arcs) since my testing showed that using only 3 decimals will often cause arc errors.

If you can you should run Metalguru's original code through GRBL in a debugger so you can tell us what exactly is wrong with that second plunge hole. The numbers are only slightly different from the first hole, just in the center co-ordinates, the I and J offsets are exactly the same since they are both 5mm holes. Maybe the problem is that it is a helical cut since Z is changing during the arc?

 

ran it in LinuxCNC and it gives a nice informative error message (-:

but wait, it is actually a Sketchup anomoly resulting from the tiny differences in hole centers.
X for hole 1 is xx.018mm
X for hole 2 is xx.001mm

Sketchup compares values to the nearest 0.001"
The X values for those 2 holes are different by 0.017mm, which is roughly 0.000669", below the threshhold.
This means that Sketchup considers them to be equal X values so does not trigger an X value output for the second hole.

By changing the SketchUcam code to use a custom comparison (diff greater than 0.0001") we get code that works fine from the original drawing.
Now we see X change from
X28.200
to
X28.184
for those hole centers, thus keeping the radii happy.

Must still test it a lot though, such high precision comparisons may cause unforeseen glitches elsewhere.

 

to quote the help

Code:

Plunge holes are automatically grouped.
This prevents underlying geometry from interfering with G-code generation.
Only an underlying horizontal line will interfere 
but in this case it is very easy to delete the part that overlaps the colored 'hole' line. 
Ordinary holes have no name while enlarged holes are named with the diameter and depth.
For example a plain 8mm hole will be named "_diam_8.0mm" and a 
depth restricted 9mm hole will be "_diam_9.0mm_depth_76.0".

in the case where you really need an underlying horizontal line under the plunge hole, group the line before applying the plunge holes. the 2 groups will not interfere with each other.

to quote the help, again (the help has a lot more detail than the vids and will really help you get to know this tool)

Code:

New 'Quick Tools' toolbar that allows you to quickly toggle the status of the 'Use Comments' and 'Comment Style' options. 
Using these will NOT affect the default settings set via the Tools|Phlatboyz|Options|Machine
Options menu.
Activate this toolbar by ticking the View|Toolbars|SketchUcam Quick Tools item.
NOTE that these icons have no visible effect until you output Gcode, 
though you will see the current status of the setting when you hover over the icon (except in SK7). 

I added the ability to turn of comments specifically for GRBL because GRBL does not like them much and the wide variety of gcode senders even less.

 

BTW you should NOT be seeing
(RAMP limiting Z to min_z @min_z)

This means you have not set min_z and max_z correctly.

on the main help page, click 'After install - things to do' and follow the instructions.

 

Grbl will ignore comments, but there are a set of special characters that control the real-time features in Grbl. These are ~, !, @, ?, and Ctrl-x. In your comment you have a '@' which will cause the machine to do a door safety stop.

I'm actually in the process of overhauling and re-designing Grbl's communication protocol. It will fix things like this.

 

yeah, the @ is part of a Ruby variable name that was supposed to be printing the value instead of the name (-:

 

That is true. However, at the time it was written, the real-time control characters needed to be selected as typable characters. These were things that were not in the official g-code programming language, which they are not, but they can exist inside comments. I ended up deciding that even though there was a chance that some users would have these characters in a comment, it was simple enough to avoid by not sending them to Grbl. Sending comments just take up bandwidth with no gain anyway. Most GUIs already skip comments anyway for this reason.

Like I said before, I'm reworking the Grbl protocol to avoid problems like this, as well as, a lot of other improvements, particularly for GUIs.

 

Not a conflict of interest. I just forgot you asked.

Hard to say which is the most stable these days, as they are all progressing and new bugs crop up constantly. If you find a bug, I recommend contacting the authors to let them know. It'll end up benefiting everyone.

The one I reach for first is bCNC. It's not pretty (on purpose), but it's very full featured and powerful. It's cross-platform with a standard Python installation (uses the standard tk GUI kit. hence the not pretty). It can be overwhelming to a new user. It is supported by a very smart and quick to respond author. It's by far the fastest evolving GUI and works perfectly on anything as slow as a Raspberry Pi.

The next would be UGS (Universal G-code Sender). It's been around the longest and is usually the one I recommend to just about everyone. Recently though, there has been a rash of bugs due to a coding overhaul, but it's steadily being fixed. UGS is fairly basic, but it does the job, usually very reliable. On a RPi, it's serviceable, if you're curious.

GrblPanel is also excellent, but it only runs on Windows, which a surprising portion of Grbl users don't have access to or afford. (Grbl is internationally used).

Of these three you can't go wrong. And I'm probably forgetting one or two, but these are the main three.

I can only NOT recommend one. That is Chilipeppr. I haven't tested it in about a year, but when I did, I ran into numerous performance issues. While it would work fine for simple jobs, an aggressive or large job would either make Chilipeppr non-responsive for long periods(no control over the machine) or execute the job very poorly compared to the other GUIs. I recall some browser crashes as well (but still kept running the job until I could reconnect). That's not to say that these problems haven't been fixed since then, but in general, I'm not a fan of current browser-based GUIs. There are too many things that can break between you and the machine. Machine control should be as close to the machine as possible and be 100% responsive. Nice-to-have features or a pretty interface doesn't do much in reality, if you can't stop your job when you see a crash coming or it doesn't pause the machine when you want it to.

However I do understand the benefits of browser-based software. Consistent, updated versioning, better feedback troubleshooting data, and cross-platform usage. I think we're getting there, but it's not quite what I'd like it to be yet.

 

Nope. There are a lot of challenging technical issues with trying to cram everything in to a woefully overstuffed 328p AVR. Going to a Mega doesn't help much, as they are the same speed. I can say, things are progressing nicely, but I'm not happy with the current performance. Good, but not great. That will take time to optimize.

 

good, but then your overcut% was greater than 100%, which means it is supposed to cut through the material, but it cannot because min_z is zero. to use it like this you need several things:
table must be flat
material must be held down flat
Z zero must be set accurately.
given all those factors you will get good cuts without much cleanup.

if you don't mind cutting into your spoiler, then set min_z = -max_z, set table top to Z-zero if you like, and carry on with whatever overcut% you need.

'theoretically' yes, but it doesn't. the Z levels are controlled explicitly by the overcut% and the material thickness, so no 'ramming' will happen (-:

min_z and max_z arose long ago in the code and I don't know the history but I do know that they no longer make perfect sense but also cannot be worked around, they need to be set to match your machine and the side effects need to be understood. having some limits is essential, but it is really the limit switches on the machine itself that must protect the machine, or failing those, the soft limits in GRBL (or other controller). No amount of limiting in the Gcode generator can prevent a crash if the machine + software system is not used correctly.

if you set min_Z = -max_z then you can use overcut% greater than 100%, and tabletop = z-zero on or off.
if you set min_z == 0 then you are limited to 100% overcut% and tabletop= z-zero, always.

layers are dynamically calculated and limited, and the final pass will depend on the overcut%.
with your parameters, and overcut% == 100 you will have 3 passes at 0.8mm deep and the final at 0.775mm deep.
if overcut% == 110% then material thickness becomes an effective 3.4925mm and you will have 4 cuts 0.8mm deep and final one of 0.2925mm deep, making 5 passes in all.

in soft materials I find it useful to decide how many passes I want and calculate the pass depth.
3.2mm material * 105% overcut / 4 = 0.84mm per pass

in hard materials it is better to add a pass if there is a partial pass, or at least round up....
so instead of 0.8mm per pass with a final of 0.29mm as above, use 5 equal passes of
3.175*1.1/5 = 0.6985 ( I would round to 0.7mm to ensure it does not do 6 passes).
having all passes the same depth make for better surface finish.

just helpful information.

indeed, that is why the quicktools toolbar exists, so you can easily switch between comments on for checking and comments off for actual cutting.