Welcome to Our Community

Unlock hidden features. Sign Up for Free Today!

SketchUCam problem

Discussion in 'CAM' started by Metalguru, Feb 10, 2016.

  1. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    Hey guys:

    I am just trying my first shot at Sketchucam. I have created a drawing of a bracket, used SketchUCam to generate a gcode file, and tried it out on my router. The router makes the first hole, goes to the second hole position, and GRBLpanel comes up with the error:

    error:invalid gcode ID:33

    and hangs. It loses communication with the Arduino, the COM4 port which the arduino attaches to goes away, and I have to reboot to get it back.

    The g-code line that it gets the first error is Line 44:

    G03 X29.0836 Y105.3621 Z2.8000 I0.0000 J0.9000

    I don't know much about G-code, but this is the beginning of a 5mm hole using a routine called plungebore. This is the first G03 instruction of the hole. Looking at the code, I don't see any obvious errors and it is not much different from the first hole except for the xy position. Other than that the g-code is identical.

    I ran this twice to make sure it was not a hardware problem, but the code error occurred in exactly the same place both times.

    I have run the gcode through Camotics and it runs fine through the whole simulation.

    At a loss on this one. ***?

    Attached the files so you can see what I have done.
     

    Attached Files:

  2. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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?
     
  3. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  4. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  5. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    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.
     
  6. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    All right guys, thanks. Good to know. I will have to be much more careful when generating g-code drawings from now on.
     
    #6 Metalguru, Feb 15, 2016
    Last edited: Feb 15, 2016
  7. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    So, still messing around trying to get this to work..

    NC Corrector crashes with a "Divide by Zero" error every time I load a file. Doesn't seem to matter which file.

    Sonny: So, does GRBL Panel fall under this category? Not sure if GRBL panel is your software or someone elses. Whose GUI do you recommend as being the most robust and error free?

    David: I regenerated a new bracket design, and tried to run it. I had odd problems with duplicate holes appearing with a slight offset, etc. I think this may have been my problem with SketchUp and not yours. However, I also had an odd problem with certain comment lines causing GRBL Panel to perform a pause in the code execution. It always happened on a comment about the plunge angle limit, specifically this one:

    (RAMP limiting Z to min_z @min_z)

    Every time this comment occurred, GRBL Panel would pause, and I would have to hit the resume button. Did thid 7 or 8 times for each iteration of the perimeter cut. Weird.

    Going back to go over your tutorial vids again to see if there is some stuff I missed...
     
  8. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    Just ran another test, better results except for two things:

    1. Holes seem to be coming out a bit small. I am using 1/8" hardboard for test material, that may be the cause. 5mm holes came out at 4.6-4.7mm, 22mm hole came in at 21.6-21.7mm. Tool is 1/8"(3.175mm) up cut mill. Hardboard tends to fuzz up a bit when cut. Outside cuts seemed fine. Will try to run an aluminum plate tomorrow.

    2. GRBL Panel is still halting on the RAMP comment as above. Or, pausing , I should say. Not super critical, but a pain in the *** nonetheless.

    Let you know what happens with the aluminum cut.
     
  9. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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?
     
  10. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  11. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  12. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  13. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    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.
     
  14. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    yeah, the @ is part of a Ruby variable name that was supposed to be printing the value instead of the name (-:
     
  15. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    So, all good information Guys, but:

    I thought anything within a comment section was supposed to be ignore by GRBL. (or any code, for that matter). So why would a control character inside comment brackets get executed?

    David, this confuses the hell out of me. It says in the help to set Min_z to -(Max_z). That would mean that if my z axis travel was 100mm, I should set Min_z to -100mm? This means the machine could theoretically try to ram the cutter 100mm below the table? This does not make sense. This is why I set Z_min to zero and ticked the "Table Top is Z Zero" box on the parameters window, and left it alone (exactly following the instructions). So why am I getting this bad comment line?

    Also, this does not make sense to me in another way: If I have a workpiece that is, say 3.175mm(1/8") thick, and I set my multipass depth at 0.8mm, this means it will take 4 passes to get through the material, and the cutter will end up at Z=-0.025mm. This is fine, I have a spoiler board and I don't care if the cutter goes into it a bit in the interests of making a clean cut through the workpiece. However, this means that the Z axis has gone negative, through the hard limit set up in the parameters. Is this what is causing this error?

    Not sure why you included this. I had no underlying lines anywhere on the drawing. And none of my holes were plunge holes, they were all holes larger than the bit.

    I will turn off comments from now on when generating the final gcode for the machine. It is handy to have them for debugging purposes, however.

    Thanks again, guys.
     
  16. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    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.
     
  17. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    Sonny, I did not get a recommendation from you as to which GUI (IYHO) was the best and most stable... Or is that a conflict of interest?
     
  18. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    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.
     
  19. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    Cool, thanks for your opinion. I like GCodeSender as well, was trying out GRBL Panel, but there are a few things I don't really like about it.

    Appreciate your time, Sonny. Any ETA on the new version of GRBL?
     
  20. Sonny Jeon

    Sonny Jeon Veteran
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2015
    Messages:
    110
    Likes Received:
    37
    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.
     
  21. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    Cool, well all I can say is, keep up the fantastic work...
     
  22. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder

    Joined:
    Aug 6, 2013
    Messages:
    521
    Likes Received:
    250
    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.
     
  23. Metalguru

    Metalguru Master
    Builder

    Joined:
    Dec 29, 2015
    Messages:
    332
    Likes Received:
    175
    David:

    Ok, I think I got it now. If Zmin is set to zero, it will stop when Z gets to zero no matter what overcut you have set. If you set Zmin below the table, everything will work properly, overcut will work, and no ramp limit errors.

    So why not set Zmin to be a realistic value like -1mm instead of -100? You will never realistically cut to -100mm, so why use that as a limit. I suppose it doesn't matter, it will never get there anyway... Just kind of non intuitive...

    Thanks again.
     

Share This Page

  • About Us

    The OpenBuilds Team is dedicated helping you to Dream it - Build it - Share it! Collaborate on our forums and be sure to visit the Part Store for all your Building needs!
  • Like us on Facebook

  • Support Open Source FairShare Program!

    OpenBuilds FairShare Give Back Program provide resources to Open Source projects, developers and schools around the world. Invest in your future by helping others develop theirs!

    Donate to FairShare!