[SOLVED] UGC: Homing doesn't behave as it should [NOISE on LIMIT SWITCH]

Hi Guys,
I’m trying to set my X-Carve for the first time and I’m having some issue with the homing functionality.
I’m using an Arduino/gShield with grbl 1.1f and UGC to move the whole thing.

I’ve my limit switches connected in NC and in series (no filtering though). I updated the $5=1
From what I understand, when I start a homing function, the system should move until hitting the limit switches right ?

In my case, the Z goes down for few millimeters (just a homing mask to apply) then move X/Y for a little bit and then stop… No homing alarm, it just stop. I can start the homing function a bunch of time without hitting limit switches. If I hit a limit switch, the system keep running into it. The limit switches doesn’t seems to stop the homing.
I tested the limit switches electrically (multimeter) and with a ? report. The report is coherent with the limit position so at that point I don’t think the limit switches are a problem.

What is the real GCode behind a $h ? I would like to see if the $h is done correctly.

Also here is my $$:


Thanks guy

These grbl parameters are not set up for using the X-carve.

These are the parameters that I use on my 500mm machine with 1.0c. 1.1f should be similar. It is obvious from your parameter list that the version of 1.1f you have was not compiled for use with the X-carve.

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=115 (status report mask:01110011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=1 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$30=255. (rpm max)
$31=0. (rpm min)
$32=0 (laser mode, bool)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=188.947 (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=290.000 (x max travel, mm)
$131=290.000 (y max travel, mm)
$132=88.000 (z max travel, mm)

Thank you LarryM. I’m going to use your $$ for inspiration. I’ve a Xcarve 1000 with the last Nema23 steppers. What are the steppers on yours ?

I have the NEMA 23s from Inventables.

You need to determine the correct setting of $3 and $23 on your machine to get it to move in the correct direction and home in the correct direction.

I messed a little bit with the directions but not in details. Before I changed the parameters, the weird thing was that the motors seems to operate in the right referentiale when jogging but not when homing
Facing the X-Carve and using UCG commands
+Y away from me, -Y towards me
+X right, -Xbox left
+Z up,-Z down

But when I start homing it’s the not the same directions anymore. I can change $23 but I’m wondering why the homing is inverted. The Z goes down for instance

What you want to do is get the jogging working correctly with $3.

Once that is done get homing moving correctly with $23.

By definition, grbl moves the axes in the positive direction when homing.

Since the X-carve has its homing switches in the front and left you normally have to reverse them for homing so that the X and Y axis move negative for homing purposes.

Normally, Z moves up for positive and down for negative and doesn’t need to be reversed.

If you wired your machine differently than the build instructions call for then you may have to adjust the parameters to match your build.

So I got my homing problem figured out. The issue was coming from the limit switches.
I plugged an oscilloscope on the limit pins and found out that when the stepper were turning, false limit triggers were created by the noise. The electromagnetic noise was actually HUGE ! Enough to throw off the pull down resistor of the Arduino.

I use them in a NC configuration (it doesn’t matter if NC/NO) but the way I did the wiring they were very susceptible to electromagnetic noise. My limit witches are not connected through a twisted shielded cable.

So I used the optocoupler solution to isolate my switches from the Arduino. Some people advise to mount capacitors but with the level of noise I had, capacitors could have let some noise pass through. Overall the optocoupler would be the best solution for this kind of application. It’s pretty cheap and if you use perforated protoboard the electronic would be an easy project (even for a newbie who never really solder)
You can find the electronic diagram and parts in the bottom of this GRBL github page https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches
I consider this as an important upgrade of my X-Carve.
So if you have some sporadic behavior with your system, think about isolating your controller pins from electromagnetic noise.

Have a good one guys

The capacitor/resistor filters will do if your wiring is somewhat “noise reductor” (shielded cable, twisted pair). The more you’ve noise, the bigger your capacitors needs to be. But you can reach a point where too big capacitors can deteriorate the electronics. At first I thought about these filters because I had some capacitors around but when I saw the amount of noise… the optocoupler were the only good solution.
Capacitors and optocouplers are about the same price and as we don’t have RadioShacks anymore :sleepy:, it takes the same time to supply these parts :slight_smile:

Thanks for your help though PhilJohnson and LarryM, my GRBL configuration was way off :wink:

1 Like

Especially when it’s Friday evening and you know you’re stuck until monday + shipping time. I personally like Digikey, you can buy per unit and they ship the same day.

1 Like