No MCU Found (Another one) - Linux MBP

General Discussion
1

Basic Information:

Printer Model: Ender 3 Neo
MCU / Printerboard: CReality 4.2.2
klippy.log
klippy.log (380.6 KB)

Running Linux Mint on a Macbook Pro 2013. Installed Klipper using KIAUH and everything went smooth.
Flashed the firmware on my Ender 3 NEO using Creality Ender 3 v2 2020, adding [include mainsail.cfg] and making sure that all configurations for the build were accordingly.

When it comes to the point of getting the MCU, I get the infamous message

ls: cannot access ‘/dev/serial/by-path/*’: No such file or directory

Tried /by-id/ and /by-path/. Both results in the same error.

Using the advanced options in KIAUH, I get “No MCU found” when using USB and USB (DFU Mode). But when selecting UART I get MCU #1: ttyS0

Went to printer.cfg and edited:

[mcu]
serial: /dev/ttyS0
restart_method: command

And still no result.

Here is the result of the dmesg after disconecting and connect the 3d printer.
dmesg.txt (86.7 KB)

I know there is something going on between the 3DPrinter and the Macbook Pro because when I plug it, the display on the Ender turns on.

Followed many instructions that I found online, and no result, still can’t get it to work.
Can not get the MCU and on Mainsail still get the message that Printer is not ready.

2

Your dmesg output does not contain any traces of a printer board.
Make sure that the printer is properly powered and repeat the dmesg process according to How-To Trouble-Shoot

Alternatively you can use the command dmesg -w, which will put dmesg into a monitoring mode, so that you see any changes live during disconnect / reconnecting the board

3

Thanks. All is good now – at least MBP and Ende3 are communicating.
It was only a matter of trying a 7th cable. No jokes. I used 6 cables and was losing hope till I found a long-lost and forgotten usb/v8 cable lying around. I was so angry on everything, that I could not read the dmesg properly. Thanks again!

Now I have to learn how to use klipper!

4

@Sineos just stumbled upon another thing that I am not figuring out myself.

I’ve been following the instructions on this:

And editing my printer.cfg accordingly. But When I try to move on the Z axis, I get “BLTouch failed to verify sensor state”

The BL Touch is the one that came with my Ender 3 Neo and works flawlessly with the stock firmware.

This is my
printer.cfg.txt (3.7 KB)

5

If you have any questions, please only post a recent klippy.log. Posting / pasting configs etc. is typically not needed unless specifically requested by a supporter.

For the BL Touch (clone) you often need to pull the sensor pin high by prepending a ^. You also should check the information on clones here: BL-Touch - Klipper documentation

6

Just a quick comment - I’ve stopped recommending that people use the pullup character (^) because very few controller boards now have a direct connection to the MCU’s IO pin.

Usually they’re buffered (which means they only work in one direction) with a pull up wired to the buffer’s output. So, the ^ is redundant and there is always an active pull up on the output pin.

The only boards that I know of that still have direct connections between the MCU IO pins and the board’s connectors are RAMPs. I believe|very sure that the Creality 4.2.2 boards have their output pins buffered with pull ups.

7
  • According to Creality Board 4.2.2 and 4.2.7 Schematics this does not seem to be the case (maybe the author of the schematic simply omitted the buffer, I do not know).
  • Redundancy does not hurt and at least I personally do not feel like checking every schematic and every possible pin combination.
1 Like
8

“Redundancy” was probably the wrong word. The problem comes in when you suggest something and nothing changes for the user.

Thank you for the pointers to the schematics (I didn’t know they were available). It’s interesting to see that Creality has pull ups are on ALL the digital inputs with the exception of the BL Touch:

image
image1943×585 24.9 KB

Just did a bit of research and the BL Touch’s sensor output is a bit more complex than I thought it was. it’s programmable as a 5V push-pull or an open drain output. I’m not sure what kind of sensor output(s) the CR Touch has - I couldn’t find anything definitive.

I hear what you’re saying about not wanting to have to check every schematic, but for the BL/CR Touch, you might end up having to do it. I’ve just gone through a number of controller schematics and I see a pretty wide variety of touch input (as well as output) pin configurations.

After looking at the different schematics and the variety of different ways the BL/CR Touch can be connected, I feel a lot better that I moved to steel/PEI printing surfaces with inductive probes.

9

I think we are all well aware that such issues have a lot of different potential solutions, ranging from simple misconfiguration, to wrong hardware/jumper settings, over to wiring problems and finally faulty components.

So, I would not call this a problem: Typically, you get a rather unspecific problem description like “XY does not work” and then you iterate through the possible solutions, starting with the most obvious ones.

1 Like
10

@Sineos and @mykepredko

Thanks for your time and patience. Just so you guys know, adding the ^ to sensor_pin under bl_touch did the trick.
Somehting that would take me a loooong time to figure out by myself, if I ever managed to.

Just as a reference for possible future cases, it is now like this:

[bltouch]
sensor_pin: ^PROBE_IN
control_pin: PROBE_OUT
x_offset: -40
y_offset: -12
#z_offset: 0
probe_with_touch_mode: true
stow_on_each_sample: false
3 Likes