[Solved] Problem with wiring GRBL and Gecko G540 - Homing Solution in 1st post

So I wired up my machine and I am able to get motion in all 3 axes. I am using an Arduino loaded up with GRBL and a Gecko G540 as the stepper driver.

I read on the Gecko manual that the G540 was designed to have NC limit switches. However,the GRBL README calls out for NO.

So I went for NO and wired each switch to its own input pin on the Arduino. D9, D10 and D12

Then during testing, I tried to perform a homing command on one of my axes and it crashed into the switch and broke it. Was just a little bit too slow to reach EStop. :frowning:
So before I try anything else, I wanted to find out where I went wrong.

Please ask me anything I need to clear up to help you guys help me.

Thanks in advance for your help.
Frank

EDIT: I had many problems with my setup.

  1. I couldn’t use easel because the inventables hex would not flash properly since I was using Windows 10. I cannot fully vouch for this, but XLoader didn’t work for me. Then when I tried flashing the arduino with the method linked below, I was able to use easel. I made sure that I DIDN’T “run as admin” on the .bat file.
    [Reference thread] Alternate method for .hex upload

  2. I was able to flash the main fork of GRBL on the first flashing, which provided me with the default GRBL settings. So I changed each one of GRBL’s settings by copying one of LarryM’s post of his settings.
    X-carve Grbl Default Settings - 500mm

  3. This is part of where I went wrong, having copied someone else’s settings my steps/mm was not calibrated to my machine, so whenever I sent a homing command, my machine would approach the Z-axis switch and it would click. Then it would back off as per the pull off distance, but since the calibration was off, it wouldn’t pull off far enough away so that the switch would open circuit again. This caused the homing operation to fail. So I increased my pull-off distance ($27=1) to ($27=10) just an arbitrary number that seemed like it would be large enough to pull away. After making that change, my machine pulled far enough away from the switch after the initial click. Then it would approach it again at a slower rate for a more precise re-positioning and pull off again. Then the X and Y axes followed. So my homing went perfectly finally!

Post your grbl settings here ($$ output from grbl) and the version # of grbl that you are running as a starting point.

**** Connected to COM4 @ 115200 baud ****

Grbl 0.9j [‘$’ for help]

$$
$0=10 (step pulse, usec)
$1=25 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.010 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=0 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=25.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=250.000 (x, step/mm)
$101=250.000 (y, step/mm)
$102=250.000 (z, step/mm)
$110=500.000 (x max rate, mm/min)
$111=500.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=10.000 (x accel, mm/sec^2)
$121=10.000 (y accel, mm/sec^2)
$122=10.000 (z accel, mm/sec^2)
$130=200.000 (x max travel, mm)
$131=200.000 (y max travel, mm)
$132=200.000 (z max travel, mm)
ok

First thing I would recommend is loading grbl from the Inventables fork. That version has the initial parameters that work best with the X-carve.

Alternatively, you can change the parameters to the default values one by one.

Look here:
If you have the 1000mm unit change $130 and $131 to 790.000 If you have the “new” version of the X-carve I think the default for X is 740.000

Then check this:

1 Like

Thanks for the reply. However I am having trouble using the .hex file from the link. When I send a command in UGS after loading the inventables.hex in XLoader, I get the message “GRBL has not finished booting”

But I think I can just use the .hex I was using originally and modify the settings from there. I am currently reading the Configuring GRBL page to learn what each setting is.

Also as you state in one of the links you posted, having hardware limits is not worth it (or something in the likes) if you do not have switches at both ends of the carriage direction. So I may look into setting that up in the future. Unless you think it is fine to have both hardware limits for homing and software limits for everything else at the same time.

(changing subject due to ideas popping into my head)
As I am reading, I am noticing that I did not have hardware limits on in GRBL which lead to the crash on my Z axis. So I am thinking with it on, I can actually achieve a homing cycle.

Please continue to advise I am not going to act hastily.

It’s getting late, so I won’t be playing with the machine until tomorrow, but I will be available to respond if I am able.
Thanks again.

Many times this is a baud rate issue. Version 0.9j and beyond use 115200 baud.

You can use homing/soft limits/hard limits all at the same time. My personal preference is to use homing and soft limits.

Your switch crash is either a wiring error or a parameter setting error or a bad switch. Having hard limits set would not have prevented the crash.

In XLoader, I made sure it was at 115200 baud. Also in UGS I checked the baudrate. And for some reason I checked the Arduino IDE if it was at 115200 baud.

I checked with my multimeter to see if all my switches were okay before powering on initially. I used the continuity function and got a short when I actuated the NO switches.

I wired all my switches to ground without daisy chaining and the other wire to D9 D10 and D12 respectively.

I believe the only problem was that hard limits were not set.

Nope. Homing does not require or use hard limits. Both soft limits and hard limits are temporarily turned off during the homing cycle.

Ok, now you need to check and see if grbl sees your switches changing.

Is there documentation to show me how to go about doing that? Or would you kindly teach me how?

EDIT: [Guide] Using Grbl to debug your homing switches

Just found your post. If there is anything else to add, please let me know. I’ll do some reading and come post here again with further questions as they come. Thank you much for your continued help if you so choose.

1 Like

update, I got and wired my new switch. Now in UGS I tried a couple things:

