3rd Party Controller Homing Busted on Y

I am in the middle of testing a 3rd party controller. I had it doing $H a few times but after an hour or so it got into a mode where it does the Z home and the X home as expected but not the Y. I doesn’t even move in Y during home. I can cut things just fine. This only happens during homing.

Trying to come-up with a theory to fix this. Any ideas?

I believe that this is configured by compile time options for Grbl, and maybe Grbl settings — please compare the latter with:

Yes Will that is on my list but it doesn’t explain why it might have changed when I didn’t set any parameters. I glanced at a $$ dump and didn’t see anything obvious but I will step through it tomorrow. Also checking the limit switch wiring since I have been having trouble with that.

Will suggested checking because some of the senders fiddle with the settings behind your back.

1 Like

It was a bad limit switch. Unfortunately it was one I just replaced a few days ago.

I’ve had some trouble with these myself. They seem a lot more fragile than I would think they should be. As long as you don’t fully depress them, they seem to hold up ok. I’ve broken a couple, and both times because I was moving things around by hand.

2 Likes

Agreed. They gave me the Digikey part listing and I bought a 1/2 dozen. Will probably look for a robust alternative at some point.

Here is that info (from the wiki apparently): http://www.digikey.com/product-detail/en/omron-electronics-inc-emc-div/D2QW-C003H/SW1221-ND/2698560

Not sure where they get the nice twisted pair wire that they use as leads.

1 Like

I installed the Simulated Roller Version of this microswitch. Thought it would give me a little protection against accidental destroying the switch. It does cost a very small amount of X, Y and Z movement though.

Here’s the link if interested -
https://www.digikey.com/products/en?keywords=D2QW-C073H

2 Likes