Homing sequence

[thawkins]

The default homing sequence, homes X, then Y and then finally Z.

This is not very safe as it risks dragging the tool across obstacles on the bed, the correct sequence is to home Z first so it is lifted away from the bed, and then home the other axis.

[bdurbrow]

Homing behavior is - at the moment - inherited from the main, official Grbl-mega distribution. I haven't done anything to it yet. My testbed machine (an old MaxNC 10) is in pieces right now, but is about to be put back together; with homing switches (it didn't come with them) and a brushless spindle motor (the kind used for big RC airplanes); and after get it together I will address this.

Related is auto-squaring for gantry style machines; which I will have to address also (I have the pieces for an 2020 extrusion based router that will need it).

I don't know how long it will take for me to get to this.

FYI: https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle

[thawkins]

I have just completed a 2020 based router with conventional moving bed, and im starting on a 4040 design that will use dual y sliding gantry, the 700mm ball screws and mounts for that just arrived today. Im going to use a hybrid design with vwheel based gantry motion but linear guide rods (16mm) for the x carriage,

The 2020 machine has grbl-Mega on it, I can sort out the homing order and raise a pull request for it if that is ok.

On Tue, Sep 24, 2019, 6:01 PM Britt, notifications@github.com wrote:

Homing behavior is - at the moment - inherited from the main, official Grbl-mega distribution. I haven't done anything to it yet. My testbed machine (an old MaxNC 10) is in pieces right now, but is about to be put back together; with homing switches (it didn't come with them) and a brushless spindle motor (the kind used for big RC airplanes); and after get it together I will address this.

Related is auto-squaring for gantry style machines; which I will have to address also (I have the pieces for an 2020 extrusion based router will need it).

I don't know how long it will take for me to get to this.

FYI: https://github.com/gnea/grbl/wiki/Set-up-the-Homing-Cycle

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bdurbrow/grbl-Mega/issues/13?email_source=notifications&email_token=AAADRSOT5ORWQPINBUWU6VDQLHQN7A5CNFSM4IZJ7TMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7N2AWY#issuecomment-534487131, or mute the thread https://github.com/notifications/unsubscribe-auth/AAADRSKHPXGYBOCX4V7QCHTQLHQN7ANCNFSM4IZJ7TMA .

[bdurbrow]

The 2020 machine has grbl-Mega on it, I can sort out the homing order and raise a pull request for it if that is ok.

Eh... just push the changes to your fork; I prefer to use Xcode's FileMerge; so once it's uploaded I'll take it from there.

[Saur0o0n]

Hi,

About homing sequence - fist of all, Thawkins is right - it should be Z and them X/Y. config.h

#ifdef DEFAULTS_RAMPS_BOARD
  #define HOMING_CYCLE_0 (1<<X_AXIS)   // Home X axis
  #define HOMING_CYCLE_1 (1<<Y_AXIS)   // Home Y axis
  #define HOMING_CYCLE_2 (1<<Z_AXIS)   // OPTIONAL: Home Z axis 
#else
  #define HOMING_CYCLE_0 (1<<Z_AXIS)                // REQUIRED: First move Z to clear workspace.
  #define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS))  // OPTIONAL: Then move X,Y at the same time.
  // #define HOMING_CYCLE_2                         // OPTIONAL: Uncomment and add axes mask to enable
#endif // DEFAULTS_RAMPS_BOARD

Sequence is probably wrong (by default) - because DEFAULTS_RAMPS_BOARD is set. This is something definitely to address - preferably by just removing this if.

But I have another issue. My homing can't finish. I've just assembled all wiring (not for DRO - just all steppers/endstops/spindle) and started testing machine. On the beginning I've disabled Z homing (because it was not installed) - so it was only

  #define HOMING_CYCLE_0 (1<<X_AXIS)   // Home X axis
  #define HOMING_CYCLE_1 (1<<Y_AXIS)   // Home Y axis

This made X homing correctly, but Y homing stopped before reaching endstop (but it reacted as it would reach it - did retract and probe again). I've tested few times. I thought that this is perhaps because I've disabled Z - so I've finished Z axis and run full homing X,Y,Z.

Now X and Y are Ok - Z stops before reaching endstop.

I've checked with multimeter and endstop is not triggered when grbl stops homing. Any idea what's going on? I'll probably in saturday check with vanilla grbl mega.

You can see failed Y homing here (you can see it does not reach blue endstop): https://youtu.be/MwiHUuFwyto

[thawkins]

