How to repeatably break the Z limit switch on an HDZ

So,

I think I’ve caught it in the act, but I’ve probably still missed some things…

After going through a couple of limit switches on the Z axis on my HDZ I figured it was probably user error or some odd combination of actions that caused an occasional overtravel which results in a broken Omron mechanical limit switch as they are not able to withstand the load of being pushed in hard enough to shear off the locating peg on the housing.

Being the sort of person who thinks twice is unlikely to be coincidence or accident, when I replaced the second broken switch I carefully avoided putting the locating peg into the matching hole on the HDZ aluminium plate as this was a key part of the ability to destroy the switch in an over-travel event, I rely on the substantial friction and a small rubber O ring instead to hold the switch in place;

I’ve now found an entirely repeatable method of causing the overtravel which will break the switch quite effectively, if you have it mounted as per the design.

All you need to do is set your retraction height on your toolpath in Fusion 360 to be greater than the remaining Z travel after setting Z zero, which can happen quite easily on a tall workpiece or long bit. The job will start, the HDZ will retract to the normal height for tool insert, spindle start prompts, then the toolpath starts and at the first Fusion360 CAM retract for a rapid, clunk, brrrrrrp skipping Z stepper and broken (or pushed out of the way) Z limit switch.

So, now that I’ve been able to repeat the event with what I think is a ‘reasonable’ series of actions (reliably enough to take pictures as it happens);

  • Zero Z height above tall-ish workpiece
  • Set enough retract height in Fusion 360 to clear clamps during rapids (40mm in this case)
  • Start job

I think I’m now inclined to call this a design fault (which we can hopefully get fixed with a better designed mount for the proximity limit switch)

Fortunately my deliberately bad mounting of the Z limit switch has avoided me breaking my remaining stock of spare switches.

What mistake have I made that I’ve not spotted here?

Should I turn on the soft limits option in the controller? Would this prevent the over-travel and stop the job where I exceed the machine limits?

Thx

3 Likes

Could you take a couple videos at different angles?

Just kidding!

So the first pic it’s mounted with an o-ring instead of in the OEM hole and the second pic is of the locating boss being sheared? Do you ever shear the boss/peg during initialization? Could the holes have been positionally off from manufacturing?

2 Likes

:wink:

Yep, in the first pic it’s in the “new normal” position where the peg isn’t home in the matching hole in the HDZ motor mount plate so that the switch can rotate around the mounting bolt if Z axis push comes to shove.

And in the second, the switch is being shoved out of position by the Z hitting the physical limits of travel (which occurs after the ‘home’ position, I think it has to as it couldn’t work otherwise). If the switch was mounted as per design it would likely have broken the contact mechanism and sheared off the locating peg as on the last two switches.

Nope, the init as well as the “STOP” in CM both seem to read the switch and stop as soon as the contact closes.

I don’t think there’s anything bad in the manufacturing, the holes all appear to be central in the motor mount plate, it’s just that the mechanical travel after the switch closes is sufficient to damage the switch.

I’ve been running it like this for months since I installed it and broke switches early on, so it’s not exactly a common occurence, I’ve just made a vertical clamp and was starting a job with little clearance when I managed to cause the event in a way I knew how to repeat.

This is relevant to me as I’m installing my HDZ today but I’m confused. Isn’t the idea of a limit switch that it will stop that axis travelling when the switch is activated? How is you z axis continuing to travel “through” the switch activation and break it?

Do the limit switches not interact/override the Gcode during a cut if you have an error in your setup (programmed retract height > available retract height)?

1 Like

First off, this is an edge case problem that only a few people have run into, so don’t worry too much. I brought it up because I couldn’t repeat the issue when it first happened and now I can, which will help figure out how to work around it.

In terms of the limit switch and stopping… I should have used the correct words and said “homing switch” as they’re not treated as a limit in normal operation (I believe) they’re only used during init to set the home machine 0 position for each axis as I understand it.

I have seen mention of a soft limits mode in GRBL but that’s all I know about that so far, hoping somebode here knows more about the specifics on the Shapeoko.

4 Likes

I have been through probably 6-8 of the switches. 5 on the z just like your picture. 1or 2 on the y and finally built a bracket to better hold it. Just waiting for the proximity switches.

Anyone got another source of either. C3d has been very accommodating with replacements.

Phil

Just for the record: the fact that the Z axis does not stop when hitting the switch when retract is set to something higher than the available remaining travel, is because the limit switches are intentionally ignored DURING a job, to prevent false positive detections (people would be about 9000 times madder that their 15 hours 3d carve was ruined due to a false limit switch detection near the end). And since there is no such thing as a perfect filtering/robust signalling (not without a lot of complications), false detections cannot be ruled out. So it’s a design choice, it’s debatable, but it’s the least of two evils, at least this is my understanding of why things are setup like this (and what a number of previous threads on this topic highlighted).

I for one would vote that switches be ignored only after the initial retract move.

One can enable soft limits (and/or even hard limits), but you need to know what you are doing, and it does not fit very well with the fact that CM has its own internal soft limits, so overall it is not recommended.