Enable $20, $22. This got me stuck in alarm lock and ask me to soft reset because when I send the homing command would end up in the positive range. That being out of range of the soft limits. So I would never be able to get out of that since it was stuck in loop of sorts.

Then I tried $21, $22. so my machine is no longer stuck. However, whenever I hit the switch after sending the homing command, the machine goes into alarm lock and totally skips the pull off.

Then I tried $22. The switches do nothing at all.

So I was wondering if the hex file from Inventables, has anything different other than machine specific grbl settings compared to the main grbl hex.

Do I need to restart computer if I want to flash a different hex file on the same board? Since maybe the serial monitors expect the previous hex file?

Could not having the spindle connected have an effect on whether the inventables hex on the arduino would be detected or not?

also, on easel, using the inventables hex, I am stuck on connect usb. But with main hex, I get stuck on writing configuration.

for reference, my setup only has limit switches on one side as per the instructions in Xcarve.

Did you do the test with grbl to see if the homing switches were working?

Not yet. had to stop for the day as it was getting hot. But I at least familairized myself more with the software and usage of the machine. I will use a different serial monitor that can do the direct communication with grbl tomorrow.

I held the Z switch and sent the ‘?’ command, then the X, and then the Y switch. This is with my motors off. At the end, I repeat the previous steps with my motors on but not moving.

<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:100>
ok
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:001>
ok
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:010>
ok
$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=19 (status report mask:00010011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=0 (homing dir invert mask:00000000)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=10.000 (homing pull-off, mm)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=300.000 (z max travel, mm)
ok



<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:100>
ok
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:001>
ok
<Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:010>
ok

So I changed the pull off back to 1mm ($27=1). I thought the deflection of the switch lever was bad so I pulled it off more. But I realized the switch must stay depressed. So the Z-axis now homes perfectly, pulling off 1mm (so it thinks, since not calibrated steps/mm yet). But it stops there, providing me with this.

Note: My actual position of the XY carriage is somewhere in the middle.
Edit: sorry for double post.

Grbl 0.9j ['$' for help]
['$H'|'$X' to unlock]
<Alarm,MPos:0.000,0.000,0.000,WPos:0.000,0.000,-81.578,Lim:000>
ok
[Caution: Unlocked]
ok
ALARM: Homing fail
ok

Grbl 0.9j ['$' for help]
['$H'|'$X' to unlock]
<Alarm,MPos:0.000,0.000,-1.000,WPos:0.000,0.000,-82.579,Lim:100>
ok

You do have a homing failure on the Z axis. Notice that after the ALARM: Homing fail and your restart of grbl the Z axis homing switch is stuck on.

Doesn’t mean the switch is failing, but once the Z axis tripped the switch, the system did not pull the Z axis off the switch.

Try it again, when you get the ALARM: homing fail, restart grbl and see if Lim:100 is the result. Then manually move your Z axis off the switch and do a ? command to get status and see if the Z axis switch is now open.

Note: If I get Z axis homing to pull off switch completely, so it opens again, the z axis goes back up. Not sure if this still happens since I was successfully able to flash the inventables hex file and reach the homing operation in easel. I was not able to before. I used the avrDude batch file you shared for when working with Win7+. I am using Win10.

<Alarm,MPos:0.000,0.000,-1.000,WPos:0.000,0.000,-82.579,Buf:0,RX:1,Lim:100>
ok
<Alarm,MPos:0.000,0.000,-1.000,WPos:0.000,0.000,-82.579,Buf:0,RX:1,Lim:000>
ok

The normal cycle when homing is for the machine to move Z up until it trips the switch. Once tripped the machine then moves the Z axis back down off the switch, changes the movement speed and then moves back to the switch to get a more accurate position. When the switch is tripped again then the machine moves off the switch and goes to do the X and Y axes, simultaneously.

Does it do this, or just contact the switch once and stop?

Oh so it may do that, but I never let it reach the switch out of panic when it slowed down and tried moving back.

Would it work if I just click the Z axis switch twice and then the Y then the X, assuming there isn’t actually anything wrong.

If it never reached the switch then you have false triggers, most likely due to electrical noise. Did you use shielded wire for your homing switches or the black and white wire that Inventables supplied?

I’ll have to check if pressing the switch twice will work, but I have to be away for awhile so I’ll have to get back to you on that.

I have shielded only on the steppers. But I added a filter electrolytic cap 0.47uf for each switch. But I’ve read that 100uf ceramic along with resistor would be better to create rc filter.

I would have to try again and increase the pull off because once the homing begins, the z approaches the switch and then does the initial pull off. Then it slows down and approaches the Z switch again and that’s where I panic and stop it.

But if I have a small pull off like 1mm, the switch remains closed and the homing operations halts there.

So I believe if I increase my pull off at least until I calibrate the steps/mm, I might have a successful homing cycle.

Edit: I was right. I just completed a full homing cycle and it happened exactly as you described.

So my problem was that the steps/mm was wrong, so the pull off was not large enough to back away from the initial click of the home switch. For example, my actual distance traveled on my z axis was about 4mm instead of the 10mm I had in my settings.

Now last thing I need to do is connect my spindle and I can get to carving! woot!

Thank you so much @LarryM for your patience and help.

2 Likes