This verson definatly homes correctly, aside from the order, check the softlimits (table size) see if they are correct, i think homeing stops if movement has been more than 100% of limit size.

On Fri, 1 Nov 2019, 04:56 Adrian Siemieniak, notifications@github.com wrote:

Hi,

About homing sequence - fist of all, Thawkins is right - it should be Z and them X/Y. config.h

ifdef DEFAULTS_RAMPS_BOARD

define HOMING_CYCLE_0 (1<<X_AXIS) // Home X axis

define HOMING_CYCLE_1 (1<<Y_AXIS) // Home Y axis

define HOMING_CYCLE_2 (1<<Z_AXIS) // OPTIONAL: Home Z axis

else

define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace.

define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time.

// #define HOMING_CYCLE_2 // OPTIONAL: Uncomment and add axes mask to enable

endif // DEFAULTS_RAMPS_BOARD

Sequence is probably wrong (by default) - because DEFAULTS_RAMPS_BOARD is set. This is something definitely to address - preferably by just removing this if.

But I have another issue. My homing can't finish. I've just assembled all wiring (not for DRO - just all steppers/endstops/spindle) and started testing machine. On the beginning I've disabled Z homing (because it was not installed) - so it was only

define HOMING_CYCLE_0 (1<<X_AXIS) // Home X axis

define HOMING_CYCLE_1 (1<<Y_AXIS) // Home Y axis

This made X homing correctly, but Y homing stopped before reaching endstop (but it reacted as it would reach it - did retract and probe again). I've tested few times. I thought that this is perhaps because I've disabled Z - so I've finished Z axis and run full homing X,Y,Z.

Now X and Y are Ok - Z stops before reaching endstop.

I've checked with multimeter and endstop is not triggered when grbl stops homing. Any idea what's going on? I'll probably in saturday check with vanilla grbl mega.

You can see failed Y homing here: https://youtu.be/MwiHUuFwyto

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bdurbrow/grbl-Mega/issues/13?email_source=notifications&email_token=AAADRSJF2WDMVHPWXWUVBWTQRNBA5A5CNFSM4IZJ7TMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECZHCHY#issuecomment-548565279, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADRSOZR2VMCLFWPPRO6FTQRNBA5ANCNFSM4IZJ7TMA .

[Saur0o0n]

When soft limit is triggered - there is message corresponding to it (ugsplatform) so this is not a case here.

[bdurbrow]

From limitswitches.c:

      // Set target based on max_travel setting. Ensure homing switches engaged with search scalar.
      // NOTE: settings.max_travel[] is stored as a negative value.
      max_travel = max(max_travel,(-HOMING_AXIS_SEARCH_SCALAR)*settings.max_travel[idx]);

max_travel is then used to set the target for the homing move - so if settings.max_travel[idx] isn't a large enough value the homing will end prematurely.

Softlimits are only checked in mc_line(); and limits_go_home() bypasses that and goes straight to plan_buffer_line() - so you won't get a softlimit error from homing.

What's odd if the problem is too-low a value in settings.max_travel[idx] is you should be getting an alarm:

if (approach && (rt_exec & EXEC_CYCLE_STOP)) system_set_exec_alarm(EXEC_ALARM_HOMING_FAIL_APPROACH);

I've added some serial print commands to limits_go_home() and attached that to this post. Hopefully that will shed some light on the issue.

limits_go_home_print.cpp.zip

[Saur0o0n]

Thx, for the code. I've run it - X,Y went fine, Z - as before, was triggered (without error) before hitting endstop. I've attached also $$.

Grbl 1.1g ['$' for help]
[MSG:'$H'|'$X' to unlock]
$0=10
$1=255
$2=0
$3=4
$4=0
$5=0
$6=0
$10=1
$11=0.020
$12=0.002
$13=0
$20=1
$21=1
$22=1
$23=7
$24=500.000
$25=2000.000
$26=250
$27=7.000
$30=12000
$31=0
$32=0
$100=37.037
$101=37.037
$102=100.000
$110=3500.000
$111=2500.000
$112=500.000
$120=100.000
$121=100.000
$122=100.000
$130=850.000
$131=550.000
$132=111.000
ok

00000001
3 1
0.0000
0.0000
0.0000
-1275.0000
0.0000
0.0000
00000000 00000000 00000000 
2 0
-7.0740
0.0000
0.0000
7.0000
0.0000
0.0000
00000001 00000000 00000000 
1 1
6.9930
0.0000
0.0000
-35.0000
0.0000
0.0000
00000000 00000000 00000000 
0 0
-6.8040
0.0000
0.0000
7.0000
0.0000
0.0000
00000001 00000000 00000000 

