Upgraded grbl: didn't go quite right

X-Carve 500 MM with Arduino-grbl controller
Upgraded to grbl 1.1
Easel driver 0.3.9
X-Carve as working prior to the upgrade. When I do the ‘Set up your machine’, enter the settings for the machine, and click ‘Confirm settings’, it connects and writes the settings. Then when it displays the ‘test your wiring’ page, the Z down then up arrows work but the X and Y arrows don’t make any movement happen. It freezes.

If I do a Machine menu:Home, the X-Carve will do a home just as before, coming to the left front of the machine, finding all 3 home position limit switches.

If I skip the setup and select a project and ‘Carve’, I can use the machine controls and move in all directions. (first right, back, and down to clear the limit switches.)

What’s wrong?

Check your $$. Most likely the upgrade changed/corrupted them and then Easel setup fixed it.

I need to find what the settings are supposed to be. Don’t have the original settings.

LarryM:
Do you have the configuration settings for grbl 1.1 ? It’s a different animal, having changed the x & y axis from moving + to moving -.

There are only a few differences and none of the movement parameters are different.
Grbl 1.1f [’$’ for help]
[MSG:’$H’|’$X’ to unlock]

$$
$0=10
$1=255
$2=0
$3=3
$4=0
$5=0
$6=0
$10=1
$11=0.020
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=3
$24=25.000
$25=750.000
$26=250
$27=1.000
$30=1
$31=0
$32=0
$100=40.000
$101=40.000
$102=188.947
$110=8000.000
$111=8000.000
$112=500.000
$120=500.000
$121=500.000
$122=50.000
$130=290.000
$131=290.000
$132=90.000

X0 Y0 used to be in the front left corner of the X-Carve, with numbers increasing with motion to the right and the rear… X0 Y0 are now in the rear right corner. Is this supposed to happen?

This is a compile time option.

The CNC industry arbitrarily defined the work area to be in the negative quadrant. Which is a fancy way of saying all co-ordinate numbers are negative.

Grbl uses that orientation by default. It also has a compile time variable that let’s you change the orientation so that the work space is in the positive quadrant.

I always run in the positive quadrant. It’s a personal preference.

Oddly enough i have this exact issue after updating to grbl 1.1f this evening. From what i gather tjere is a config.h file that im suppose to edit but i have no idea where it is or really if that is correct.

I downloaded the hex file from github and used xloader to send it to my machine. Changed all the settings to match the old settings and everything appears to work except when i home it shows machine posistion as -31.xx,-31.xx, and cant remember the z

In config.h

// 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.

Where is this file located?

It’s part of the grbl source code download from Github.

Ok i have no idea why i would need that. I dont believe ive ever downloaded the source code before. So If i dont have the config file on my machine, why would it change the setting?

This is the first time ive done anything to my grbl. Was still running the original .9j i got when i assembled and started my xcarve the 1st time through easel.

As i said all i did was download the hex from github and used xloader to send it to the xcarve

The setting is determined by whoever compiled the .hex file that you downloaded.

nevermind i figured it out

Are grbl 1.1 and Easel driver 0.3.9 compatible in the Machine setup process? It’s acting a lot like it doesn’t want to work in negative space. See my first post: x and y won’t move but z will.

Do you have soft limits enabled? If so, the setup process will probably be done before homing which may trip a soft limit?

Hi, Ben.

Sorry to have drifted your thread away from the main topic.

Your difficulties really don’t have a connection with grbl running in negative space. It is a Machine co-ordinate issue only.

If you home your machine, jog to your Work Zero position on your material, establish Work Zero at that location, then your G-code files should work correctly.

Your axes not moving is an independent problem.

Post your $$ output from grbl here.

I had $20 set to 1 but that is what was stopping the machine setup from moving the x & y. After changing it to $20=0, the setup worked as it is supposed to.

I still have an issue with setting $10 to 1 in order to display work position but it keeps changing back to 115. According to the grbl wiki, the settings should be 0, 1 or 2. (This is an issue outside of Easel. I have my own application that sends G codes)

I may try reflashing grbl with the HOMING_FORCE_ORIGIN uncommented if I can’t find a way to get the G10 L2 command working so I can work in positive space.

$0=10
$1=255
$2=0
$3=3
$4=0
$5=0
$6=0
$10=115
$11=0.020
$12=0.002
$13=1
$20=0
$21=1
$22=1
$23=3
$24=25.000
$25=750.000
$26=250
$27=1.000
$30=12000
$31=0
$32=0
$100=40.000
$101=40.000
$102=188.976
$110=8000.000
$111=8000.000
$112=500.000
$120=500.000
$121=500.000
$122=50.000
$130=290.000
$131=290.000
$132=100.000

$10=1 should work.

$20=1 should work.

Might want to turn $21 off ($21=0) that’s hard limits.

G10 L2 should work. That’s not a positive/negative space issue.

Looks like you may have an issue with Z axis calibration.

You shouldn’t have any problems using your own G-code sender. As long as you don’t use any G-code command that operates on Machine co-ordinates as apposed to Work co-ordinates, you shouldn’t see any difference when operating with negative space.

If you use the correct Machine co-ordinates that should work with machine co-ordinate G-codes.