Communication lost with MCU after turning on the heater

General Discussion
1

Basic Information:

Printer Model: Sovol SV04
MCU / Printerboard: 2x Creality 5.2.1

Soooo, I have a very odd problem.
I klipperised my SV04 some weeks ago using a BTT CB1 with adapter, and it was running fine.
I have a spare board I decided to connect for experimental reasons (possibly running a water pump for Biqu H2O off second boards heater bed pins etc).
So I’ve opened the printer and ran another set of wires from the PS to the outside where the board sits (just on the desk). Added a ferrite on them too.
Whenever I try to heat the bed, the communication with MCU(s) is lost.
Here’s where it gets really weird for me:

  • I didn’t disconnected anything inside to the best of my knowledge
  • I did came back and retightened the PS and power/bed terminals on the main board
  • I’ve insulated the power pins in the USB cables to avoid any interference
  • The loss of communication only occurs when the bed is connected, without load I can set the temps without loosing the comms
  • I’ve checked the bed’s resistance and I guess is within the norms (2.1 ohm for a big 300x300 24V bed)
  • I’ve temporarily connected the bed heater to the second board, output configured as a manual fan, I can run a couple % before the comms are lost. Max say couple hundred mA. If I up the “fan speed” further than 10-15% its instantaneous. After the loss of comm the heater stays on.
  • I’ve sent 50% “fan speed” (irl about 25%PWM since I’ve configured “max speed” to 0.5, in any case to have time to react to a free-running heater) and I’ve seen like 1.6A current to the bed that slowly started to actually get warm, it stays on after the comm loss.
  • I’ve tried scoping things hoping to see some blatant interference, weird spikes etc. Nothing, everything looks smooth and clean. Taking ground from the host GND both the PS GND, PS +24, both bed terminals - everything pretty smooth, maybe with minimal fluctuations in PWMs rythm.

I’m at a complete loss, hoping for your input!

2

Hello @vinZ31ent !

When you opened this thread, the template asked for the klippy.log in the third line (you deleted that and the rest)

Please attach the klippy.log to your next post. If it is too log, you can zip (compress) it.

What PSU do you exactly have?

A 275W heater with 2.1 Ohms draws about 11.5 A from a 24V PSU at 100%.

BTW: During recent times we has some issues that have been a result of a bad PSU.

1 Like
3

Sorry, I was posting falling asleep after second late evening of trying to get somwhere with this.

klippy.log (121.0 KB)

The printer config is a bit of a mess, don’t worry about me using the second MCU temp for bed temperature lol, that was just to avoid thermistor errors with disconnected bed. Second extruder is not even connected yet I’m in the process of going to biqu H2O - but I was already printing with the first in this state.

The PS is the stock sovol unit, 500W unbranded. But it was just working fine before.
And it doesn’t make sense to me. If i turn on the extruder heater it takes the load fine. Running the bed at maybe 10% PWM already causes a crash. In the above example I was increasing the “fan” output, it crashed at 0.38A measured. Regarding

idk how reliable is my measurement, I have a decent multimeter but idk how well it averages the PWM here. Still, if I just go straigth to 1.6A even after the crash I don’t see nothing concerning on the scope (unless im looking wrong…) so how it would be possible the PS takes the 30W of the hot end easily, and has issues under 10W of the bed (24V*0.38A?). Unless the PWM pulses of full amperage are long enough to make a mess. I don’t have a spare PS and I’m hesistant to buy one, but maybe I’ll try running this board off my 24V LiFePo battery. It easily gives 80A so… hahaha

4

I do not understand your config nor your issue.
Apparent, it is your E MCU that is having an issue, e.g.
Timeout with MCU 'E' (eventtime=244.612437)

Your bed is defined as:

[heater_bed]
heater_pin = PA2
sensor_type = temperature_mcu
sensor_mcu = E
...
  • It is not controlled by a pin on E
  • For whatever reason your heatbed measures its temperature via the E MCU but as internal MCU temperature (which hardly makes any sense)

I stopped looking at the config at this point. Maybe it makes sense to start over and rebuild your config step by step, starting from a bare minimum

2 Likes
5

If you read my posts more carefully you’d know what’s happening there, but I’ll reiterate:
Temp sensor is to avoid an error from disconnected bed from board one
The bed is currently connected to the second board over the manual fan output “water pump” to have manual control over it.
The behavior is the same regardless of where the bed is connected. It crashed when it was connected to properly configured MCU and it crashes the same connected to MCU E

6

Ok, I’ve went back to a single board config, connected the bed back to the printer MCU, commented any references to the second board, physically disconnected its USB, and everything works.
Connected the second board (that, mind this, was functional, I test ran a water pump off it’s bed heater connection previously but didn’t tried the printer at all and didn’t had any issue, I could control the PWM and the pump ran), only uncommented the second MCU config, still without any other references or functionalities, and again I got things to crash the moment I turn on the bed heater.
I’m going to find another USB cable, maybe try to install the second board inside the enclosure? Anyway, probably looking for some weird interferences?

EDIT:
Tried another, short USB wire, config for the second board on, then config again commented out so there’s no reference to it in klipper at all - everything crashes when I turn on the bed heater.
Physically disconnect the USB - works again.
Connected a ground straight from the host to the second board without connecting the USB - the bed starts heating but it still a crash after a moment.
That gets me thinking… ground loops?
EDIT2:
Turning on the bed heater with just_the_loose_second_USB_wire_connected_only_to_the_host_loose_other_end makes it crash…
I’ll see if adding some nf-pf range caps to the bed will make the EMI calm down lol

7

Do you have the possibility to check the input voltage at the printer board that comes from the PSU?

Especially when you start heating the bed.

8

The voltage is rock solid for what I can tell. On the digital Sanwa (no fluke but pretty decent until) multimeter if there’s some momentary drop it’s not visible and the operating voltage doesn’t change in any meaningful way. Can’t remember the numbers exactly but it didn’t called my attention, around 23.87V I believe bed off bed on. I’ve tried scoping it too, I only have a very old analog HP scope which is not ideal for this job but didn’t saw anything neither. There’s some voltage fluctuation under full load, but it was within one div in the highest sensitivity settings, IIRC 0.01V/div and I have 10x probe so within tenth of a volt? The boards have voltage stabilisers, chips are 3.3V probably, from 24V it would really have to drop like crazy to go under the LDO drop threshold to underpower the chips.
If you consider that everything works great with one board and just connecting the second USB wire to the host is enough to make it crash when bed goes on that points straight to EMI interference to me?

1 Like
9

I fixed this using 1.20$ USB-A to USB-micro 1A 5v 480Mpbs wire from IKEA. This one just works. LOL
I tested like 5 wires I had at hand, I’ll admit - of questionable quality, but… Didn’t expected it would be that easy.

3 Likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.