00000010
3 1
-842.9948
0.0000
0.0000
-842.9948
-825.0000
0.0000
00000000 00000000 00000000 
2 0
-842.9948
-156.4922
0.0000
-842.9948
7.0000
0.0000
00000000 01000000 00000000 
1 1
-842.9948
6.9930
0.0000
-842.9948
-35.0000
0.0000
00000000 00000000 00000000 
0 0
-842.9948
-6.7230
0.0000
-842.9948
7.0000
0.0000
00000000 01000000 00000000 

00000100
3 1
-842.9948
-542.9976
0.0000
-842.9948
-542.9976
-166.5000
00000000 00000000 00000000 
2 0
-842.9948
-542.9976
-5.7700
-842.9948
-542.9976
7.0000
00000000 00000000 00001000 
1 1
-842.9948
-542.9976
7.0000
-842.9948
-542.9976
-35.0000
00000000 00000000 00000000 
0 0
-842.9948
-542.9976
-0.1000
-842.9948
-542.9976
7.0000
00000000 00000000 00001000 
ok

Now I'll do the tests with vanilla grbl - but it starts to look more like some electrical glitch that perhaps multimeter isn't fast enough to see. I'll hook up oscilloscope later.

[thawkins]

Try putting a 100pf capacitor across the switch contacts, you could be picking up noise spikes from the z axis stepper.

I use the makerbot style switches which have a built in lowpass filter and an indicator led, they plug straight in to tbe RAMPS card using tbe 3 pin jst connector

https://www.ebay.com/c/1653329084

I used to have lots of issues with noise on switches, but since switching to these i have never had a problem.

On Sat, Nov 2, 2019, 6:18 PM Adrian Siemieniak, notifications@github.com wrote:

Thx, for the code. I've run it - X,Y went fine, Z - as before, was triggered (without error) before hitting endstop. I've attached also $$.

Grbl 1.1g ['$' for help] [MSG:'$H'|'$X' to unlock] $0=10 $1=255 $2=0 $3=4 $4=0 $5=0 $6=0 $10=1 $11=0.020 $12=0.002 $13=0 $20=1 $21=1 $22=1 $23=7 $24=500.000 $25=2000.000 $26=250 $27=7.000 $30=12000 $31=0 $32=0 $100=37.037 $101=37.037 $102=100.000 $110=3500.000 $111=2500.000 $112=500.000 $120=100.000 $121=100.000 $122=100.000 $130=850.000 $131=550.000 $132=111.000 ok

00000001 3 1 0.0000 0.0000 0.0000 -1275.0000 0.0000 0.0000 00000000 00000000 00000000 2 0 -7.0740 0.0000 0.0000 7.0000 0.0000 0.0000 00000001 00000000 00000000 1 1 6.9930 0.0000 0.0000 -35.0000 0.0000 0.0000 00000000 00000000 00000000 0 0 -6.8040 0.0000 0.0000 7.0000 0.0000 0.0000 00000001 00000000 00000000

00000010 3 1 -842.9948 0.0000 0.0000 -842.9948 -825.0000 0.0000 00000000 00000000 00000000 2 0 -842.9948 -156.4922 0.0000 -842.9948 7.0000 0.0000 00000000 01000000 00000000 1 1 -842.9948 6.9930 0.0000 -842.9948 -35.0000 0.0000 00000000 00000000 00000000 0 0 -842.9948 -6.7230 0.0000 -842.9948 7.0000 0.0000 00000000 01000000 00000000

00000100 3 1 -842.9948 -542.9976 0.0000 -842.9948 -542.9976 -166.5000 00000000 00000000 00000000 2 0 -842.9948 -542.9976 -5.7700 -842.9948 -542.9976 7.0000 00000000 00000000 00001000 1 1 -842.9948 -542.9976 7.0000 -842.9948 -542.9976 -35.0000 00000000 00000000 00000000 0 0 -842.9948 -542.9976 -0.1000 -842.9948 -542.9976 7.0000 00000000 00000000 00001000 ok

Now I'll do the tests with vanilla grbl - but it starts to look more like some electrical glitch that perhaps multimeter isn't fast enough to see. I'll hook up oscilloscope later.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bdurbrow/grbl-Mega/issues/13?email_source=notifications&email_token=AAADRSIIMIGY5UZ62IUX3C3QRVHXPA5CNFSM4IZJ7TMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC4YR7Y#issuecomment-549030143, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADRSO27SLG732FUPVKFXDQRVHXPANCNFSM4IZJ7TMA .

