First of all sorry for creating one more topic like this.
Could you please help me analyzing this klippy.log to get an idea who’s guilty in this awesome error?
Happening on some prints after 1,2,3… hours of prining
What I did trying to get rid of the issue:
Initial setup was using BTT CB1 image based on debian 11. Now reinstalled the system with armbian cli debian 12 image with using new SD card
changed controllers fans configuration to run 100% while printing (temperatures for CB1 and main board cpu seems to drop from around 50+ to ~ 42°C)
added fan to SB2209 with config to keep ~50°C (before it was 60+ while printing)
-changed microsteps for x and y to 32 from 64
What I did to get this even worse (but not sure that’s affected smth)
added usb web cam logitech C270 with 800x600 config and 5fps.
Please help. I’m frustrated. Printer is awesome but it’s not reliable((
And the stupid question regarding the nature of this error.
If error says MCU EBBCan’s timer too close does that mean actually this partucular MCU (in my case rp2040) is guilty? Or that’s not the case and this one is just ‘because’?
Why I’m asking? If I add 35$ more and get CB2 instead of CB1 will this help? Or it’s useless? And issue is somewhere on titally different side?
yeah, I did. Can’t claim I did 100% of them. But a lot…And for me this error actually mean “idk what’s wrong with you, just throw away your voron abd get something running on marlin((”
Therefore I was having a vague hope someone can extract at least some meaningful information regarding my particular case from logs
Judging from your post, you did exactly nothing of what is recommended for this kind of error.
Literally thousands of Vorons are working fine with alike setups, so maybe a first place to start is Timer too close plus what @NAPCAL recommended: Use the search function.
To be expected. Adding a webcam to an anyway instable system is rarely a good idea, but at least confirms that probably the items mentioned in the above link are the right track.
Well, that’s really might looks weird. But I just finished the build recently. And I’ve been searching a lot on internet and did not find the info that I can’t run web camera on Manta M8P + CB1. I agree having the stable system without a camera is better that taking a look on the camera frozen picture showing how ‘timer to close’ looks like. But how can I see then actually the camera is guilty and current setup can’t handle the camera then (even with 800x600 and 5fps)?
What shall I change If I want to have camera and reliable printing?
A CM4 is faster, and you can run RPi OS Bullseye, not Bookworm, and not the altered BTT OS; this would eliminate if the CB1 or BTT OS is causing your issue; it should have better support for your camera.
If it still happens after that, then change to an external CAN bus adapter and remove any load from the board’s MCU that could be causing delays in the communication to the SB2209.
So actually one of my questions was related to the error ‘nature’. It says ‘timer too close’ for actually my rp2040. If you’re saying I should get CM4 that mean it can be not rp2040 who’s busy with doing something, but my host computer not being not able to communicate in time with toolhead. Correct? So getting more powerful host can be beneficial in this case. Or that’s not always working this way? I mean is there anything which can be actually analyzed in such cases with at least pointing to direction if not the particular guilty part? rather then trying to change different part of the system with the hope that it’ll help
The last set of instructions sent to the SB2209 could not be completed on time, so something delayed the delivery of the set of instructions sent out to the SB2209.
Klipper controls multiple MCUs by a set of instructions performed in very close timing so that the MCUs will work in parallel.
The CB1 could be overtaxed when communicating via USB to the MCU side of the M8P (onboard connection), USB to CAN using the MCU of the M8P (onboard connection), and USB to the Camera via the USB-A connector.
The Raspberry PI CM4 and RPi Bullseye are very well-established configurations. Also, you would be able to use the 2x20 GPIO with no alterations to pin assignments and standard hats.
Thanks, good to know someone can be happy))
My understanding btt pi2 is a kind of standalone, so need to communicate with main board via USB, which is not supported for Manta M8P. So I already flipped out and ordered CM4 as suggested. For now switched off web camera. Looks a bit better, but still got timer too close once after that((
Please check your udev version. If it is 24x, upgrade it to the latest 25x. This is an essential firmware issue related to CB1. I have reported it to the engineers at CB1, and they may update the firmware on GitHub. The commands you will need are:
apt show udev
sudo apt install udev/xxx-backports (where xxx is your Debian version codename, e.g., sudo apt install udev/bullseye-backports).
Oh try and reduce your microsteps to 16 if they’re not already. I noticed it seemed to make a bit of a difference. Still got the errors but not as much.
Is this the problematic version you mentioned or the updated version? If you’re using the official firmware released for CB1, your latest udev version should be 252.29-1deb12u1bpo11+1.
