What is the problem?
When connecting the raspberry pi running octoprint to my skr 1.3 via USB, after some time (1-3 minutes) my piezo probe begins to trigger spontaneously without any physical input. The "triggered" LED on the piezo interface board initially begins to flicker intermittently, eventually the probe remains triggered. The machine is then unable to home correctly as the probe is my Z endstop.
What did you already try to solve it?
The only solution I've found so far is to unplug the usb from the raspberry pi. Of course this renders octoprint essentially useless as it can't communicate with my machine.
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, what kind of hardware precisely, ...)
Mainboard, lights fans motors and heater etc are all running from a 24v psu which is controlled by a relay connected to and powered by the gpio on the pi. The heated bed is powered by mains and ssr controlled by the skr 1.3. The pi is powered by an external 5v 2A wall wart. The piezo sensor is a universal piezo v2.85 which is tuned and functioning perfectly when the pi is disconnected and I'm printing from the LCD (tft_24 running in marlin mode). The machine was working perfectly before adding octoprint. So the problem must be related to electrical interference from the pi, relay or 5v supply for the pi, as these are the only new components that have been added to the machine since there problem arose. I'm at a loss as to what's causing the issue though. 
if you power the printer off completely does it still light up the lcd while connected to the pi? It could be an issue with backpowering or possibly need a shared ground between all devices involved.
Hi jneilliii, thanks for your response. I don't think it's a backpowering issue. When the printer is off the LCD is off. I had this issue with my ender 3 a couple of years back. I have tried placing a piece of electrical tape over the 5v pin on the USB cable used to connect the pi to the skr to see if that alleviated the issue but it was to no avail. Perhaps should have mentioned that in the "what I already tried to solve it" section. 
I had considered that the pi being powered by a dedicated supply and not sharing a ground with everything else could be the issue, but I assumed it would have a common ground connection via the USB cable? Currently, the relay controlled by the pi switches the AC power to the whole system. If I move the relay to the DC side to switch everything but the pi I could create a 5v rail from my main psu with a buck converter and have the pi powered by that (so it's always on). Then I could be certain that the pi shared a common ground with everything else. Is there a simpler solution? Could I, for example, simply connect a jumper between a ground gpio pin on the pi and the ground on my main psu or a spare ground pin on the skr 1.3? 
Well, connecting the pi's ground to my 24v psu ground didn't solve the problem. 
Testing continuity between the ground plane on the skr and the pi with the USB cable connected indicated that common ground is indeed provided by the USB connection. Could it be worth connecting the pi via UART as opposed to USB? I don't see how this would be any different than just interfacing the pi with my controller via USB but it's the only other method for octoprint to control the machine so could be worth a punt. 
I would have thought USB would be more resistant to interference though, given that the cable is shielded and has a ferrite doohickey; I don't hold out much hope.
If anyone else has any bright ideas, I'm all ears. I'm at a loss here!
Well, for anyone else suffering a similar problem I found a solution. It might not be the best solution it might not even be a good solution but it's solved my false trigger situation.
To try and narrow down where the noise was entering the probe, I removed the piezo disk from the sensor board but left the pi connected to the SKR via USB. I powered up and patiently waited for the trigger indicator on the sensor board to begin flickering but after 10 minutes there was no sign of any false triggers, so I concluded that the piezo disk itself was the route by which the false triggers were occurring. I found this bewildering because the disk is encased in electrical tape so it couldn't be due to conduction. If this was the case it would have never worked correctly before my octoprint implementation. Based on this I figured that it was happening as a result of induction and that the noise was traveling through the frame as nothing else is even remotely close to the piezo or it's 40mm or so leads back to the sensor board. Checking for continuity between the frame and ground indicted that the frame was not grounded. The frame is earthed, because I have an AC heated bed, and making sure that the AC has a more favorable route to earth than my body is essential for safety in the event of an electrical fault. So I figured the solution would be to provide a similar path for the noise causing the false triggers, so it would return to ground, rather than traveling through the frame and piezo.
I discovered an article on the TH3D wiki regarding false triggering of their easy ABL inductive probe on ender 3 machines due to EMI from the X axis stepper motor traveling through the gantry. The solution there was to connect a lead between the X axis stepper motor's metal casing and another point on the frame outside of the gantry, which is isolated from the rest of the machine by the Delrin wheels. Having read elsewhere that the pi3 is known for having noisy USB ports (something to do with the ethernet circuitry which has since been solved in pi4) I decided that plugging in a second USB cable to a free USB port on the pi and attaching the ground from that to the frame of my machine might solve the issue. Sure enough it did! To test, I connected the lead to the frame and gingerly touched the USB A terminal's housing to the outside of the USB ports on the pi and the trigger light on the piezo sensor board immediately went out. So I plugged the second USB in and since then, no more false triggers.
This could perhaps also be solved by simply connecting a ground pin on the pi's gpio header to the frame, or maybe even connecting the -ve terminal of the PSU to the frame, both of these may even be considered better solutions. I'm certainly no electrical engineer and my solution was based entirely on empirical problem solving as opposed to any expert theoretical knowledge.
If anyone has any pointers on the suitability of my method for solving this problem, or any concerns about the safety or longevity of my equipment doing it this way, I'd love to hear about it. Everything now works as it should and nothing let out the magic smoke so I'm guessing it's problem solved! 
1 Like
Well, I'm glad you got it figured out. Your assumption of connecting ground pin header to frame would also probably work.