I have Mini 3 and after replacing the BLTouch the head doesn’t move close enough to printer bed for the BLTouch to make contact.
Is there now something wrong with my geometry settings and it believes it bed should be closer than it is?
Is there anyway to have the printing head come closer to the bed? I’ve modified the Z-axis settings but it won’t let me get below -4xxx. It’s as if the fundamental geometry changed when we swapped in the new BLTouch.
Remove and check that the toolhead is seated properly. I don’t see a way to mount the BLTouch wrong, but if the toolhead didn’t seat right, that could cause an issue.
There’s a macro that you can run that will reset the calibrated Z height.
Look in the Mainsail Dashboard, in the Macros or Action Buttons panel, for a macro that says “RESET Z ENDSTOP” and click it. Or on the KlipperScreen touch screen tap the macros icon on the action bar on the side of the screen, scroll down until you find “RESET Z ENDSTOP” and tap the play button to the right.
This should make it set the z height back to the factory value of 186 mm.
You’ll then have to recalibrate the Z endstop position. Easiest way to do that is to go back to the main menu on the touchscreen, go to More, then to Z-Calibrate, select Endstop in the drop down menu, and follow the instructions. You’ll have to do the classic “slide the paper under the nozzle” calibration procedure.
Actually, it might be better to calibrate the probe first, then go back into the z-calibrate and do the endstop calibration.
thank you all for the replies. Unfortunately, I let my son take a look at it and he decided to it needed package updates. Now it doesn’t even communicate with the tool head.
The Mini 3 uses SocketCAN, but when I query using the following
~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0
I see:
Total 0 uuids found
The connection is up:
ip -details -statistics link show can0
shows:
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 128
link/can promiscuity 0 minmtu 0 maxmtu 0
can state ERROR-ACTIVE restart-ms 0
....
RX: bytes packets errors dropped missed mcast
56137726 7673887 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2961096 493633 0 0 0 0
Is there an easy way to refresh the toolhead without refreshing the Manta board?
Doing updates from the update manager in Mainsail or KlipperScreen does not change the firmware on the microcontrollers on the Manta or EBB (tool head board), even if Klipper updates on the Linux OS. Right now the only way to update microcontroller firmware is to log in by SSH, compile new firmware, and flash them manually.
So updating packages shouldn’t have broken communications between the Manta and the EBB.
The “can state ERROR-ACTIVE” makes me think there is a problem with the CAN Bus cable between the Manta and the EBB.
The way the system works in Klipper is the Manta acts as both a USB CAN Bus adapter, and also a Klipper MCU device on that same CAN Bus it creates.
One of the error states of CAN Bus is that when a device on the bus is sending messages and never gets a reply, and also never sees any other traffic, it assumes that itself is the problem. In a system with lots of CAN Bus nodes, like in a car, it’s unlikely that all the other devices on a bus will stop transmitting at the same time, so the node says “I must be the problem” and shuts down. I believe the “can state ERROR-ACTIVE” is the USB CAN Bus adapter firmware on the Manta doing this.
But in reality, it’s probably just unable to communicate with the EBB tool head board, which could be caused by a bad CAN Bus cable between the Manta and EBB. With no other devices to show a live CAN Bus it goes into the error state. Theoretically it could also be a failed EBB board, but that is very unlikely.
What error message is showing on the touchscreen or on the Mainsail web interface?
TLDR: Updates shouldn’t have broken CAN Bus communications, check the cable between the Manta and the EBB.
Just to circle back:
We started over with a clean image (following the documented steps) and after some fiddling with Z it’s finally behaving, no other changes were made to get it working.
to reply directly:
Since we got it working with a new image I figure it must be that something was broken in a way that made it seem like SocketCAN was broken to the scripts but wasn’t in fact broken. It’s a shameful admission because I’ve worked with it fairly in depth in a former day job.
Moral of the story is be careful whom you let touch the internals of your equipment.