Fanuc 0M Control - Overtravel When Homing

RESOLVED!!!
See last post for details if interested. Thanks for the feedback all!

-----
I am hoping someone has encountered a similar problem in the past and lead me down the right path to resolve this error. I have a old Kitamura MyCenter 1 with a Fanuc 0M-B control. Everything has been working fine for the couple months I've had it. I have non-absolute encoders which require you to home each axis when the machine is started.

My shop is very hot right now, around 95F while the AC is out. The previous owner mentioned the machine would not stay running in his shop (very hot also) without a fan on the open cabinet. I never had a problem though until last night. I was running parts and got a 920 Watchdog Alarm Error mid run of a program I have been running a lot. I was scared because it says to replace the PCB, but searching mentioned some just had to put a fan on the open cabinet like the previous owner mentioned (I don't know if this is the error the previous owner would get though).

I powered down, put a fan on the cabinet, powered up and all way fine it appeared. I went to restart my program but when I went to rehome my axis's Z homed fine, but X and Y did not.

X and Y both appeared to be homing right, where it decelerated as it was getting to the end, but instead of stopping at machine zero it continued to -2.002mm and through an overtravel alarm.

I retried homing a couple dozen times with the same result, even after cycling power and letting it sit for a couple hours between tries.

I don't know what to look for or what to do from here to troubleshoot it because it cannot locate home. I'm worried that perhaps something fried relating to the limit or encoder hardware/logic now and that is where that 920 error originated from and not the heat of the cabinet. I would have thought it was a bad switch if it didn't happen right after the 920 error and if it weren't both X and Y at the exact same time. I'm thinking perhaps the key to this is that it is X and Y and not Z and that will be an indicator of what is amiss to someone who knows the way the hardware works.

Can anyone advise on what procedures to do to investigate this more? I have manuals but it makes no reference of anything related to homing, switches, overtravel or anything I am describing.

------

Above is the original symptom/issue that caused me to start troubleshooting myself. The issue mentioned in this section cannot be resolved until the above root problem is fixed. But to test the limit switch I put the rapids to 1% and tried to home Y. While it was moving I depressed the top switch, released it... kept moving. I did it a second time and it stopped and Home light for Y lit up. This gave me hope but it caused the machine to think the end of travel (home) was way short of where it should be.

So I tried booting with CANCEL P held down to override the softlimits, which worked. But when I would tried homing Y in that mode it would just continue on until it hit the lower cam/switch (the E-stop switch). On mine I have two cam/switches on each axis. The upper cam/switch is the homing and the lower cam/switch is the emergency overtravel. When the upper switch first hits the cam it causes a deceleration, and then when it clears the cam it knows it is home. At least that is how I think it works, maybe it doesn't.

At any rate, I've made things a bit worse since I can't get reset machine 0 on the Y back to where it should be, but at least I was able to see that the machine can still home (green light and machine 0 reset) just not where it should happen.

Usually if it slows down, this is an indication that it saw the home limit, the next thing it looks for is the z pulse or marker of the encoder, either it is missing or the O.T. limit is less than one revolution away from the home limit.
Al.

Pretty sure it looks for the switch, travels the length of the dog, switch drops off then looks for a marker pulse. Is the switch gummy?

Thanks guys. I am going to clean the switches just to be sure. But it is very strange I went from no problem to both axis having the exact same problem the moment that serious alarm (which has not persisted) appeared and locked up the machine (920 watch dog timer alarm). Plus one switch is only a few months old and has been used almost exclusively dry cutting. It sounds unlikely both failed at the exact same time, which makes me think it is related to the homing logic/hardware. I checked all parameters to ensure something wasn't corrupted and all are exactly the same. Here are pics of my board LEDs just in case anything looks suspect to someone with my experience than myself.
Attachment 247614

Attachment 247616

Can someone definitively explain to me how the switches work with Fanuc controls? The best I can tell there are two possible ways. I am nearly 100% sure the lower switch is the hard travel, because it interacts with the dog that is at the end of the travel and depressing it causes an e-stop.

It is the upper homing switch I'm not 100% on and knowing that would help troubleshoot this with more certainty on what to try.

Example 1:
The way I thought that switched worked, especially because the cam is ramped on both sides, is:
When the switch it first depressed it triggers a decel signal to the table to slow down and move slowly.
When the switch is released (when it clears the other side of the cam), it triggers the home signal.

Is this correct? Because when I look at the switches when the lower one has made it all the way to the e-stop cam, the upper switch hasn't cleared the upper cam or even really any of the ramp so I don't think it is allowing the "home" signal to fire.

Example 2:
Or, is it when the upper switch first contacts the upper cam that it triggers both decel and home, and the machine just is programmed to slow down and continue moving that axis N-revolutions or N-inches until it finds its own zero (based off the encoder, or?) ? In this example the "releasing" of the switch would have nothing to do with anything, but in my own testing on how the switch works it appears it is only once it is released does it trigger home, and the depressing of it just triggers the decel.

Like I mentioned above... after this first happened I tried playing with the Y switch and did a homing procedure but with my finger depressed the upper switch, released it... nothing, did the same thing again and it stopped, home light lit up, and changed the current position to Machine Zero. In subsequent tests it seems I have to press and release twice before the table stops and it calls that home. That would make sense why it won't home, but why would the machine be looking for On-Off-On-Off for home instead of just On (decel) -Off (home).

Once again I will try cleaning but everything seems to be working right, nothing gummy from the looks of it, and everything being very predictable when I do it by hand.

Definitely not the switches, at least not the mechanics of them. I pulled them off, disconnected them from the machine and tested them with my ohm meter. They are very sensitive and not all at sticky, very smooth and crisp. The take a very small movement to activate them (open the circuit) and they pop back into place without fail (closing the circuit, switches operate as normally closed).

I didn't think with both X and Y exibiting the exact same issue immediately proceeding a machine failure it would be mechanical, but I was hoping it would be that simple.

So the only things I can think now it could be is...
The dogs aren't set right, which I put it at a 1% chance after seeing how sensitive the switch is. It should have plenty of room to deactivate on the downside of that dog before the e-stop dog is met by the e-stop switch. Plus, why would it be working fine for all this time and all the sudden both dogs go out of adjustment at once. I've looked at it close, it just doesn't make sense.

So that really leaves the electronics/logic. Once again, in my testing of manually tripping the switch it appears instead of homing based "Depress-Release", which I believe is normal operation, it will only do it on "Depress-Release-Depress-Release" when I do it by hand. I don't know if that is because that is what it wants now, or if it is because the first time I depress-release the encoder says it is not close enough so it ignores it, I don't know.

But I feel like it has something to do with the limit logic or the encoders. Are the X and Y encoders or limits ran off the same piece of hardware independent from Z? If so, it would make sense why X and Y went out at the same time but Z is fine. That is probably the hardware I need to look at closer.

Any ideas? I've reached out to Fanuc also but no response. If they share anything I will post it but it seems with the older stuff it is getting harder and harder to get support.

Resolved... Fanuc told me to move the limit switches closer (less travel) and the darn thing homed. I don't know why, but I guess they do, lol. To be clear, the e-stop dog and the decel dog are fixed, you cannot adjust those independently, just the whole dog assembly forward or back, which is why I was skeptical and didn't even bother trying that yet until they insisted. The 5 minutes to adjust them solved the problem, couldn't believe it after all the time I spent messing with this.

It sounds like 920 error lost the positioning and/or something settled, and moving them up a tad allowed the encoder to pickup home. Again, I can't make heads or tails on why it worked but all that matters is it worked. =)

If anyone finds themselves in a similar situation the next step (or possibly the alternative to moving your switches) is to backoff the gridshift a bit.

I'm not sure if my work offsets will not be off or not, will have to see if they still locate in the morning. I don't care if they don't though, I'm willing to spend an hour reprogramming my offsets after I spent several hours digging around in the hot grimy machine getting stabbed with chips.

Kudos to Fanuc for still supporting products that have long since stopped adding to their bottom line. Good business model because it does want to make me buy more Fanuc stuff in the future when I need the next machine.

What happened to you is your axis jumped grid. This happens when your zero pulse on the encoder is too close to the reference dog. By moving the dog you removed the chances of not seeing the zero pulse at the same time of hitting the reference dog. I seen machine run for years then out of the blue this happens. The newer controllers do a much better job and so you do not see that phenomena any more.