after homing to X-Min: Unable to jog toward X+, will hit soft-limit

[kovmarci86]

My machine has homing switches on Y-min, X-min. After homing, continuous jog control does not work and gives the error: Unable to jog toward X+, will hit soft-limit

I'm using OpenBuilds Control v1.0.370.

Based on all the information I think OpenBuilds Control expects homing switches at another location. This is a large machine and it would be nice to be able to use this setup. I believe the step directions and homing directions are configured correctly.

The machine seem to work well, only the jog feature is affected.

My config:

$0=6  ;  Step pulse time, microseconds
$1=254  ;  Step idle delay, milliseconds
$2=15  ;  Step pulse invert, mask
$3=6  ;  Step direction invert, mask
$4=0  ;  Invert step enable pin, boolean
$5=0  ;  Invert limit pins, boolean/mask
$6=0  ;  Invert probe pin, boolean
$10=1  ;  Status report options, mask
$11=0.010  ;  Junction deviation, millimeters
$12=0.002  ;  Arc tolerance, millimeters
$13=0  ;  Report in inches, boolean
$20=1  ;  Soft limits enable, boolean
$21=1  ;  Hard limits enable, boolean
$22=1  ;  Homing cycle enable, boolean (Grbl) / mask (GrblHAL)
$23=1  ;  Homing direction invert, mask
$24=25.000  ;  Homing locate feed rate, mm/min
$25=1800.000  ;  Homing search seek rate, mm/min
$26=250  ;  Homing switch debounce delay, milliseconds
$27=3.000  ;  Homing switch pull-off distance, millimeters
$30=13800  ;  Maximum spindle speed, RPM
$31=0  ;  Minimum spindle speed, RPM
$32=0  ;  Laser-mode enable, boolean
$33=0  ;  Spindle PWM frequency
$34=0  ;  Spindle off Value
$35=0  ;  Spindle min value
$36=0  ;  Spindle max value
$37=1  ;  Stepper deenergize mask
$38=100  ;  Spindle encoder pulses per revolution
$39=0  ;  Enable printable realtime command characters, boolean
$100=80.000  ;  X-axis steps per millimeter
$101=80.000  ;  Y-axis steps per millimeter
$102=400.000  ;  Z-axis steps per millimeter
$103=800.000  ;  A-axis steps per degree
$110=8500.000  ;  X-axis maximum rate, mm/min
$111=8500.000  ;  Y-axis maximum rate, mm/min
$112=400.000  ;  Z-axis maximum rate, mm/min
$113=200.000  ;  A-axis maximum rate, deg/min
$120=320.000  ;  X-axis acceleration, mm/sec^2
$121=320.000  ;  Y-axis acceleration, mm/sec^2
$122=40.000  ;  Z-axis acceleration, mm/sec^2
$123=30.000  ;  A-axis acceleration, deg/sec^2
$130=1545.000  ;  X-axis maximum travel, millimeters
$131=1972.000  ;  Y-axis maximum travel, millimeters
$132=100.000  ;  Z-axis maximum travel, millimeters
$133=280.000  ;  A-axis maximum travel, degrees
$I=����������������������������������������������������������������

[petervanderwalt]

My machine has homing switches on Y-min, X-min.

Yet you have $23=1 ; Homing direction invert, mask (only telling Grbl X is at Min, Y and Z at max as expected.

CONTROL works fine with Grbl 1.1 (standard version) check your settings and make sure its not a custom compile, use default official Grbl

[kovmarci86]

Thank you @petervanderwalt for taking a look. I think I will need to invert the motor wires then.

[kovmarci86]

Hi @petervanderwalt , I was wrong in the description, sorry. My limit switches are on the far left corner. I believe that is Xmin, Ymax (I said Ymin, which is wrong). I have some experience with 3d printers, but I'm new to GRBL.

The machine jogs the way i think is correct. Up arrow moves Y to the far side, Left moves X to the left, page up moves the spindle up. Compared to the home point, the machine works in negative Y and positive X.

I still think this issue exists, or there is a correlation between the pin invert mask and the jogging logic. Something I don't understand.

It seems the machine is moving correctly, but the soft limits expect the machine to move in negative X too.

Do I need to physically invert the motor direction to remove the invert mask to have this fixed? (this would make sense if the jogging logic depended on the direction pin invert mask besides looking at the homing direction).

[petervanderwalt]

but the soft limits expect the machine to move in negative X too.

Then you havent read the Grbl Wiki if you don't understand that bit. The whole machine lies in negative quadrant: Why is Grbl in all negative coordinates after homing? Or it so annoying and not what I'm used to!