Indeed very strange! But more than a handful other users seem to have no issues with the latest updates including me. Although more than homing of X and Y is currently not possible…
Don’t you have another spare board available?
What speed does the Mainsail GUI report for your involved MCUs?
Hi Brian, you want to see this?
mcu(stm32f446xx)
Version: v0.12.0-102-g9f41f53c
Load: 0.00, Awake: 0.00, Freq: 270 MHz, Temp: 30°C
0
mcu rpi(linux)
Version: v0.12.0-102-g9f41f53c
Load: 0.04, Awake: 0.00, Freq: 50 MHz,
4
Host(aarch64, 64bit)
Version: v0.12.0-102-g9f41f53c-dirty
OS: Debian GNU/Linux 11 (bullseye)
Distro: MainsailOS 1.3.2 (bullseye)
Load: 0.68, Mem: 187.5 MB / 859.7 MB, Temp: 39°C
eth0 (192.168.51.202) : Bandwidth: 3.4 kB/s , Received: 136.4 kB ,
in my black despair i tried to deactivate interpolation, stealh chopping and set microstepping to 32 - no, doesn’t work.
And to my estimation I’d like to say i neither have a performance problem with my MCUs nor with the RPi.
Why are you already on Klipper v0.12.0.102 despite being it dirty?
I wanted to update this morning and have been presented a 0.12.0.96 only or something like that.
Or you on the dev channel or on stable main?
Speed of the board should be correct with 270 MHz I assume?!
In the past we had some challenges with 64 bit OS on the RasPi but I don’t know whether or not this can be related here…
Well I have updated to version steps today - try in two hours and you will get .104 
the dirty part is from KIAUH it always installs:
Repo has untracked source files: [‘klippy/extras/gcode_shell_command.py’]
I don’t know what it is used for, but getting rid of it makes only sense if i stop updating.
B.t.w.:
Being forced to update is a dense situation, that’s why I’m in trouble now. I was very satisfied with my v0.10.x.xx, but then update forced and BOOM!
It is an old wisdom but still valid: “Never touch a running system!”
Well it is the official MainsailOS distribution, if there are known obstacles with 64 bit this makes no sense.
So do I, to be honest - I really don’t know.
“Standby Current” is typically described as the current when a device appears to be powered down, ie in a low power state, not sitting idle.
Sorry for being pedantic but it’s important to use terms correctly so that we’re all talking about the same things.
Regarding reporting measurements, if you report values as fact without any kind of explanation of the equipment people will either a) assume you have the equipment to properly measure them and potentially go off in the wrong direction or b) question what’s going on and sidetrack the conversation.
What is “2 x 2,5mm²”? If you’re going to describe wire, it’s customary to state what it’s AWG is.
Regardless, if your bench power supply isn’t giving a current reading that matches the expectation of the board/drivers/printer.cfg why would you trust it to provide an accurate voltage output reading?
Again, I don’t know your equipment but I always check voltages with my trusty Fluke DMM.
I agree with everything you’re saying but for years I’ve read about people having issues with using the 5V power from their Octopus boards for their Raspberry Pis.
Power is probably the most critical parameter for 3D printers. You can’t marginalize it.
Personally, I think 10A is too low for what you’re doing and I’m not sure how you’re testing things in terms of whether or not the bed/extruder heaters are on.
Looking at your discussion with @LifeOfBrian and I’m not sure what’s going on there. I’m currently running V0.12.0.102 without any reports of it being dirty (I just checked my klippy.log and there are no warnings there).
Typically, if I do an update and it comes up dirty, which happens very occasionally, I reload it and everything is fine.
Regardless, if I do get an indication that Klipper or any of the other components are dirty, I reload and don’t continue until everything is clean.
Sorry @mykepredko but AWG is …uhm, quite anglo-saxon
In the European area you use SI units and this is square millimeters for cable cross sections. And behold: It even makes sense since more square millimeters means a thicker cable and not vice versa.
2x2.5mm² means 2 wires, each with 2.5mm² cross section (=AWG13 or 14)
Agree, 24V / 10A is quite tight for a 3D printer plus host but then again, the tests by @limefrog have been quite synthetic and failed pretty early.
Who forced you?
KIAUH installs this unofficial module only if you request it to do so. Generally not needed unless you have a use-case for it. Widely spread and no indication exists that it might contribute to this error.
That’s absolutely o.k. and I agree being precise is essential, but I’d like to ask for a bit charity here since english is not my mother language.
I do because I’ve measured the voltage with with my trusty DMM (will omit the brand name here, but it was definitely cheaper than yours) and it shows exactly the same reading in all four digits.
Definitely agreed, and that is the reason why my 850W bed heater runs on 230VAC, so the 10A on the 24VDC rail are quite comfortable for everything else.
I’ve heard that first time here and had no problem so far doing it that way for about one year. Had some other problems (mechanical) but after solving them the combination proved to be rock solid.
On the other hand I’ve already followed your suggestion and used an independent PSU for the RPi. Nothing changed.
Yes, I did that once (agreed on question), but KIAUH has no option to remove it. If i remove it by hand, it comes back with the next update.
Since it does noting for me and according to
I decide to leave it as is until i tidy up everything when this is topic is done.
Good question. Would tend to the Mainsail update manager. It updated klipper with the whole of packages and after that i had to update the Octopus, because of version clash. When i did as told, everything died. An option to step back to same version as MCU would have been nice. And yes, my point of view is one-sided, i know and in my mood that is quite necessary at the moment.
You learn something new every day.
According to the references I found, 2.5mm^2 is 14 AWG.
Does anybody know, if reflashing the MCU is lethal to any data? Is everything overwritten in this process or is something kept? If so, is it possible to wipe the MCU and reflash it in a clean state?
It depends on the method you use to flash it.
Personally, I use DFU mode with the with the mass erase option for the Octopus (and Manta M8P/M5P):
sudo dfu-util -a 0 -D newFirmware.bin --dfuse-address 0x08000000:force:mass-erase:leave -d 0483:df11
Thank you for the information. I just did it with the make flash command so far. I assume that does not flash in a clean state.
May I use your line directly (beside changing newFirmware.bin ) or do i have to find correct parameters for my board? the value behind -d looks like an usb id.
Am I right to use this id shown by lsusb:
Bus 001 Device 004: ID 1d50:614e OpenMoko, Inc. stm32f446xx
The dfu-util command is only to be used when the Octopus is in DFU mode.
That means shorting the BOOT pins on the Octopus and checking for the USB ID 0x0483:0xDF11. It will not work with any other USB IDs.
I suggest that you read the Octopus’ User Guide and other documentation on dfu-util.
We should put our pieces together. You have XY, I have Z - should work!
I’ve read in the instruction manual, chapter 8 precautions, topic 5.:
It is recommended to update the firmware using SD card. Using DFU (direct
programming via the USB port) will overwrite the bootloader meaning that you will no
longer have the option to update via SD card.
@mykepredko Is this the case with your line? How do you handle that?
Just for my reference:
I’m wrong here! I tried:
SET_KINEMATIC_POSITION Z=100
G1 Z0 F1500
I got:
MCU 'mcu' shutdown: Timer too close after movement stoppedSo, I’m able to provoke the problem on the Z-axis also! And again, the error appears when the movement is completely done. The decelleration at the end of the move worked out, no interruption.
I tried the same thing with 300mm up and down, exactly same behavior. Remarkable is, that it takes maybe a quarter of a second after movement has stopped until the error appears.
Saying that, i think my homing problem doesn’t come up with the begin of XY movement but with the END of the Z-movement!
…or better let’s say with the END of ANY movement.
This works for me. Just tested this with my new Z axis and new setup.
So this is either a corner case on your side or the board is the issue here.
Stays very strange!
Could hardly be, it is the second board already, which shows the same behavior.
Out of the box, just flashed with the current firmware.
Yes, i think so … but how to get out of here!?
O.T.
@LifeOfBrian
Congratulations to your running Z-axis.
“May the schwartz be with you!”