Reversing the direction of the axes

I attach the settings, see the picture.

I switch on the machine with laser head at the front left. After Lightburn starts and the position is loaded, the coordinates are 0.0, but after homing it is set to negative values.

Thank you for the recommendation. It would definitely be a way to compile my own driver, but I have no knowledge of that. So far, I’ve used MACH3, which behaves a little differently.

This is even better seen with laserGRBL, pictured above before and below after homing.

Your machine doesn’t have limit switches. There’s no homing for your machine. You manually “home” your laser by starting it at front-left.

Is there a reason why you’re trying to use the home button?

Let’s check one thing, though. Can you run these commands one at a time in Console?

$#
?

I installed the limit switches and they work. HOME is set when you press the button on the monitor. The axes just move. I know that absolute coordinates are not necessary for a laser, but I am used to them from a CNC milling machine.

Ah. Ok. That wasn’t apparent to me from your original post.

I agree that absolute coords is nice and limit switches make it easier. Are you aware that you’re perfectly capable of using absolute coords without the switches as long as you start in front-left?

Anyhow, if you the output of the commands from my previous post I can help you get this setup.

$#

[G54:-392.000,-407.000,-407.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

?

<Idle|MPos:-392.000,-407.000,0.000|FS:0,0|Ov:100,100,100>

ok

I’m sorry, I fight not only with the laser but also with English :slight_smile:

I suspect this is what is causing your situation. If I recall, Sculfpun doesn’t allow EEPROM changes but let’s see if we can clear it. That might apply only to $$ settings and not $# settings.

Type into Console:

G10 L2 P1 X0 Y0 Z0

Rehome and report back coordinate position.

ok

G10 L2 P1 X0 Y0 Z0

ok

$#

[G54:0.000,0.000,0.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]

Still a negative quadrant on the machine, G54 -G59 zero

Location indicator still out of range.
I found an area in config.h that probably describes my problem:
// After homing, Grbl will set by default the entire machine space into negative space, as is typical
// for professional CNC machines, regardless of where the limit switches are located. Uncomment this
// define to force Grbl to always set the machine origin at the homed location despite switch orientation.
// #define HOMING_FORCE_SET_ORIGIN // Uncomment to enable.

But I didn’t change anything like that.

Can you rehome and then type ? in Console and report back?

Also provide output of $$ please.

?

<Idle|MPos:-392.000,-407.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

ok

$$

$0=10

$1=25

$2=0

$3=0

$4=0

$5=0

$6=0

$10=1

$11=0.010

$12=0.002

$13=0

$20=0

$21=1

$22=1

$23=7

$24=100.000

$25=1500.000

$26=250

$27=3.000

$30=1000

$31=0

$32=1

$100=80.000

$101=80.000

$102=250.000

$110=6000.000

$111=6000.000

$112=1000.000

$120=1000.000

$121=1000.000

$122=1000.000

$130=395.000

$131=410.000

$132=200.000

ok

Can you confirm that you rehomed the machine? If so, can you power cycle please and try again? If not, can you home and rerun the ? command?

Laser On, Off, Homing, $$, ?
Waiting for connection…

Grbl 1.1h [’$’ for help]

[MSG:’$H’|’$X’ to unlock]

error:9

G-code locked out during alarm or jog state.

[MSG:Caution: Unlocked]

ok

[VER:1.1h.20190825:]

[OPT:V,15,128]

Target buffer size found

ok

ok

$$

$0=10

$1=25

$2=0

$3=0

$4=0

$5=0

$6=0

$10=1

$11=0.010

$12=0.002

$13=0

$20=0

$21=1

$22=1

$23=7

$24=100.000

$25=1500.000

$26=250

$27=3.000

$30=1000

$31=0

$32=1

$100=80.000

$101=80.000

$102=250.000

$110=6000.000

$111=6000.000

$112=1000.000

$120=1000.000

$121=1000.000

$122=1000.000

$130=395.000

$131=410.000

$132=200.000

ok

?

<Idle|MPos:-392.000,-407.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>

ok

Can you rerun $# also please?

$#

[G54:0.000,0.000,0.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

Well, that’s not what I expected. I expected the G54 to have been restored. In either case I think the issue is related to Sculpfun not allowing EEPROM changes.

Try this. After homing run:

G92 X0 Y0
?

Return results please.

G92 X0 Y0

ok

?

<Idle|MPos:-392.000,-397.000,0.000|FS:0,0|WCO:-392.000,-397.000,0.000>

ok

Okay, one more then:

$10=0
?
$#