grbl "laser origin" and "finish position" – error?

Home Forums Software LightBurn GCode Specific grbl "laser origin" and "finish position" – error?

This topic contains 8 replies, has 2 voices, and was last updated by  LightBurn 5 months, 3 weeks ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #2106

    Sauron
    Participant

    Hi,

    Switching with (possible) error report from FB to here (it should be preferred method – right?).

    When homing laser to upper/right corner – default location for GRBL – position is set to 0/0/0 there, homing works properly. Now if I set, in device setting, “laser origin” also to upper/right corner all X/Y movement are inverted. When I set “laser origin” to lower/left corner – movements are kind of correct but working space is not.

    So far I’ve been homing to lower/left corner, and probably because of this I haven’t notice that. But since this is “not proper” way with CNC and GRBL has reported origin/home position as -300x -180y (this is the size of my table) which is not logical to me, I’ve switched to “negative space” where home is 0/0/0. But then every movement has to be in negative space – I guess this is the problem here.

    Second thing. Whatever I do – after finishing laser engraving (doesn’t matter if I push “Set Finish Position” or not) – laser is going somewhere until it hits endstop. This happens when homing to lower/left corner – so it’s not connected with previous problem.

    Checked both on Linux and Windows (just to be sure).

    I’m not sure if this is clear – I can do video if it helps.

    Regards – Adrian

     

     
    <div></div>

    #2115

    LightBurn
    Participant

    Hi Adrian,

    LightBurn doesn’t work in “negative space” mode – You can set the origin to any of the four corners, but the workspace is always in positive coordinates, so we recommend using an origin in the lower left.

    Can you verify that when homing to lower left your workspace coordinates are positive X to the right, and positive Y to the rear of the machine?  If they are, things should work normally and you could be using the wrong “Start from” mode – I recommend using “Absolute Coords” until you understand how the coordinates and job-origin system works.

    Read up on that here: https://github.com/LightBurnSoftware/Documentation/blob/master/CoordinatesOrigin.md

    #2117

    Sauron
    Participant

    I’ve read documentation on every possible way – before posting this (and other issues). Of course I can work with lower/left corner as home/start position – problem is, this is not laser only machine. So this would require have completely different grbl $$ settings for milling and laser – this is, at least, not ideal solution.

    I’ll check how “finish position” behave with different homing settings and let you know.
    <div></div>

    #2123

    Sauron
    Participant

    Hi,

    I’ve switched homing on GRBL to lower, left corner. Now position after homing (“get position” button) shows X-300 Y-180. Axis movement is ok, but if I don’t use “start from current position”, LB tries to move somewhere outside workspace.

    It would be much easier to debug, if I could see gcode commands send by LB (this is what I’ve asked on facebook some time ago), or perhaps some description of the debug log content.

    #2124

    LightBurn
    Participant

    You’re still working in negative coordinate space, which LightBurn does not support.

    You can view the gcode that LightBurn emits by clicking “Save GCode” instead of “Start” – the generated code is identical.

    #2130

    Sauron
    Participant

    Ok, I’ve switched GRBL to work in positive space – sadly this requires reflashing firmware and I’m not sure how other tools (used with spindle) will work with this. But this results only in X/Y being positive (left/lower corner 0/0), Z is (and have to be) negative. When I enable Z axis in device setting, every program starts with moving Z axis top and hitting limit switch. Interesting thing is that this command (moving Z axis) does not exists in exported GRBL file. So GRBL output is not exactly as running program within LightBurn?

    This is example of exported gcode – no Z movement

    G00 G17 G40 G21 G54
    G91
    M4
    ; Cut @ 5 mm/sec, 50% power
    G0X15Y7.5
    G1X-0.04Y-0.77S3500F300
    G1X-0.11Y-0.74
    G1X-0.19Y-0.72
    G1X-0.25Y-0.69

     
    <div></div>

    #2131

    LightBurn
    Participant

    GRBL file output in LightBurn should be exactly what is saved to disk – the code generator doesn’t know the difference between saving for sending or saving for disk, so they should be exactly the same – I can’t explain the results you’re getting. Are you sure you had Z enabled when you saved the GCode file to disk?

    #2133

    Sauron
    Participant

    Ok, my mistake – it’s because LB adds Z movement only when it start position is not Z=0 (and I’ve tested with homed and moved laser). When it does – there is no Z movement both in gcode or program run directly.

    So in this case – why LB moves Z to 0 on beginning of every program anyway? This should never be the case (unless with this type of machines) – I start with moving Z to position where it’s focused properly on material and then run the program. Z should be only moved if I check in cut mode, to “Z step per pass (mm)”.

    Another thing/question – doesn’t “Relative Z movement” should change gcode for Z movement (don’t look at coordinates – it’s different circle program)?

    sauron@warsztat:/tmp$ head withoutZrelative.g
    G00 G17 G40 G21 G54
    G91
    M4
    ; Cut @ 6 mm/sec, 90% power
    G0X12Y6
    G0Z20
    G1X-0.03Y-0.61S6300F360
    G1X-0.09Y-0.6
    G1X-0.15Y-0.57
    G1X-0.2Y-0.56
    sauron@warsztat:/tmp$ head withZrelative.g
    G00 G17 G40 G21 G54
    G91
    M4
    ; Cut @ 6 mm/sec, 90% power
    G0X15Y7.5
    G0Z20
    G1X-0.04Y-0.77S6300F360
    G1X-0.11Y-0.74
    G1X-0.19Y-0.72
    G1X-0.25Y-0.69

     
    <div></div>

    #2134

    LightBurn
    Participant

    Relative “Z movement only” is supposed to skip the initial Z move to the material height.  The next release adds the ability to specify the material height for GCode based systems, and hopefully cleans up some of the other inconsistencies with Z.  I’ll have a look at the gcode generator to see if there is anything amiss in there.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.