I've built a project that uses Processing on my RPi4 to read a rotary encoder and then turn a stepper motor until the motor's own encoder value matches the original input. In individual code snippets, I have been able to read both encoders and control the motor. I wired it all up on the breadboard and was able to use the input encoder to turn the motor just fine. Finally, I added a longer cable between the motor/encoder and the RPi/input encoder using an ethernet cable and ethernet plugs. At this point, I was able to again control the motor as expected using the input encoder to determine a value and the motor's encoder to stop the motor when it had reached its setpoint. However, this test was only 10second and when the rotation command ended, my Pi rebooted. I thought I had jiggled the Pi's USB-C cable and maybe unplugged it, so ran my motor test again. Again, at the end of the run, the Pi crashed. After that, it was unable to boot to its normal USB drive; the green status light just held steady when power was applied to the RPi. I had to burn the recovery EEPROM bootloader to an SD card, reflash the EEPROM, and then burn a fresh Bullseye image to the SD card before the RPi would boot again. When I attempt to boot from a USB drive, even a fresh install on a different USB drive than the original, the RPi screen just freezes at "1.717875] brcm-pcie fd500000.pcie: link down". I have not tested the GPIO pins yet. I can interface with the RPi using gadget mode and VNC, but I have not been able to get it reconnected to the internet. WIFI is not working as "No wireless extensions are available" and it is not sharing my computer's connection as I normally would.
So, what happened?
I am using an RPi4 running Bullseye powered by USB-C running in Gadget Mode. I've been using this setup for months now.
The motor driver is a Big Easy Driver set to 3.3v logic. I have operated the stepper motors with this controller many times.
The Big Easy Driver is being connected to the RPi's 3.3v and ground.
Motor power is coming from a power supply set to 24v, limited to 2A. The Big Easy Driver's onboard current limiting potentiometer runs the motor at 1.2amps.
A 25v 100microFarad capacitor is across the power supply input. THIS TEST WAS THE FIRST TIME THIS CAPACITOR WAS IN THE CIRCUIT, if that's relevant at all.
My guess: In my code, when the motor is not being stepped it is disabled by the Big Easy Driver so that it does NOT hold position. When it steps, the motor is enabled (Big Easy Driver Enable pin set to LOW), then the step commands are sent. When the step command is completed, the Big Easy Driver's Enable pin is set HIGH again and the current to the motor is turned off. I think this collapse of the magnetic field induced a current in the ethernet cable wires from the encoder going back to the RPi, creating a voltage spike that damaged the RPi.
Does anybody have any other ideas? I'd rather not kill any another Pi.
Here is a diagram of my circuit.
(Note that the pink wires between ethernet cables are not accurate and just represtation. I don't know why Fritzing has an 8x6 pin RJ45 socket)
(This minimal setup is part of a larger project that will use the animation capabilities of Processing along with the physical components. The motor has an encoder attached because at times it will be manipulated while the motor is turned off but its rotation still needs to be known.)
So, what happened?
I am using an RPi4 running Bullseye powered by USB-C running in Gadget Mode. I've been using this setup for months now.
The motor driver is a Big Easy Driver set to 3.3v logic. I have operated the stepper motors with this controller many times.
The Big Easy Driver is being connected to the RPi's 3.3v and ground.
Motor power is coming from a power supply set to 24v, limited to 2A. The Big Easy Driver's onboard current limiting potentiometer runs the motor at 1.2amps.
A 25v 100microFarad capacitor is across the power supply input. THIS TEST WAS THE FIRST TIME THIS CAPACITOR WAS IN THE CIRCUIT, if that's relevant at all.
My guess: In my code, when the motor is not being stepped it is disabled by the Big Easy Driver so that it does NOT hold position. When it steps, the motor is enabled (Big Easy Driver Enable pin set to LOW), then the step commands are sent. When the step command is completed, the Big Easy Driver's Enable pin is set HIGH again and the current to the motor is turned off. I think this collapse of the magnetic field induced a current in the ethernet cable wires from the encoder going back to the RPi, creating a voltage spike that damaged the RPi.
Does anybody have any other ideas? I'd rather not kill any another Pi.
Here is a diagram of my circuit.
(Note that the pink wires between ethernet cables are not accurate and just represtation. I don't know why Fritzing has an 8x6 pin RJ45 socket)
(This minimal setup is part of a larger project that will use the animation capabilities of Processing along with the physical components. The motor has an encoder attached because at times it will be manipulated while the motor is turned off but its rotation still needs to be known.)
Statistics: Posted by loudboy — Tue Sep 10, 2024 5:52 am