Have you tried a new SD card or not? For this error, this is definitively something I would test.
WRT Armbian, I have two boards running on Armbian Bookworm and not noticed any strange Klipper behavior except Klipper-mcu Service Fails to Start
1 Like
At least my Octopus Pro on my IDEX works fine as well.
Does the homing suchend in any way?
Meaning does one axes triggers its endstop or when exactly occurs the error.
What happens when you manually trigger the endstops or perform a stepper buzz on the X and Y steppers?
Swapping stepper drivers is always an option even when the dumps look fine.
Also test a brand new SD card as requested with a simple Klipper installation.
1 Like
… I made up two SanDisk SD cards which both do not connect to the Octopus. One made of Armbian set up with KIAUH and one made of MainsailOS updated with KIAUH. The latter I have in the RPi at the moment.
I was able to compile Klipper v0.12.0-100 with the installation an flashed it on MCU and RPi.
Version: v0.12.0-100-g600e89ae
Linking out/klipper.elf
$ make flash
Flashing
Installing micro-controller code to /usr/local/bin/
but connection does not happen.
Klipper reports: ERROR
mcu 'rpi': Unable to connect
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Error configuring printer
According to Sineos suggestion above I tried:
$ systemctl status klipper-mcu
and got:
Unit klipper-mcu.service could not be found.
tried:
sudo service klipper-mcu start
and got:
Failed to start klipper-mcu.service: Unit klipper-mcu.service not found.
changing to the previous Samsung SD Card connects immediately, shows correct version of MCU and RPi (also updated to v0.12.0-100) an does everything but moving XY, which crashes instantly.
You simply did not follow RPi microcontroller - Klipper documentation
1 Like
Homing proceeds as follows (head is nearly centered above bed, no endstop triggered): After invoking the homing the bed is lowered by 10mm to get free space for XY-movement. At the moment the X-movement should set in, it instantly crashes. No X-movement happened at all. Same is if just Y-homing is invoked for Y-movement, Z-lowers then instantly crash. Since it is a coreXY machine that is of no matter since both steppers have to move.
Buzzing is something i haven’t tried yet. Will go back to the previous Samsung SD card and do…
I’m afraid youre right, made that just out of my head. Will read and regret, i assume. 
O.k. buzzing does someting! I was able to buzz z,z1,z2,x,y! All of them moved!
invoking
17:17 FORCE_MOVE STEPPER=stepper_x DISTANCE=10 VELOCITY=10
led to crash after moving the 10 millimeters.
After restaring
17:18 FORCE_MOVE STEPPER=stepper_x DISTANCE=-100 VELOCITY=10
17:18 FORCE_MOVE STEPPER=stepper_x DISTANCE=-50 VELOCITY=10
17:17 FORCE_MOVE STEPPER=stepper_x DISTANCE=20 VELOCITY=10
worked but crashed one second after last movement was done!
After restaring
17:22 FORCE_MOVE STEPPER=stepper_y DISTANCE=-100 VELOCITY=10
worked but crashed one second after last movement was done also!
Regretting! Ashes on my head and thank you Sineos.
I made up the SanDisk with MainsailOS working now. Shows same behavior (but needed more speed to crash?):
17:34 Klipper state: Shutdown
17:34 FORCE_MOVE STEPPER=stepper_y DISTANCE=-100 VELOCITY=100
17:34 FORCE_MOVE STEPPER=stepper_y DISTANCE=200 VELOCITY=10
17:33 FORCE_MOVE STEPPER=stepper_y DISTANCE=100 VELOCITY=10
17:33 FORCE_MOVE STEPPER=stepper_y DISTANCE=-100 VELOCITY=10
17:32 FORCE_MOVE STEPPER=stepper_y DISTANCE=10 VELOCITY=10
17:32 FORCE_MOVE STEPPER=stepper_x DISTANCE=10 VELOCITY=10
after all there still is a spark of life in the machine. Thank you guys for showing me! But how to get the genie out of the bottle again?
240127_klippy_sandisk.log (589.3 KB)
Unfortunate that it did not work out with a new SD card. This would have been an easy fix.
Sorry, no further idea. Do you happen to have a spare Pi or similar SBC to try?
… Have to strip my Hometheatre for that or have a leftover RPi 1 which won’t be sufficient, will see…
… changed USB-cable between Octopus an RPi to no avail …
… have changed the RPi with an identical one - same thing.
Tried the previous RPi to propel the old CR10 via a BTT SKR Mini E3 v2.0 - worked. I did not print but homing was carried out without a problem, jogging around with no problem again.
What remains seems to be the Octopus… …or the TMCs… …or the steppers… …or whatever…
…small testprint running on CR10, will change things back then…
Very strange… 
As Z works fine can you just connect X and Y motors to two of the Z motor ports, change the config accordingly and test again?
Jumpers for the respective driver mode are set correctly I hope?!
If all goes as planned I’ll work on my NoName later and will update Klipper on all MCUs and check this as well.
If this would be a Klipper thing others should have this issue as well.
And my printer is already at 0.12.0.8x I think and homed at least X and Y properly. Need to update due to changes on ADXL code and my ADXL PCB being on an older version…
I didn’t change anything to the hardware and everything was - more or less - running since half a year.
I plan to configure the two leftover TMC slots (with fresh TMCs if i can find them ), because i don’t want to break what’s working so far.
I’ll keep my fingers crossed for your NoName! 
…Just took a spare stepper and changed one - all the same, changed the other - same also.
Strangely the crash happens after the forced movement was carried out!
So at least the stepper drivers are not causing the issue.
Still can be the ports (board) itself, hence you should swap the motor connections and alter the config. You can just easily backup the current config files and will not lose anything!
Just ran through your klippy.log to again check for anything suspicious.
Though not related to the issue I would advice you to have the feeder not running in StealthChop mode due to the immense acceleration. And avoid having a hold_current being set.
Those values don’t look right/too low:
max_accel_to_decel = 2500
square_corner_velocity = 2.50
max_z_accel = 12.5
As you seem to have mechanical endstops what happens (already asked for that information) when you manually trigger them?
What is the status of the X and Y endstops when not being triggered?
Use the following section under the Machine tab in MainSail:
You wrote some posts ago that the force move command succeded or that it crashed after the move finished.
How did the motors sound while moving, normal motor noise or a strange one?
That’s still unclear - I’ve changed the steppers, not the drivers so far. I had no time to look where I’ve hidden those spare TMCs yet, maybe I should wait for Easter!
this looks strange, because my printer.cfg contains:
[printer]
kinematics: corexy
max_velocity: 300
max_accel: 5000
max_accel_to_decel: 5000
square_corner_velocity: 5
max_z_velocity: 10
max_z_accel: 12.5
The Z-acceleration and velocity is withholdly chosen, because the Z-axis is a heavy construction, the bed is massive 6mm aluminum also. Motors are supported by 2:1 belt reduction on the leadscrews to avoid sagging of the bed (B.t.w.: The numbers are still doubled against the cr10’s default settings). Do you have a suggestion I should try?
Acknowledged! This is a leftover from the early days - I have commented out holdcurrents quite a long time ago, but missed the feeder.
This needs a bit more explanation, I’m afraid…
Endstops are optical and work as expected. Tried them in the beginning already (mentioned very discreet in the first post ) and did it again on your demand but missed to write that. So, everything is fine here.
No strange things here also, quiet and calm. But i admit that i use the forced movements with care at low speed only, but tried 100mm/s one time with no peculiarity also.
After all i have still two unchecked sources of malady (correct me if I overlook something):
- the TMCs
- the Octopus
But if i keep in mind, that the neo pixels are out of order since the first moment of trouble (have seen two of them showing a different color than black once before next crash happenend) and knowing that this normally wont be influenced by far from the TMCs i have my fears…
If all this is healed, i swear to thoroughly go through my config to clean things up! 
(and maybe pick up some advises to make things better)
New week, new attempts of solving that…
How big is the bed?
I had a 10 mm cast aluminum bed with only two spindles (ok, ball screws…) and not speed reduction and had several hundreds of mm/s².
I personally find 12.5 mm/s² very conservative even for normal spindles. But as this is not the main topic here keep it as it is.
StealthChop is not capable of supporting high acceleration at least with some certain load. Or you have to crank up the current what will either burn your drivers or “melt” you stepper motors and surrounding plastic parts.
A feeder should accelerate quickly and due to the pressure on the filament has some load.
So keep it in SpreadCycle mode and don’t miss a step.
BTT:
So you swapped the actual motors already with no change?
Then either test other drivers with risk of damaging them if the board has an issue or connect the motors to the working Z ones and adapt you configuration to this new setup.
Should be sufficient to just change the section headers to the correct stepper names but don’t forget about the endstops.
I’m now waiting for my new bed to arrive…