My $0.002: it’s just easier to double-check that your retract height is consistent with the available Z travel.

3 Likes

The switch, although a good switch, is simply in the wrong place. There isn’t enough overtravel in the switch to accommodate how far the axis (all of them) can move before hitting the physical stops. This is why they fail. You can also break them by pushing them past the “click” with your finger while trying to test an axis, or manually moving the axis into a stop. The switches are just plain mounted 1-2 mm too close to the edge on the entire machine (you can look up the total safe travel, and acceptable overtravel in the switch spec sheet). They’re great switches, but they don’t have the internal overtravel to manage where they’re mounted.

5 Likes

That seems to be consistent with the manufacturer’s data sheet for the switch family, 2.7mm overtravel.

I guess I’ll be continuing to mis-mount mine until those brackets for the proximity switches are available and I can switch over.

1 Like

Thx Julien,

I understand the noise problem with using the switches as limit, we’d need to do a whole load of de-noising for that to be remotely near the right balance.

With regard to the soft-limits though, Carbide can’t be the only machine that it’s best not to slam into the end-stops, is there any more reading / info you could point me to on how the soft limits work in GRBL and why they’re not a good idea with CM pls?

Phil,

I have got quite quick at soldering them :wink:

There’s a thread where the part numbers and digikey / mouser sources are discussed if that helps?

1 Like

About those soft limits, here’s a great post from @neilferreri

EDIT: and I mention this because he educated me on the fact that soft limits WILL address this retract crash (I initially thought they wouldn’t)

The fundamentals are on the GRBL page here

As to why CM has its own internal soft limits instead of using GRBL’s ones… I…would need to go and read about that in old posts and…I’m in a tunnel, I’m losing you…brzzzz… :slight_smile:

4 Likes

Thx Julien,

There seem to be a few informative threads with the right search string.

I guess I could choose to see this as another straw on the pile of excuses I’m building to go to the dark side and CNCjs…

But more seriously, I think it’s worth spelling out to HDZ users that it is possible to physically damage to the home switch just by exceeding the retract limit until there’s a fix with either proximity switches or a mount that’s within the allowable overtravel from the vendor. It might save support some postage on new switches for starters. From experience I know how frustrating it is to not be able to continue because you can no longer initialise your machine after mashing the Z home switch.

The fix being something like “If you are setting a high zero for a tall workpiece or an ‘air cut’ be very very careful with your retract heights in your CAM software and make sure you’re not going to hit the Z limit” - or do what I have done and file off the locating peg on one side of the switch and make the position check a regular maintenance item.

3 Likes

Why not just go simple and add a hard stop? Looks like a longer Z stepper bolt just might work.

3 Likes

Yeah,

I was reading a thread yesterday on mycncuk where a guy 3D printed the secondary wipers for his HiWin rails out of a flexible filament and I was thinking that printing a “bumper” for the Z travel might work quite well for a softer and less switch-mashing impact.

2 Likes

Incorporate the switch overtravel limit into the hard stop bumper that is also the switch mounting bracket that swings out of the way instead of breaking. :smiley:

3 Likes

The solution in my case, (I broke one about 2days after installing the HDZ and never got a replacement)
Was to make a simple aluminum bracket to hold one of my $0.25 lever arm switches I had on hand. It’s worked fine ever since. And it has overtravel of probably 10mm before it will break or even move… I don’t use fusion, so that was not my problem… I’d bet you can find similar with same hole dimensions.
While the oem switches are not cheap, as I’ve mentioned before, they are VERY Fragile

4 Likes

Having looked at the problem for a while I thought that the shave the pin off the switch idea was probably not likely to be generally acceptable to other HDZ owners, I also wanted to keep the very repeatable precision Omron switches (I’ve used Omron before and their stuff is Japanese quality for the most part).

I have implemented a simple rubbery buffer instead which allows the Z to home but provides a soft landing when the GCode sails past the disabled soft limits and heads for a home switch mashing hard stop. This is only until I can replace the whole lot with proximity switches as a permanent solution;

Two layers of the 3mm thick neoprene rubber stuck together and cut to match the shape of the Z stepper mount, that’s approx 6mm or 0.25 inches (which is how much more than the 2.7mm allowable the HDZ over-travels);


This is then stuck to the bottom of the Z motor mount where the top of the moving Z carriage otherwise impacts it, next to the home switch;

During homing there is still clearance with the switch in the normal position and the homing appears to work normally, however there is not sufficient compression in the rubber to allow for switch crunching over-travel, probably also a bit better for the ballscrew to take a soft landing on the physical travel limit;

It’s not very pretty but it’s simple, cheap and works.

5 Likes

Very cool hack, I like the simplicity.

3 Likes

I would love to see an official Carbide3D “solution” to this problem. I have an HDZ which has worked fine for hundreds of carves since I installed it, but a few weeks ago on the initialization sequence it crushed the Z limit switch. I wonder if the switch went bad before the initialize causing the Z to crash on the sequence but who knows.

I wonder if the inductive homing switch retrofit which is supposedly coming “soon” will resolve this.