Shapeoko XXL maxing out X/Y axis at job start

[bhamm (Bryce Hamm)]

I just updated my Carbide Create and Carbide Motion software, prior to doing so I had ZERO issues with running jobs on my Shapeoko XXL. The XXL will home correctly, however, when I try to start a job, the router/z-axis move to the rear of the machine and jam up. I feel like the machine is searching for a bitsetter or trying to find a touch probe but I do not use either one of them. I manually set my machine each job.

I added an icloud (https://www.icloud.com/photos/#0li2N0Vh9svrZU0KG5M9xe32g) link with two videos, one showing homing being completed successfully, the other showing the problem that started after I updated my software. Has anyone else ran into this issue?

[fenrus (Arjan van de Ven)]

would you mind taking / posting a screenshot of your settings screen in carbide motion?
(saves us from asking a series of questions )

[bhamm (Bryce Hamm)]

Here are the settings in Carbide Motion.

[Julien]

Hi @bhamm

Can you grab a copy of your GRBL settings and paste it here for a quick check ?
Use the “Show log” button in the Settings Window, then go to the MDI tab, send “$$” (without the quotes), and copy/paste the content of the log window.

[bhamm (Bryce Hamm)]

I followed your directions and this is the output that I copied;

$$
$0=10
$1=255
$2=0
$3=6
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=40.000
$110=10000.000
$111=10000.000
$112=5000.000
$120=500.000
$121=500.000
$122=400.000
$130=845.000
$131=850.000
$132=100.000
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]
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 M56 T0 F0 S0]
ok
$$
$0=10
$1=255
$2=0
$3=6
$4=0
$5=0
$6=0
$10=255
$11=0.020
$12=0.010
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=2000.000
$26=25
$27=3.000
$30=1000
$31=0
$32=0
$100=40.000
$101=40.000
$102=40.000
$110=10000.000
$111=10000.000
$112=5000.000
$120=500.000
$121=500.000
$122=400.000
$130=845.000
$131=850.000
$132=100.000
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]
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 M56 T0 F0 S0]
ok

[Julien]

Those settings are correct, so the investigation continues…

[bhamm (Bryce Hamm)]

I looked over the upgrades done to CM with V5, and this is from 513 “- (NEW) Bitsetter location not cleared when disabled” is it possible that my machine thinks there is a Bitsetter installed and is trying to utilize it?

[KevinCarr1996 (Kevin Daniel Carr)]

Does your .NC program you’re trying to run have initial moves in the positive X/Y directions?

Try typing into the MDI “/G21” (not the quotes, of course).
If that doesn’t do anything, try typing “/G20”

Is your G-code in mm or inches?

[bhamm (Bryce Hamm)]

The g-code is in Inches.

If I type “/G21” this is the output:

G21
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]
ok
$G
[GC:G1 G54 G17 G21 G90 G94 M5 M9 M56 T0 F300 S0]
ok

If I type “/G20” this is the output;

G20
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]
ok
$G
[GC:G1 G54 G17 G20 G90 G94 M5 M9 M56 T0 F300 S0]
ok

[KevinCarr1996 (Kevin Daniel Carr)]

Try running your G-code in-between you trying those commands.

Is this a program you’ve used in the past? Can you upload the g-code?

[bhamm (Bryce Hamm)]

I typed command “/G21” and then tried to run the G-Code and it did the same thing.

One thing I noticed is when I initialize the machine the gantry rests at X: 7 / Y: 7 (both numbers positive values). When I use rapid position and move the gantry the values of X & Y are negative. (First image shows gantry at Center-Front* closest to the front of the machine); however, when I try to run a job the gantry tries to move positive which is causing the issues (image 2). It like my job is in negative values but the machine is trying to run positive values.

[David.Curtis]

I think the last screenshots you posted look exactly as they should. They indicate that your homing zero point is in the far back right corner of your machine (7mm north and 7mm east of WCS zero) When you jog to center-front, you’ll see negative numbers, as you’ve moved down and left of WCS Zero point.

Where are you zeroing on your stock? If you tried to start a job without re-zeroing on stock (lower left) then it will indeed rapid to the back-right (your zero point) then start working up from there. Jam up, lose steps and make that noise.

[KevinCarr1996 (Kevin Daniel Carr)]

Since your machine is homing in the top right (Machine zero), and the rest of it’s travel is to the bottom left, it will always show negative values as the machine coordinates. Where are you zeroing your work coordinates? I’d start there first.

Maybe for the time being, try typing “$21=1” - This will turn on “Hard limits”, so when your machine does try and over-travel into the limit switches, it won’t keep trying to go and will shut down power to the steppers.

If it’s not your G-code or your WCS zero, it seems to me like Carbide Motion might be trying to convert your G-code to metric and over-traveling for some reason. When I was helping my buddy set his machine up, I send a hard command through Carbide Motion as “/G20” to change the default units to inches (Or that’s what I was hoping anyways). It ended up doing some weird things and over-travelling with simple, small G91 moves. I changed it back with “/G21” as soon as I realized that was the issue and it was fine after that. I think carbide motion does some weird things in the background sometimes to make things more user friendly (But sometimes screws what you think you’re doing up). I don’t use carbide motion because of that.

[bhamm (Bryce Hamm)]

KevinCarr1996 and David.Curtis you guys ROCK!!! I needed to re-zero the gantry in the SW corner and it resolved the problem. Prior to upgrading Carbide Motion I never had to re-zero the X or Y; only the Z. I cannot thank you all enough for your support and prompt replies; I truly appreciate the help!

Out of curiosity, KevinCarr1996, what program do you use instead of Carbide Motion?

[bhamm (Bryce Hamm)]

Thank you for showing me the the command for turning on Hard Limits, I didn’t know this was possible. It will be nice to not hear the stepper motors when I make a mistake!

[KevinCarr1996 (Kevin Daniel Carr)]

@bhamm I use CNCjs I use a raspberry pi with Linux, so even if I wanted to, Carbide Motion isn’t supported on linux.

Also, question. If you never re-zero your WCS, how do you position the machine to your work? Do you just align your stock to the same position with the same G-code zero every time?

[bhamm (Bryce Hamm)]

I’ll have to look into CNCjs, I have a RaspberryPi 3 laying around somewhere, might be time to put it to use. As for your question on re-zeroing the WCS, I just align my stock to the same position; I can say I’ve probably been doing this wrong the whole time This little learning experience has revealed to me how little I actually know about this machine and how the software operates.

Going forward, I am going to re-zero every job and try and break my lazy habits.