[Saur0o0n]

I've gave up on testing with vanilla grbl-Mega - too much changes to do in code/or hw - and my workshop is not the best place for that ;). Anyway I've hooked up oscilloscope and there are no any voltage drops that could trigger endstop pin without hitting actual switch (I've set the trigger limit to 1V on oscilloscope), but on the other hand I was unable to catch faulty homing after that - so I'll continue later on.

thawkins: I use biffy micro-switches, those for 3d printers are too small for this task. Definitely small capacitors will eliminates some noises and I'll use them later on with endstop rework. For now my endstops are NO (normally open), I'll change them to NC and put all of them inline as it should be. I'm also thinking on switching to optical endstops. I was hesitating to do that so far (I have mechanical one on all my 3d printers, and older CNCs) but this should eliminated all the bouncing and should be more repeatable (large microswitches have quite large gap between open/close position).

[bdurbrow]

It looks like the ATMega is seeing an active (in-home) condition on the Y axis limit switch prematurely. Well, I think it is... on the cycle that's failing it's exiting with axislock[Y_AXIS] being all zeros; indicating that it thinks the Y axis limit did in fact trip.

I am thinking that the switch de-bouncing isn't working for noise rejection, also. So... I'm thinking I'll eventually re-work that (I don't know when I'll get to it, so do keep doing the work you are to eliminate the noise in hardware).

I do think that optical or inductive limit switches are the better option, given the choice. Inductive limits are sometimes used on 3D printers to sense the exact position of the bed for auto-leveling; so I would tend to think that they'd be good enough for homing switches on a CNC (obviously, for jig/fixture/vise location, you'd want to probe a reference surface, but just to get the machine back to zero it should be OK).

[thawkins]

inductive switches tend to have a fair amount of imprecision on the switching point, plus they need a ferric sensing surface, they wont work with copper or aluminium. I suspect optical would be better.

[Saur0o0n]

This Old Tony (from YT) did his CNC on inductive limit switches - I was very surprised with this (because of many reasons) - but for on thing, his frame is pure metal, so no problem with ferromagnetic surface ;) Yesterday I was unable to catch failed homing (I've added also capacitors - close to Atmega). But today, when I've closed case and removed oscilloscope - there it is again (on Z axis).

00000100
3 1
-842.9948
-542.9976
0.0000
-842.9948
-542.9976
180.0000
00000000 00000000 00000000 
2 0
-842.9948
-542.9976
9.2900
-842.9948
-542.9976
-7.0000
00000000 00000000 00001000 
1 1
-842.9948
-542.9976
-7.0000
-842.9948
-542.9976
35.0000
An error was detected while sending '$H': (ALARM:9) Homing fail. Could not find limit switch within search distances. Try increasing max travel, decreasing pull-off distance, or check wiring. Streaming has been paused.
Error while processing response <ok>: An unexpected command was completed by the controller.

this time it was only once (during fast homing) and the slow one did not manage to finish, since is was too far away from actual micro switch.

[Saur0o0n]

Quick updated. I've did not manage to find the problem on electrical level - two days ago false homing was happening quite often, but I was unable to catch it on oscilloscope (even at 5 us window) - so this is the most strange part for me. I've decided to replace cables for shielded one (all others, except power for spindle, are shielded, but I did not thought it will matter for endstops :/ ), so this should happen tomorrow, and I've prepared myself simple optoisolation board (similar in design to one at grbl manual). So tomorrow I'll test it all, with rework to NC (Normaly Closed) endstops - hope it helps so I could move on.

During the process I've manage to blow voltage regulator on Arduino (I thought, considering other devices, it could handle 24v - it can't ;) ) - I've replaced it, but after studding the schematic I've decided to go directly with 5V. This all external power supply on Arduino is designed a bit awkwardly - or it has not much power from USB, or it has to go trough diode+regulator that's just burning power, requires much higher voltage (more then 7V) and is also quite limiting. Anyway, I've omitted the regulator from power plug (this works exactly like giving +5V on 5V pin on Arduino board - but I find it more elegant this way). And also removed 5V path from USB - since I plan to use it (at least for now) all the time and current design does not disable USB power if external voltage is only 5V.

[bdurbrow]

If it's the same regulator as shown on the official Arduino schematics, then the max is 20v. Considering the number of regulators available with a 30v limit, and that 24v is a rather standard voltage to find in systems, I'm kinda surprised that the Arduino project didn't go with a higher-capacity regulator.

