Basic Information:
Printer Model: Voron 2.4
MCU / Printerboard: Manta M8P v1.1
klippy.log*
Describe your issue:
I’ve been trying to get the Manta M8P working all day now. I compiled klipper in USB to CAN bus bridge mode so I can connect a SB2209 canbus pcb to the toolhead. Klipper is running an a CM1 module.
Whenever I try to home the axis or do a quad gantry level, klipper throws a MCU 'mcu' shutdown: Timer too close error. Homing sometimes succeeds and sometimes fails instantly. The error never occurs while moving the X and Y axis but only when moving the Z axis. Sometimes the homing is successful but then QGL fails.
I’ve already tried canbus speed of 250000 and 500000 but no difference was noticable.
I’m building a Voron 2.4 so there are 4 Z steppers connected to the mainboard. When I set the Z steppers microsteps to 16, the error occurs. But when I set the microsteps to only 1, homing and quad gantry leveling works fine although the noise is really terrible (serieusly, I’m worried the neighbours may even complain). I’ve never run steppers without microstepping before so I’m not sure if this noise is expected.
This made me suspect that there is something wrong with the communication between the MCU and the CM1. So I checked the M8P schematics to see how it is wired. The USB signal from the PA11/PA12 pins goes through a USB hub (FE1.1S) and USB multiplexer (RS2227XN) so maybe one of these chips causes trouble?
I checked the canbus statistics (ip -s -s link show dev can0) and there are no reported errors. When moving the XY axis the packet rate is about 100 packets/s and when the Z axis is moved the rate is about 400 packets/s. Not a rate that should cause any trouble I guess?
Does anyone have the same issues with a Manta M8P? Any suggestions what I might try next?
Thing I might try in the future (but not today because I’m tired…);
- Compile without canbus bridge support and talk to PA11/PA12 over USB instead of as a simulated CAN device. The voron tap sensor needs to be connected directly to the mainboard because homing now relies on the SB2209 pcb.
- Try to connect a raspberry pi to any of the serial pin pairs maybe?
- If all else fails I will probably get a CAN bus head and drop the whole USB to CAN bus thing…
…
klippy.log (261.3 KB)
Thanks for the link to that page! I’ll try to make some graphs soon.
I already reflashed debian on the CM1 and only installed klipper, moonraker and mainsail so a system overload would be unlikely I think. Faulty sd card is also almost certainly ruled out because I swapped it when reinstalling debian.
I reflashed the SB2209 as USB CAN bridge and the M8P in normal CAN mode to see if this would fix anything. The issues are exactly the same (maybe slight longer before errors occur). The signal still needs to go through the USB hub and multiplexer to get to the SB2209 though…
So here are the load graphs. This is the homing procedure for X,Y,Z and then the quad gantry level procedure. After the second set of 4 corner probes, the mcu got an error (Most of the time the error occurs after only one set of corner probes. This time I got lucky). The error always occurs after a full set of corner probes. Moving the gantry up a few centimetre also triggers the error.
I don’t think there is anything unusual in the graphs?
I just realized that I don’t need CAN bus…
I wired the SB2209 to the M8P directly via USB instead of via CAN. Now both MCUs are connected to the CB1 via USB and everything works fine. So I guess there was something wrong with my CAN bus setup after all.
@YoctoByte
We’ve had great results and reliability with the M8P in bridge mode.
If you do want to give CAN bus a try again there’s a few extremely important details that people often miss:
- Any cable longer than 25mm must be twisted at a minimum rate of 1 twist per 25mm
- The wires connecting the 2 furthest nodes (the “Trunk”) should be terminated at both ends with 120Ohm resistors
- All other branches off the trunk should be kept shorter than 60cm
- The CAN High and Low wires must be the same length in the trunk and for each branch
- Cables must be secured so that the CAN bus connectors on moving parts like the print head can’t wiggle
For the M8P and the SB2209 there’s a jumper labeled “120R” that needs to be installed for the 120Ohm trunk resistor. After that I’d check your cables and cable management.
1 Like
Thanks for the suggestions! I did terminate both ends with the 120R jumpers. The canbus cable provided by BigTreeTech also has two thicker power cables inside. I shortened this cable to ~150cm and stripped the last ~15 cm from this cable to connect the power wires to the power supply and the can wires to the main board. I twisted the can wires in the same direction as they were twisted inside the thick cable. Maybe twisted them too tight, is that possible?
Anyway, it is working now over USB now and CAN bus gave me too much headache so I completely gave up on it… I think I will rewire the two can wires as USB wires to get rid of the extra USB cable.
Can you send pictures (ie from your smartphone) of your wiring? Also, are you using a “CM1” or a CM4 as your system controller?
If you’re having problems with creating your own CAN bus cables, you’re going to have bigger problems trying to do your own USB cables.
1 Like
Here are the pictures of the wiring. I soldered the D- and D+ of an old USB cable directly to the canbus L and H pins and connected the other end of the wires to the USB header of the M8P. This works so much better than CAN bus!
I don’t really understand why can bus is even a thing in the 3d printing world when we already have USB. USB is more reliable, much easier to set up (no need for can adapter or can bridge mode) and not capped at 1 Mbit/s. Also no need for canboot when using USB.
To answer your other quesion; I have a CM1.
Glad USB is working for you.
I think you’re looking at CAN vs USB from your limited perspective. CAN is superior to USB in applications like this because it is:
- Cheaper to implement (simpler MCUs can be used, less costly connection hardware and cabling)
- Simpler (and vastly smaller) software implementation than USB
- Very EMI resistant
- Built in error detection and automatic retransmission
You’ll probably hate me for saying this, but I’ve had absolutely no problems getting CAN on four 3D printers working in a variety of different platforms and, as far as I know, I’ve never had a dropped packet (I’ve checked periodically). Certainly I’ve never had a print fail due to a system error.
As for set up, USB is simpler (fewer steps) and documentation for CAN set up isn’t great or completely consistent but, when you understand the process, you can work through it quite easily without any unexpected issues.
I’m happy you have things working and I’m looking forward to seeing what you produce.
1 Like
Just took a look at the pics, it’s hard to tell on the Manta side but you’re definitely missing the 120R jumper on the print head side.
@mykepredko is right on all points for CAN vs. USB, once you get it working it’s spectacularly reliable
