1. Hey guyz. Welcome to the All New Phlatforum!



    Sign Up and take a look around. There are so many awesome new features.

    The Phlatforum is a place we can all hang out and

    have fun sharing our RC adventures!

  2. Dismiss Notice

SketchUCam problem

Discussion in 'SketchUcam Help' started by Darrell Norquay, Feb 10, 2016.

  1. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    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. WTF?

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

    Attached Files:

  2. swarfer

    swarfer Moderator Staff Member

    Offline
    Messages:
    808
    Trophy Points:
    28
    Location:
    Grahamstown, South Africa
    Hi
    first, nothing wrong with the code, really
    but GRBL or GRBLpanel is doing something odd.
    Here is the meaning of the error message
    https://github.com/grbl/grbl/issues/619
    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!

    The reason for truncating was because GRBL used to limit lines to 50 characters, then increased to 80, and now I believe it is settable in the settings (nope, compile time option). SketchUcam itself tries to minimise line lengths and I believe they are always shorter than 70 characters. Even comments are split onto multiple lines to maintain 'short' line lengths, just for GRBL.

    So, look in the settings tab of GRBLpanel and see if there is a truncation/trim option that you can turn off.
    Make sure you have the latest GRBL code and latest GRBLpanel, trying to debug older versions is a waste of time.
    Make sure GRBL is using 70 or 80 characters for line length. The line you quoted is 47 characters which may be close enough to the old 50 limit to be causing problems.

    I see in the latest GRBL version the default is 80 characters for the line buffer so this should not be a problem if you are running 0.9j - which leaves GRBLPanel as the problem area.
     
  3. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    Update:

    Tried running the code with 109JBs GRBL Interface (downloaded from Github), same problem. First hole cuts fine, second hole stops right at surface with error code 33.

    Then tried running it with UniversalGCodeSender, the program ran all the way through, but the second hole did not cut, it went to the position, made a slight mark on the face of the part, then moved on to the next hole. The rest of the program ran fine, with the exception noted below:

    The cut outline for the part started one one side, ramped down through the whole length of the cut, then proceeded to cut the rest of the outline at full depth. The bit moved up for the tabs, and ramped back down, but otherwise cut the outlines at full depth. Good thing I used some 1/8" plywood for a test piece instead of aluminum. That cutting profile would have broken the bit for sure in aluminum. I thought I had the program set to do increments of 0.8mm depth for the outline cuts, not full depth. What did I do wrong?
     
    Last edited: Feb 12, 2016
  4. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    Ok, I figured out the multipass thing. I forgot to check the box in the setup window, I set the pass depth but did not enable it.

    And BTW, I am using GRBL version 0.9J on my arduino.
     
    swarfer likes this.
  5. swarfer

    swarfer Moderator Staff Member

    Offline
    Messages:
    808
    Trophy Points:
    28
    Location:
    Grahamstown, South Africa
    Having noted that your hole positions are not in any way lined up with 'round numbers' (ie not on a grid) and that the second line of holes is not lined up with the first (X values are different, even though they are visually 'in line', I tried changing the drawing.

    I placed a construction line an exact number of mm (130) from the bottom of the safe area box and moved the entire drawing so that the top row of holes lay on that line.
    Then I placed a construction line from the left side and moved everything so that the top left hold center lay on that line. (press T to place construction lines).

    This places the top left hole at exactly
    X25.000 Y130.000
    but the next hole that gets cut, 2nd row, left side, is not aligned with that, both X and Y being some odd fraction of a mm different (besides the roughly 20mm offset in Y).
    So, I placed a construction line 20mm from the first row of holes and moved the 2nd row onto the line.
    Now the second row of holes are at 'nice' regular spacing and the code runs fine through GRBLpanel and GRBL, so it seems that the odd spacing somehow hit a 'worst case' calculation within GRBL that results in it deciding that the endpoint is wrong.

    Here is what the first 2 holes look like now.
    Code:
    %
    (Generated by SketchUcam V1.4-738b-dirty)
    (File: c-beam base plates.skp)
    (Bit diameter: 3.2mm)
    (Feed rate: 2540.0mm/min)
    (Material Thickness: 3.2mm)
    (Material length: 200.0mm X width: 200.0mm)
    (Overhead Gantry: true)
    (RAMPING at 30.0 degrees)
    (Plunge Depth first)
    (Optimization is ON)
    (Z ZERO IS TABLETOP)
    (www.PhlatBoyz.com)
    G90 G21 G49  G17
    M3 S24000
    (Group: _diam_5.000mm)
    G00 Z13.200
    X25.000 Y130.000
    (plungebore  DEPTH=3.200  DIAM=5.000)
    G00 Z3.700
    G00 Y129.1000
        Z3.9620
    G01 Z3.2000 F2540
    G03 X25.9000 Y130.0000 Z2.8000 I0.0000 J0.9000
    G03 X25.0000 Y130.9000 Z2.4000 I-0.9000 J0.0000
    G03 X24.1000 Y130.0000 Z2.0000 I0.0000 J-0.9000
    G03 X25.0000 Y129.1000 Z1.6000 I0.9000 J0.0000
    G03 X25.9000 Y130.0000 Z1.2000 I0.0000 J0.9000
    G03 X25.0000 Y130.9000 Z0.8000 I-0.9000 J0.0000
    G03 X24.1000 Y130.0000 Z0.4000 I0.0000 J-0.9000
    G03 X25.0000 Y129.1000 Z0.0000 I0.9000 J0.0000
    G03 X25.9000 Y130.0000 I0.0000 J0.9000
    G03 X25.0000 Y130.9000 I-0.9000 J0.0000
    G03 X24.1000 Y130.0000 I0.0000 J-0.9000
    G03 X25.0000 Y129.1000 I0.9000 J0.0000
    G00 Y130.000 Z13.200
    (plungebore end)
    (Group complete: _diam_5.000mm)
    (Group: _diam_5.000mm)
    G00 Y110.000
    (plungebore  DEPTH=3.200  DIAM=5.000)
    G00 Z3.700
    G00 Y109.1000
        Z3.9620
    G01 Z3.2000 F2540
    G03 X25.9000 Y110.0000 Z2.8000 I0.0000 J0.9000
    G03 X25.0000 Y110.9000 Z2.4000 I-0.9000 J0.0000
    G03 X24.1000 Y110.0000 Z2.0000 I0.0000 J-0.9000
    G03 X25.0000 Y109.1000 Z1.6000 I0.9000 J0.0000
    G03 X25.9000 Y110.0000 Z1.2000 I0.0000 J0.9000
    G03 X25.0000 Y110.9000 Z0.8000 I-0.9000 J0.0000
    G03 X24.1000 Y110.0000 Z0.4000 I0.0000 J-0.9000
    G03 X25.0000 Y109.1000 Z0.0000 I0.9000 J0.0000
    G03 X25.9000 Y110.0000 I0.0000 J0.9000
    G03 X25.0000 Y110.9000 I-0.9000 J0.0000
    G03 X24.1000 Y110.0000 I0.0000 J-0.9000
    G03 X25.0000 Y109.1000 I0.9000 J0.0000
    G00 Y110.000 Z13.200
    (plungebore end)
    (Group complete: _diam_5.000mm)
    
    Though the code now runs through GRBL ok, I see that all the other holes are not exactly 20mm apart like they should be, I recommend using construction lines and/or inferencing to line them up. Check the Sketchup help on inferencing, it is an important feature in Sketchup and will help you a lot in every drawing. I got used to construction lines in TurboCAD and use them all the time, but the inferencing can often replace them.
     
  6. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    Hey David:

    New issue. I'm playing more with SketchUCam. I did a simple part, flat plate with 5 holes. Did the holes no problem. Very carefully located the holes when making the model.

    Select the face, click the Outside Cut Tool, it puts a cut line INSIDE the face. Select the Inside Cut Tool, it puts the cut line OUTSIDE the face. WTF? I noticed this on the last plate I did (see above), but I eventually got it to work. Can't for the life of me figure out how...

    Help?
     
  7. swarfer

    swarfer Moderator Staff Member

    Offline
    Messages:
    808
    Trophy Points:
    28
    Location:
    Grahamstown, South Africa
    your face is reversed. right click the face, select 'reverse face'.
     
  8. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    Ok, not an obvious solution, but thanks.

    Of what other uses is the "Reverse Face" command?
     
  9. swarfer

    swarfer Moderator Staff Member

    Offline
    Messages:
    808
    Trophy Points:
    28
    Location:
    Grahamstown, South Africa
    it governs the colours and textures on a 3D model and maybe some of the more advanced 3D things like intersect may be affected by face normals.

    if you just draw a rectangle on the X-Y plane, it should be the right way up for SketchUcam. I have certainly never had an issue with faces coming up the wrong way round.
     
  10. Darrell Norquay

    Darrell Norquay New Member

    Offline
    Messages:
    6
    Trophy Points:
    3
    Location:
    Calgary, Canada
    that's exactly what I did, just draw a rectangle on the x-y plane. Hmmm. Happened with both attempts at doing the g-code file for this part, both from fresh starts of SketchUp.
     
  11. swarfer

    swarfer Moderator Staff Member

    Offline
    Messages:
    808
    Trophy Points:
    28
    Location:
    Grahamstown, South Africa
    well, I cannot find any way to change the default face orientation so have no idea what you have done.
    assuming you are using the default color theme, a face you draw on the x-y plane should be light blue (effectively that is Sketchups concept of 'bottom' face, since if you now extrude that face to a cube, the face you could not see is now 'outside' the object and the entire thing will turn white with outside faces.)

    the blue axis should point up at you.

    if you turn on the Views toolbar (View|Toolbar|tick Views) and click on the 'top' button you will get the axes oriented correctly.
    what happens now when you draw a rectangle with the rectangle tool?
     

Share This Page