Sending my machine home always results in a hard limit alarm

[IVHead]

Version

2.1.5

Hardware / Firmware

Other (add details about it below)

What happened

I am using a "gShield v5b" running the latest version of the library uploaded onto our arduino uno. I suppose an issue is that I never made this system and the issue might not be in the software it's self but the construction of the machine it's self. Like stated the machine needs a restart ever time I make it go home, causing a cycle as it wont move unless I do so. I haven't had it move on it own in days, just keeps saying "An unexpected error was detected: ALARM: Hard limit". I got so despite I unplugged the switches from the pins and the alarm was still sent. I feel like it's something obvious but I just lack the exposure to this type of stuff to see it. https://github.com/winder/Universal-G-Code-Sender/assets/161625687/1db5790a-de48-449c-92d7-726f63ffc586

How to reproduce

No response

Operating System

Windows 11

Anything else

No response

[breiler]

Sounds like a problem with EMI.

I can see that you have some capacitors and resistors to try and mitigate this. However it also looks like you are running the limit pin wiring parallell with the stepper motor wires without any shielding which I would guess could cause this

I got so despite I unplugged the switches from the pins and the alarm was still sent.

Did you unplug the wires here?

Will the machine move properly if you turn off homing and hard limits ($21 and $22)?

[IVHead]

I did unplug those wires yes. The errors were still there.

I would like to emphasize that I am not in a robotics program and do not have extensive experience with this system, so all the choices for wiring were not my own. Rather it's my job to get this working so that we may mount a laser to the arm and make a DIY laser engraver.

However setting those options you mentioned to false made it so the table actually functioned, it was able to move. Dose this mean the electronics will need to be wired differently? I can try to provide more information on the system if it is needed. I also have an extra arduino from my own kit if it's needed for repairs.

[breiler]

That suggests that enough EMI is induced on the circuit board to to make it falsely trigger the limit pin on the board.

I have had the same problems when I got started with my machines and I eventually got it to work ok after I placed the controller inside a shielded metal box and iron ferrite beads on incoming cables.

It would still occasionally trigger a false limit switch so I finally replaced it with Bart Drings board and it is now working properly: https://www.tindie.com/stores/33366583/items/

[IVHead]

You replaced the gShield?

[breiler]

No I used a plain Arduino connected to external stepper motor drivers and connected the limit switches directly into the input pins.

The gShield does doesn't seem to have any opto couplers or filtering built in to the controller board so I guess it is prone to suffer to the same problem.

[IVHead]

I see, what exactly am I replacing than? I think I'm missing something.

[breiler]

I used to use a plain Arduino Uno without any shield. But just like with your gShield, it was missing filtering or isolation on the inputs which work poorly in an electromagnetically noisy environment.

I replaced my Arduino Uno with a controller that has proper isolation or filtering on the inputs.

[IVHead]

I can't get approval to replace the parts or purchase any filters or EMI protections until I can prove that it is what's affecting the switches. Do you have any suggestions for determining if this is what's affecting the system?

[breiler]

It is a bit out of scope for UGS.

This is a good read: https://www.cnccookbook.com/cnc-electrical-noise-grounding-techniques-interference-filter/

[breiler]

Closing as this is related to a hardware problem and not UGS.