Have set the Z-acceleration to 75 mm/s² - maybe I’ll push it further later (having ball screws also), but i don’t know if I have the need to. This is also an overcame setting, it was set because of sagging bed while printing, but i have build a 2:1 belt reduction which doubles the torque here and the problem is gone. So making me to push this value is quite legitimate.
I have no observations made of this kind - so far. Having just a NEMA17 pancake stepper here running with a current of 500mA propelling a feeder with 3:1 reduction. What I have seen is: With a serious clog of PLA in the heatbreak the motor kept turnig, while the plastic gear of the feeder hopped over the teeth of the blocked metal gear! So I see a lot of torque without loosing steps here.
Exactly.
Have changed the drivers one by one (rotating with a fresh one) and nothing changed. After that I was up to reconfigure for moving the XY-steppers from Motor0 and Motor1 to Motor6 and Motor7, moved the drivers and motors. In advance to altering the pins in the config I’ve initiated a homing with the original config, knowing I won’t see movement but without the sockets populated with TMCs and steppers deconected I receive the same error:
Thanks @Sineos for your summary and your Ideas, but I’m afraid the game for my Octopus seems to be over.
I’ll surely continue investigations but i think it is time to order a new board.
So, at this point one question comes up: Which board is recommended to replace the BTT Octopus v1.1?
Use the same Octopus again (simple solution, cheapest maybe) or head for a BTT Manta M8P (I stumbled across that in another topic here) which looks promising (will be more expensive, but what are the benefits)?
What bothers me a bit: “Timer too close” is an error more related to the host than to the board. Of course, some interaction between the board and host can apparently also be causing this, but still more host related.
This is just to exclude all possibilities.
In fact (and with pretty much everything in Klipper) the updating of the LEDs with new color information etc. is done on the host and then send to the board for execution.
So, head tells hand to do something, hand does (XY-axis) or fails (pixel) but don’t give feedback to head, so head thinks: “forget about it” and tells me: “Timer too close”.
And just to complete the picture: Z-axis is foot and foot still gives feedback to head so head doesn’t complain until it calls hand.
If this simple allegory hits the point, I’ll tend to find the hand guilty again.
Power supply is done with a benchtop power supply capable to deliver 10A set to 24V and feeds the octopus, while the RPi is fed with 5V directly from the Octopus (J26).
When homing is running on Z-axis (three Motors) the power supply delivers apx. 850mA, standby current is apx. 180mA. I’m willing to declare the power supply sufficient.
A couple of concerns here with the big one being that your numbers don’t make sense.
First off, I’ve always heard that powering a Raspberry Pi from the 5V output of an Octopus is problematic - this is why Voron (and others) specify a separate 5V bulk supply for the rPi. Doing a quick Google search on this and I can find a number of people who have tried it and run into problems with the solution being going to a separate supply. For your testing, I would highly recommend getting a separate 5V supply for the rPi that is capable of 3A continuous - I suggest you use a genuine Raspberry Pi power supply for testing.
Secondly, when I look at your klippy.log you have the X/Y steppers supplying 1.3A each and the three Z axis steppers at 1.25. You should be seeing a considerably higher draw than the 0.85A when homing that you are reporting.
I’m not sure what you mean by “standby current is apx. 180mA”.
Are you checking the 24V voltage at the Octopus power terminals when you are running the homing?
Sorry for budding in but the numbers don’t make sense.
Never mind, I’ll tell you what I did. The easy one first: standby current just means: Switching printer on, wait for end of boot process and pick the number while the printer does nothing.
The Z-axis homing current is the peak level i can read when Z-axis is moving down in preparation of the XY-homing.
The values are read from the display of the benchtop power supply. Since the Z-hop is a very short action and the display is refreshed maybe just every quarter of a second I just get an integrated number over that period (and split in two chunks for sure). In lack of an oscilloscope I just can provide such an abraded value.
It’s my fault, not to have in mind that most of you have quite better equipment and methods than I do. So your criticism to my numbers is quite legitimate. I should avoid to worry things with numbers read this way.
No, I took the number from the display of the benchtop power supply, but my wire is 2 x 2,5mm² and half a meter long with crimped cable shoes and soldered banana jacks at the ends. So I don’t fear voltage falloff is too bad.
That is bad news in deed. So you say the pins dedicated for raspberry pi, mentioned in the instruction manual, page 10 shouldn’t be used?
Well, I’ve just read that people connected an additional pair of wires between Octopus and RPi to get rid of that problem. But those guys needed power for cameras and displays, which i do not have (I only power the ADXL 345 from the RPi) and they got undervoltage warnings I don’t have also.
In fact I dislike having more than one PSU flying around but will try that also.
Build in a new Octopus, updated klipper to v0.12.0-102 flashed it to linux MCU and to new Octopus:
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08008000, size = 29084
Download [=========================] 100% 29084 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
dfu-util: can't detach
Resetting USB to switch back to runtime mode
Flashing worked on first try without complainig, wow!
Pasted the new serial into the printer.cfg and power cycled the printer:
MCUs connected
neo pixels not lit - forgot to plug them in, phew! (leave them for now)
buzzing stepper (Z-Z1-Z2-X-Y) all do (leaving out E because filament is still loaded)
homing X only, getting: MCU 'mcu' shutdown: Timer too close
… I really get mad!
I can’t blame the neo pixels also, they weren’t connected. Used the same TMCs but in different order, since Z-axis moved again like a charm (with 75 mm/s²) the previous XY drivers do their job.
Edit:
Tried independent PSU for the RPi only (yes, opened Jumper J63 on the Octopus) but got the same result.
I’m willing to believe here has something happened on the software side. Everything began with the software update, nothing hardware related was touched between update and fail and everything ran fine since about half a year until then. last but not least: Every piece of hardware (correct me, if I left something out) was changed or moved, but nothing worked.
Does there exist any kind of self testing routines I could perform?
… I really get mad!