Move Tab Jog Settings more in same direction

I was delighted to get my DIY machine working (still am) but have noticed an issue possibly there all along. Initially you find a way that works and stick to it, then after time, try out other features.

This is going to be a settings issue but not sure which. My machine homes via micro switches to bottom left, with the table at the lowest position. I use a macro to move the table up for set thicknesses. Normally my designs are model airplane parts cut out of a 4" by 36" piece of balsa (the size of my work area) and I use absolute co-ordinates. I move the bed up and down fractionally uses the move tab jog buttons until the focus is spot on.

Now, I’ve noticed that if I use the job button to go right, it goes left and triggers an out of bounds. If I use the jog button to move left, it moves left (so it’s not reversed). The only movement I have from home, triggers a microswitch. It’s the same on the other axis, click the up button and the gantry moves towards me trigger an out of bounds. Again, it’s not reversed, jogging the down button moves it down, causing an out of bounds. I can’t jog right or up and away from home. Any job button action causes an out of bounds except moving the table up and down which is perfect.

I’ve gone through the support topics and found one that states ensure $J is disabled. Mine is. Enabling it, the logic being that with automatic homing it might be needed and it makes no difference and switches itself to disabled again.

Fairly sure this used to work as I used it to nudge the laser left or right, up or down a fraction when framing.

Has anyone had this before, are there any suggestions?

It’s a GRBL machine with the latest version of Lightburn. Thanks in advance.

I am having the same issue with version 2.02. I fell back to version 1.7.08 and everything works correctly. Maybe a setting gets reset in v 2.02 but so far, I have not found anything different.

Thanks Phil

Your advice is much appreciated. The problem was spotted just after I’d upgraded to 2.0.2 but could not be sure it did not exist before. That suggests a setting has changed or a bug introduced. Downgrading to an earlier version is a valid workaround which I would do, however I have purchased a licence key and renewed that. Hoping that provides some support. I’ll leave this post up for now, in case anyone else can point me towards the setting that needs to be changed or a fix date.

Thanks again Phil. Keep an eye on this post, perhaps we might both get fixed.

Not much action on this topic so I have done as Phil kindly suggested, downgraded to 1.7.0.8. With that version, jog operations work perfectly. I exported the config file before and after and they are both identical (see below for output).

It does look to be a bug introduced with 2.0.2. This is a workaround rather than a fix and jobs I wanted to cut out are now saying they were done with a later version of Lightburn which could result in data loss.

Could someone from Lightburn take a look at this bug?

Thanks

Config file below
$0=10
$1=25
$2=0
$3=2
$4=0
$5=1
$6=0
$10=0
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=4
$24=25.000
$25=700.000
$26=250
$27=1.000
$30=1000
$31=0
$32=1
$100=20.031
$101=10.006
$102=1223.787
$110=1100.000
$111=1100.000
$112=50.000
$120=40.000
$121=40.000
$122=10.000
$130=914.000
$131=97.000
$132=28.000

It’s going from bad to worse. Now with the old version, I’m getting warnings that design files were produced with a later version and data loss could result. I noticed macros that move the bed to cut set thicknesses had lost their names. I upgraded to 2.0.2, accepting Jogging won’t work, but now the macros have been lost completely. I don’t have a backup.

Have seen this post Lightburn 2.0 - Console and Macro windows - Frustrating - #3 by comp and am going to see if I can get them back again. If not I’m going to have to do them all over again.

I’ve found Lightburn keeps copies of all the preferences so have got the Macros back again. Still not got working jogging yet. That does seem to be a 2.0.2 bug

I’ve been experimenting and there’s more to this. It’s not just jogging in the wrong direction, but the wrong distance as well. For example, home machine (bottom left) and then move head to centre of bed. Set ā€˜move’ to be 1 mm and click right jog button. It moves back towards home (left and towards me) until it hits a microswitch.

That suggests it is trying to move to the wrong position. It’s a GRBL controller, and is working in negative coordinates. When setting this up a long while back I used : -
G10 L2 P1 X-915 Y-98 Z-27
It both homes and cuts perfectly.

I’ve gone through previous posts and can see CastleWoodworking had a similar issue, which @berainlb provided some excellent wisdom for. This is the original post Where to start troubleshooting Major jog issues?

Is it that jogging uses a different offset which if wrong causes this effect?

Going through the same steps
$i provides :-
[VER:1.1h.20190830:]
[OPT:VD+,15,128]
Target buffer size found
ok

$# provides :-
[G54:-915.000,-98.000,-27.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
and ? provides :-
<Idle|WPos:914.002,97.001,0.000|FS:0,0|Ov:100,100,100>
ok

When setting up my DIY laser cutter, I applied G10 L2 P1 X-915 Y-98 Z-27 to make home bottom left.

Should I be applying a G10 L20 command as fixed CastleWoodworking and if so what should the parameters be?

Thanks in advance.

I’ve found this

and suspect it’s the same issue.

Am just trying to digest it.

Thanks Howard for doing the leg work and making attempting to nail it down as a bug. I hope they get a fix for us GRBL users soon (or at least acknowledge it).

Hi Howard,

If your device Origin, and home corner is currently front left but jogging is in the opposite direction in 2.0.02 - then try changing these settings to fix the problem:

In the Console Window, enter these lines one at a time:

$3=5
$23=3
$RST=#

These instructions should invert the movement directions of your axes (given their current configuration), while also ensuring they continue to home as before.

$RST=# will remove your G54 work coordinate offset (X-915 Y-98 Z-27) which will not be needed anymore.

Please carefully check the jogging of all the axes (including the Z-axis) to make sure everything is still ok.

Thank @NicholasL for the support.

Have done this. Homing still works.
Macros that move the table (Z axis) up to set positions causes it to move down and hit the end stops.
Jogging the table up did work but not moves it down till it hits the end stops.
Jogging right 1mm seems to take it top right.

Does not appear to have worked.

I have put $3 back to 2 and $23 back to 4, then applied the original offset of G10 L2 P1 X-915 Y-98 Z-27

It’s usable again (with jogging still broken) and am happy to take onboard any new settings.

Thanks again

Howard

Please try the latest version here which fixes some jogging issues:

If you still have an issue with jog direction after that - then try this to change the jogging direction at your machine for X and Y axis only;

$3=4
$23=2

Thanks @NicholasL

I went to install the release candidate but Lightburn offered it to me anyway. Just in time delivery.

Everything is working fine again.

@Philbert you may wish to try it.

Thanks for you support.

1 Like

This worked for me. Thanks Lightburn team!

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.