Printer Model: Ender 3 to Voron Switchwire conversion
MCU / Printerboard: SKR Mini E3 V3 klippy.zip (1.2 MB)
Describe your issue:
I recently finished my Ender 3 to Voron Switchwire conversion. I have been running through a bunch of configuration, and test prints to make sure everything is functioning properly. Up to that point, everything had been functioning very well, but it was getting late. I felt comfortable with starting a print to run overnight. I decided I should start a large/tall print to make sure the printer was printing well through out the entirety of the print volume. I woke up the next morning and found the print had finished, but the raspberry pi had randomly lost it’s connection to the MCU.
Leading up to this connection issue, I had dealt with Debian 11 (Bullseye) udev bug, and thought this might be what was causing my issue. So I opened Putty and checked to make sure. After running the shell script that fixes this issue, it reported back that the buggy version is not found, meaning that isn’t my issue. I swapped out the USB cable between the pi and MCU with a known good cable, and that didn’t fix the issue. At this point I’m kind of at a loss, I haven’t had this problem before and have a lack of knowledge when it comes to diagnosing and determining the problem. The MCU is powered on, but beyond that, I am not sure how to determine if the MCU is the problem or if it is something else. I could definitely use some help.
UPDATE!: I decided to try the “manual” option for fixing the bug that causes the “ls /dev/serial/by-id/*” command to not work/no communication between MCU and pi. The manual option fixed my problem, meaning there was nothing wrong with the MCU or the raspberry pi. I don’t understand why the manual option fixed the problem, yet the “automatic” shell script reported back that the buggy version was not being found. Also, why would I randomly lose my connection in the middle of the night shortly after a print finished. I would still like to keep this thread open to try and figure out if there is something wrong. Maybe I didn’t follow instructions properly and the manual and automatic fix didn’t take or isn’t holding for some reason. I have no idea at this point
…
I’m pretty sure stm32g0b1 refers to the type of chip on the MCU. It’s not related to the hotend. This link might help explain a little better STM32G0B1
See Timeout with MCU / Lost communication with MCU
This is typically not directly a “user error” as you speculated above, but some kind of hardware instability. Unfortunately, determining the root cause can be tricky.
Oh ok, I guess that is possible. I’m not going to claim I’m an expert at setting up my klipper configs, I’m still learning haha. I love learning new stuff though. If you have some tips on how to correct or improve my klipper config, I’d love to have a more in depth conversation with you.
No, I don’t believe so. Everything is wired up in a more traditional sense. I am interested in CAN bus because I hear it greatly reduces the amount of wiring, but I have not looked into what is required to set up CAN bus.
Do you have a jumper placed in the “SW_USB” pins? Looking at the schematic you can provide 5V power from the Raspberry Pi (or whatever device you are connecting through USB). This diode should NOT be in place during normal operation. This is probably not your problem but something to check.
In the original post, you reference the “manual” option for fixing the bug that causes the “ls /dev/serial/by-id/*” command to not work/no communication between MCU and pi - what is that?
Hey @mykepredko thanks for any and all input. I appreciate you all jumping in to help out.
Yes, there was in fact a jumper on these 2 pins (reference below picture). I have removed it. I saw the jumper a while back when I was first installing the MCU, but didn’t think twice about it my mistake. A question for you now, I am curious to know the purpose of that jumper and what it’s doing when in place on those 2 pins?
Let’s make sure we’re talking about the same jumper pins - I spent some time last night looking at the schematic . Slightly modifying your image to make things clearer and make sure we’re talking about the same thing:
The upper jumper allows the host (connected via USB) to power the board. This is for loading firmware/setting up your connection BEFORE installing the SKR Mini into your printer. The issue with leaving this jumper in place is that you have two, slightly different voltage, power supplies providing logic power and that can lead to various problems with the output of the power supplies trying to compensate for the different voltage of the other.
This jumper must be removed from the board for anything other than the situation described above - the board firmware/host connection is being set up with the SKR Mini being outside of the printer. Otherwise, it needs to be removed.
The lower jumper is used to select between the SKR Mini built in 5V power supply and an external one for the NeoPixel connector as well as the user interface (called “TFT” in the documentation and attached to EXP1 and is NOT the KlipperScreen) and the BL Touch. I have no idea why this is used to change the power supply driving the BL Touch - I’m also not sure why it is also used with the user interface as they generally don’t draw much current.
In any case, leave this jumper where it is as this will provide the built in 5V to the three functions and, unless you have a long string of NeoPixel LEDs, there’s no reason to change its position.
Thanx for the link - I did some playing around with this last week and it seems that when you do sudo apt update and sudo apt upgrade -y on your host (ie Raspberry Pi), the offending code is replaced.
Did I say the schematics are horrible? They’re very poorly laid out and quite difficult to read and follow. Along with that, some of the decisions made in the circuitry (like linking BL Touch 5V power to NeoPixel 5V power) are difficult to understand.
Anyway, rant off, and let us know how things are going.
Yes you’re right, I didn’t explain well. What I meant to say is, yes, there is a jumper installed, but not on the 2 pins you suggested. Instead, the jumper is on the 2 lower right pins for “Neo-PWR1” . This I presume is the default installed location for the jumper during assembly. I never changed it until this morning when I removed it altogether.
Thank you very much for taking the time to explain to me the purpose of using the jumper in these two areas. I haven’t started messing around with adding a screen to my printer, hence my lack of knowledge regarding the purpose of the jumper on the “Neo-PWR1” pins. I would like to start looking into adding a screen at some point though. That just gives me some new stuff to learn about.
As for right now, the only issue I seem to be dealing with is the same issue I started this thread off with. I can print with my printer all day and then for some when I’m not using it for any period of time, something happens where I end up losing the connection between the pi and the MCU. Just like I stated in my original post, it happened again last night while I was sleeping
Hey @hcet14 , just so I understand correctly. Are you asking for the block diagram that you asked for last night, or are you asking for an actual picture of the board installed in my printer? If it’s the second option, I guess I could take a picture, it’s just a bit of a pain because of the board layout design. There isn’t a lot of space so as a result the raspberry pi is stacked on top of the MCU. Here is a picture of the 3D assembly board layout
Sorry, my reply was very short. Why don’t you share a picture of your jumper settings? See quote below.
In my eyes the easiest way. (KISS principle - Wikipedia)
@hcet14 I appreciate the suggestion, and you’re correct. I could have just taken a picture of the board, and I will keep that in mind for the future, but at this point I think we’re getting a little sidetracked. I have already confirmed that the jumper was not installed on the 5V/GND pins. I double confirmed it is not the problem because currently there is no jumper installed (I will put the jumper back where it was originally, on the “Neo_PWR1” PA8/PWR pins).
What I really want to figure out is, why am I losing communication with the MCU every time I shutdown my printer, or there is some sort of power loss?
A month or so ago I had shut my Ender 6 down while I was going to be away from home for an extended period of time. When I returned home and turned my Ender 6 back on I had the same issue where I lost communication with the MCU because of the Debian 11 (Bullseye) udev bug. It took me a while to figure out what was going on, but eventually I found the post from Sineos explaining what the problem is and how to fix it. After running through all of the steps, I finally fixed the issue and was able to use my Ender 6 again.
More importantly, I was able to safely shut down the Ender 6 and turn it back on again without having to run through the steps to fix the bug every time I turned the Ender 6 back on. I don’t understand why when I turn off my Switchwire, I have to run through the bug fix steps every time I turn the printer back on.
my mistake. A question for you now, I am curious to know the purpose of that jumper and what it’s doing when in place on those 2 pins?