[Saur0o0n]

Documentation for original Mega says it's recommended <=12V but max is 20V, I have Chinese one - that is a bit different in power design, and also utilizes ams1117 voltage regulator that is described with this formula 1.5V≤ (VIN - VOUT) ≤ 12V. So nowhere near 24V. But anyway, all regulators are usable in very narrow voltage window - otherwise demand for heat dissipation would be too great for such a small chip. And I don't thing it's a good idea to use it constantly this way, for prototyping perhaps - but for constant usage, direct 5V power supply is much better choice.

[bdurbrow]

I’m thinking that something like the LM2596 buck regulator modules that are all over eBay might have been a better choice instead of a linear regulator... not that it really matters now...

[thawkins]

I just pull the D1 on the ramps card and power the ramps card 5v off a separate supply. Note that is you are planning to use 24v you have to remove the two poly fuses and replace them either with a link or an automotive blade fuse. The poly fuses are only rated for 16v.

https://www.ebay.com/itm/4pcs-20GA-Gauge-APM-ATM-MINI-Blade-Inline-Fuse-Holder-Car-Truck-Marine-Boat/173579339883?hash=item286a22886b:g:KrcAAOSwSVdbu~vQ

Alternative 30V poly fuses.

https://www.mouser.com/Circuit-Protection/_/N-5g3c?Keyword=polyfuse+radial+30v&FS=True

[Saur0o0n]

I’m thinking that something like the LM2596 buck regulator modules that are all over eBay might have been a better choice instead of a linear regulator... not that it really matters now...

Yes, I've used something similar I had at hand. Now I have 3 voltage levels in my controller,

• 48V, main voltage used for spindle, and X/Y motors
• 24V, used for Z, fans and additional metering hw
• 5V for Arduino and optocouplers

When I replace Z driver (It came wrong from China, but it's for free this way) with proper 48V I plan to get rid of 24V and keep only 48V and 5V. I would prefer 48V and 12V but mehh.. it will do.

I just pull the D1 on the ramps card and power the ramps card 5v off a separate supply. Note that is you are planning to use 24v you have to remove the two poly fuses and replace them either with a link or an automotive blade fuse. The poly fuses are only rated for 16v.

I must admit I don't understand your replay thawkins - what fuses? Where?

---

Anyway, I've replaced wires with shielded ones (and grounded them) and filed some microswitches (they are not that "micro" in my case ;) ) contacts - because they had a tendency not to contact very well from time to time. Another reason to go for optic. I've also changed connection to "normally closed" on all endstops.

This did not helped - still false positive endstops during homing.

But when I've added optocoupler board in between (the one I've showed two post before) It seems to fix the problem. I'm not sure yet, but few last homing sequenced where fine. Gotta try more :)

[Saur0o0n]

It seems those changes (shielding, optocouplers, capacitors) has stabilized endstops - there where no failures so far on homing.

But I have kind of strange question (it's not that strange if you use 3d printers) - does limit switches are also active during normal program run and jogging on GRBL? I'm asking because it happened to me twice, that MAX endstops did not worked. I don't remember if it was jogging or program move - I did a lot of changes, used different programs, switched to laser mode etc.

[Saur0o0n]

Some interesting insight - I did some testing on common optical endstops (IR diod + phototransistor in one case moc70t2) and they are quite prone to false reading because of the outside light. Without any dedicated lighting, just strong ambient light I was able to get false positive readings (even 4+V - not just 3V) on it. So I guess this is also no go. I stick with mechanical switches and ordered some inductive sensors (NC) for testing.

[Saur0o0n]

I've tested endstops during program run, they are triggered (message is shown on console) - but the program is not aborted. This is something that can be set? It doesn't look normal to me and I think previously (on vanilla grbl) program did abort.

[bdurbrow]

The RAMPS configuration disables the hardware limit switches because the interrupt pins are needed for the jog MPG. I'll look into providing a polling option; but this will decrease the system's performance somewhat... how much I don't know yet (might not be noticeable); and will depend on where I put the polling call.

The general idea however, was to home the machine; and then rely on soft-limit checking to keep the machine from running amok. A proper hardware solution would either send the step lines thru a set of AND gates so that the drivers can't get step signals when the machine is not in override mode; or send a disable signal to the drivers if a limit switch is triggered.

[Saur0o0n]

Well, that would explain why on vanilla it worked (hw interrupted pins for endstops). In general, soft limit should be ok - but since I'm still fiddling with my machine, from time to time there are some unexpected situations.

This could be another good reason to move to esp32 :)