Why don’t you reverse engineer your problem and start from the working system?
If you still have some old klippy.log, when your printers were working with the factory setup, you could strip that!
I think the last Klipper version used by Twotrees was 11.9.0
Why don’t you start with a block diagram?
How is everything electrically connected. I wonder about that.
Actually that I whereI started from. It was working until tried to update klipper on the toolhead. Unfortunately something happened and I am trying to figure out what exactly.
Officially published firmware is for main board only. There is no firmware for the toolhead, so I cannot revert to the working version (there were some klipper sources in the printer’s file system, but I cannot guarantee that these were exactly sources the firmware came from).
I did this as well. But it is crookedly drawn on paper, and I am ashamed to publish
The printer.cfg is fine, As I said sometimes firmware boots, and the printer works normally. The MKS_THR.cfg is shipped with the printer next to printer.cfg, but there nothing interesting:
I’ve already wasted enough time probing around and figuring out MCU pins. I’m fairly certain it’s a software/firmware problem, but so far I have another 10 hours on it after re-doing all the updates following that armbian post instead of the reddit update one I used initially.
So I hope it continues to play nice, switching to the generic flash seemed to help with restarts after editing a config.
The screen can still get in some states where you need to run that restart service command, but I guess you could always make a macro button for that in the web UI.
As long as it works and the prints stay nice I’ll leave it alone but the moment I have to spend more than a half hour fixing software I think I’ll go the manta route.
I have old logs but no real way to correlate what state the machine would have been when they were downloaded so can’t really help there sorry
Is there a way to confirm what flash option is correct on this rp2040 is that referring to internal flash or something onboard?
Having that the toolhead board is connected with only 2 wires (UART TX/RX) the only method is ‘command’ (obviously it works only if the microcontroller has not hung)
Which pins do you mean? All the pins are listed in the printer.cfg
@hcet14
I doubt klippy.log files can help here (or I do not understand what to look there for). These are logs from the host, but it works as expected. The problem that I am particularly facing with is that toolhead MCU does not start normally, and the host simply cannot connect.
The question is why the MCU cannot boot, and where it stops? I studied the code a bit, and there are number of places where the firmware just terminates with an error. Perhaps I hit one of these cases, but in the meantime I do not know how to get the error code.
I am new to RP2040 microcontroller. What I am a little bit confused at the moment, is that Klipper code does not use SDK initialization routines. Insted it writes directly to microcontroller registers. This may lead to inconsistency when Klipper uses some SDK function, which expects SDK initialization calls first.
The SDK just aliases the registers to make it easier for developers. At the base of it they’re both doing the same thing.
SDK’s are great for when you’re developing but they tend to make the code bulky because they add in a bunch of “general” things to make it easier for the widest audience.
Once people know exactly what they’re doing and exactly what they’re expecting they strip away the SDK code and write straight to the registers to slim down the code and make it faster.
I perfectly know how to program microcontrollers with registers, as well as using SDK only - I have 20+ years experience with this I just would like to ensure there is no situation that someone uses a mix of SDK and non-SDK approaches.
Consider a scenario:
Person A writes a Klipper code using raw registers
Person B adds an SDK call in the Klipper code
SDK updates, and a function called from a Klipper code changes. Now it uses an internal variable which is supposed to be initialized with another function, which is never called to the Klipper code as person A did the HW initialization using registers.
Now you have a floating problem. Firmware either works or not, depending on an uninitialized variable.
Another possible reason of startup failure is communication with some external peripheral, which goes wrong, and the firmware just halts. I am currently trying to add USB serial for logging (unfortunately this might fail as USB connection is reset during RP2040 reboot).
Meant no disrespect or seem like I was “talking down”, there is no way to know the knowledge level of another person.
As for the mix of SDK and non-SDK approaches, anything that attempts to get added to mainline klipper goes through a PR anyways and would get flagged during the build check/code review. If someone tries a mix of methods and has all kinds of errors while testing their own changes, That’s on them to figure it out.
Usually most of the changes are to the “base” source files anyways so affect all the mcus. That’s obviously not always the case, but tends to be the norm.
Firmware halting on startup because of peripheral communication should have been caught in testing, If you mean like an on board peripheral. If you mean on another board, all the communications go through Klipper (as far as I’m aware anyways) so I don’t think that would come up.
@grafalex Not all the mainboard IO was listed in the config, the additional header outputs/fan options were not all there. There is also a header at the bottom that is the stlink connector that was not labeled.
So far so good on my end. If there’s any serial data you want me to try to capture let me know.
And if someone can confirm what the flash option is for/how to determine the correct one to use; I’ve read mixed things on if the RP2040 has built in flash or not.
Indeed, I hit the same issue today. I ended up flashing Micropython again, and simply tried pins in a loop, setting them on and off. The extra fan next to the power/data connector seems to be connected to GPIO23. Surprisingly there is a LED connected in parallel that could be used for simple debugging.
Really? Where it is? The only header on my board is USB.
In the meantime I localized the hang problem, and it is in the clock_setup() function around setting up oscillator and PLLs (klipper/src/rp2040/main.c at master · Klipper3d/klipper · GitHub lines 134-146). I used mentioned LED on GPIO23, turned it on before mentioned code, and off after. The board fails to pass this part in 50% of cases.
This all makes things quite complicated, as I need to read the microcontroller datasheet to understand this code. Is there someone who is familiar with this part?
Hello, unfortunately I also have this printer. My piece didn’t work well right out of the box. Klipper was falling for the “THR Timer too close” error. Followed by “Emergency Stop”.
The electronics in the printer are pretty crappy. However, the first thing you can do to improve stability is to replace the extruder cable with a stronger one with twisted pairs. The original cable has wires that are not twisted, with a diameter of 0.14mm2. Up to 4A flows through this cable at the peak.
In my case, changing the cable ensured stable operation and communication of the printer. But I was not satisfied with the electronics, the overloaded power supply, and the software, so I replaced everything.
The odd thing there is, plenty of people have RP2040 based boards (I do) and don’t have any issues with the existing code. Don’t know why the toolhead on that board would be any different.
I would say that the cable to the extruder is 80% to blame.
It’s not twisted, it’s very weak, runs parallel to the motor cable and other power cables, and the connector on the extruder board isn’t very convincing either.
I had slightly different problems with this printer, but they also had to do with random communication drops with THR. After replacing the cable, the printer printed a 28-hour long print without any problems. Before the replacement, it sometimes worked for 10 minutes, sometimes for 1 hour, and then the communication collapsed.
After removing the original cable I checked it and it is fine. It is not damaged anywhere and all the wires have been remeasured.
At the very least, I would try to temporarily put a second cable in parallel next to the original one and connect it to extruder board.
I’m thinking the same, poor cabling is probably causing communication issues after the pll’s enable and the timer functions get setup. Immediately after that the scheduler gets setup and starts trying to sync with the Klipper.
It’s probably failing to sync correctly because poor wiring on their board.
The problem is, your PR adds a delay for EVERYONE when only YOU are having the issue. A delay that could potentially cause issues for everyone else with rp2040 boards that are currently working just fine.
I understand that replacing the board and toolhead would require money, I’m not saying go out and spend it. Merely pointing out this might be one of those fixes you run on your own Klipper fork.
Plenty of us run custom Klipper forks that have functionality not in the mainline to fit our needs or for testing.
Yeah I’m also not convinced that its a klipper software issue, ever since I flashed mine most recently it’s been working fine without errors. What are your makefile settings @grafalex ?
@Exxon In your video it looks like you used CAT6 network cable which is the exact opposite of what you should be using in this application. You want a FET/PTFE cable with stranded wire.
Also, this printer uses UART it doesn’t need to be twisted, if you switch to a CAN system, then you would need to worry about that.
