Welcome to Our Community

Some features disabled for guests. Register Today.

Grbl1.1 jog issue & confusion aplenty with unexpected movement!

Discussion in 'Control Software' started by Tom9999, Aug 19, 2018.

  1. Tom9999

    Tom9999 New
    Builder

    Joined:
    Aug 19, 2018
    Messages:
    2
    Likes Received:
    0
    Using Shapeoko 3XXL (with homing switches), grbl 1.1 & UGS Universal Gcode Platform 2.0 [nightly] / Jun 15, 2018

    Here are is the grbl configuration

    $$
    $0 = 10 (Step pulse time, microseconds)
    $1 = 255 (Step idle delay, milliseconds)
    $2 = 0 (Step pulse invert, mask)
    $3 = 6 (Step direction invert, mask)
    $4 = 0 (Invert step enable pin, boolean)
    $5 = 0 (Invert limit pins, boolean)
    $6 = 0 (Invert probe pin, boolean)
    $10 = 255 (Status report options, mask)
    $11 = 0.020 (Junction deviation, millimeters)
    $12 = 0.010 (Arc tolerance, millimeters)
    $13 = 0 (Report in inches, boolean)
    $20 = 0 (Soft limits enable, boolean)
    $21 = 0 (Hard limits enable, boolean)
    $22 = 1 (Homing cycle enable, boolean)
    $23 = 0 (Homing direction invert, mask)
    $24 = 100.000 (Homing locate feed rate, mm/min)
    $25 = 2000.000 (Homing search seek rate, mm/min)
    $26 = 25 (Homing switch debounce delay, milliseconds)
    $27 = 5.000 (Homing switch pull-off distance, millimeters)
    $30 = 1000 (Maximum spindle speed, RPM)
    $31 = 0 (Minimum spindle speed, RPM)
    $32 = 0 (Laser-mode enable, boolean)
    $100 = 39.950 (X-axis travel resolution, step/mm)
    $101 = 40.000 (Y-axis travel resolution, step/mm)
    $102 = 40.000 (Z-axis travel resolution, step/mm)
    $110 = 5000.000 (X-axis maximum rate, mm/min)
    $111 = 5000.000 (Y-axis maximum rate, mm/min)
    $112 = 5000.000 (Z-axis maximum rate, mm/min)
    $120 = 400.000 (X-axis acceleration, mm/sec^2)
    $121 = 400.000 (Y-axis acceleration, mm/sec^2)
    $122 = 400.000 (Z-axis acceleration, mm/sec^2)
    $130 = 825.000 (X-axis maximum travel, millimeters)
    $131 = 825.000 (Y-axis maximum travel, millimeters)
    $132 = 90.000 (Z-axis maximum travel, millimeters)

    I use a macro in UGS to set a tool change position
    $J=G53 z0.0 f1000;$J=G53 Y-700 f5000; $J=G53 x-100.0 f5000

    On startup and after I use my Triquetra to set zero, the macro works just fine. After I run any NC code (Fusion 360), running the macro makes the machine move to the wrong point and causes crashes. I am pretty sure that this is caused by a coordinate system offset, but I can’t figure out what to change to get this to work. Any ideas???

    Thanks,

    Tom
     
  2. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,239
    Likes Received:
    1,815
    I don't understand why you are using jog commands in the macro?
    this is not a jog move so surely just
    Code:
    G90 G17      ; force absolute mode and XY plane
    G53 G0 Z0   ; raise Z
    G53 G0 X-100 Y-700  ; go to toolchange
    
    is all you need? it will just rapid to the safe Z and then rapid to the toolchange location relative to the machine home.

    also, you are not including either G0 or G1 in your code, which means it uses whatever was used last, similarly with G90/G91, you must always set what you want since you don't know what the previous Gcode file did and how it left the modal state.

    also, IIRC UGS likes to use G92 for offsets instead of a G54 to G59 'real' work offset. Fusion always outputs at least a G54 so make sure you know which offset system is in use and what the side effects are. according to G Codes G92 moves ALL co-ordinate systems.
     
    sharmstr likes this.
  3. Tom9999

    Tom9999 New
    Builder

    Joined:
    Aug 19, 2018
    Messages:
    2
    Likes Received:
    0
    David,

    Thanks for the suggestion, but this did not fix the problem. Before I run a gcode file (Fusion 360 with Carbide 3D as the manufacturer), the macro that you gave me is just fine. Afterwards, there is no predicting what it will do. The reason that i tried the jog command was that I read that it always references the machine coordinate system. I think that the G53, that you suggested is also supposed to use the machine coordinate system as well. The machine coordinates that are shown in UGS always look correct right before I run the macro. Any ideas what to try next?? Attached is one of my nc files.

    Thanks,

    Tom
     

    Attached Files:

    • 1001.nc
      File size:
      1.1 MB
      Views:
      2
    #3 Tom9999, Aug 26, 2018
    Last edited: Aug 26, 2018
  4. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,239
    Likes Received:
    1,815
    I think I have it....
    your machine is defaulting to millimeters but your Gcode is in inches (not a problem!).
    But the Gcode sets inch mode (G20)
    This means that your macro (all macros) must always set the units it needs, in this case millimeters (G21).

    Code:
    G90 G21 G17
    G53 G0 Z0
    G53 G0 X-100 Y-700
    
    I also note that you are using the default GRBL post in Fusion. Quite frankly, that post sucks.
    Please try either Strooms or mine instead
     
  5. David the swarfer

    David the swarfer OpenBuilds Team
    Staff Member Moderator Builder Resident Builder

    Joined:
    Aug 6, 2013
    Messages:
    3,239
    Likes Received:
    1,815
    haha, just ran your gcode and got an error33 near the end. that is exactly the problem my post tries very hard to solve since Fusion just loves to generate really tiny arcs that don't have matching begin and end radii.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice