What that is a Nextion?!
Which model?
That makes the SK1 quite interesting
Having header is the best options after a real usb socket since you do not need to solder (warrantyâŚ). While you can also poke headers through the tht holes this solution does not have good contact allways and is therfore bad in the userperspective
Once upon a time, people made products that considered the users perspective. Gotta save that $.30 though.
I love how they have all that empty space around the rp2040 and no capacitors. I mean⌠Every datasheet in the universe says put capacitors AS CLOSE TO THE PINS AS POSSIBLE.
I think they took the opposite approach here.
âHow can we shove everything away from the mcu as much as possible to crowd the corners and thus not have any room for a USB plug. 
â
Okay, I literally laughed out loud. That made my morning. Thank you for that.
It identifies itself as TJC4827X243_011C model, 480x272 resolution.
In the meantime I managed to connect to the display via /dev/ttyS1 at 57600, and update firmware using nextion ¡ PyPI
Also I am looking at GitHub - joakimtoe/KlipperLCD: A simple LCD service that enables the Neptune 3 Pro LCD screen with Klipper project, but it definitely needs adoption to SK1.
have you tried any of the restart_method: options in the mcu config for the toolhead board?
I noticed I have connection issues any time I need to restart the firmware via fluidd. The RP2040 does not reset on its own but if I hit the reset button everything comes back online.
Short stupid question.
Do you have the same setup as @grafalex?
Yeah, same setup. SK1 with updated klipper FW on both the toolhead and mcu board. Seems either thereâs something not implemented correctly in HW on their toolhead board or a linux software side issue. Really contemplating just swapping this out for a manta m5p since there is no support for the OS side of things, we just have the stock image available with Debian 10
Honestly, something you both may consider depending on your willingness to invest the time/money involved.
Itâs a sidelong view in the pictures but that connector looks like a Molex Micro-Fit Jr 3 connector which is the standard connector on a Huvud CAN Bus board and with a few others youâd just need to crimp a new connector.
I donât know if the serial connection wire inside your printer is twisted (which is what CAN Bus likes due to differential signaling) but honestly there is a high likelihood it will work anyways. CAN Bus is very tolerant of poor wiring and noisy environments (thatâs why itâs used in the Automotive field).
With one toolhead and a UtoC (USB to Can) board you could run a CAN setup and then youâre good to go. That looks like what they were going for on your printer and just skimped on costs.
Disclaimer: Youâre assuming some (should be minor) risks here. Worst case scenario is youâd have to pull the wiring to the toolhead and run it again with a twisted pair which is mainly just annoyance. But you assume the risks of your printer. Iâm just giving you an option.
Some examples: (Iâm not affiliated with any of these, they all work equally as well, just copied the first link I saw)
The Huvud below is a direct connect (check the wiring layout but you wouldnât need to replace the connector).
These two use a Molex Mini-Fit Jr 3 which is larger and youâd need to repin your cable for the larger connector, but you SHOULD be able to use the same wiring.
(Itâs the 4th item on this page)
You can find it cheaper than Amazon though this one does come with the UTOC board you would need to use CANBus
If you go for any of those except the last one youâll also need one of theseâŚ
(5th and 6th item on that page, BTT also has a version but Iâve heard itâs iffy. I use one of the Mellow fly ones and it has worked great for years)
Again⌠Just giving you some options rather than just giving up on a perfectly good base printer.
If you swap itâŚ
Are you living in the EU? I would be nice if you can ship me the original board thr (and maybe the nextion too) then I could try to port my kingroon guide to the SK1 too
CC @d0u8l3m @grafalex
If he swapps it to the manata m5p no U2C is required.
Also I recommend using a EBB since it is from the same vendor - you need to check if the ebb36 (microfit 3.0) or 42 (minifit jr) fits better
Thanks for the links, I really donât want to give up on getting this configured properly, but itâs just such a pain without proper documentation and support from TwoTrees, when issues come up, they just become a time sink trying to fix because you have to figure out basic stuff that should be documented somewhere. (dont get me on a rant about them not honoring the licensing haha)
I had it working for a good while and then it just stopped being able to connect after a restart. I got it working again now but the screen throws the emergency stop error and you canât use it, so Iâm just getting to a point.
I think the toolhead initialization is part of the issue, I changed the flash option in the klipper menuconfig to use the generic one instead of W25Q080, and software firmware restarts seem to work better now but the e-stop screen warning is still there.
I run a M5P and EBB36 on my salad fork so I was going to pick those just for some form of standardization/consistency. I have a spare EBB42 I can use and was thinking about getting a pi-can adapter to use on the stock board, but at that point itâs like why not just swap it out for something supported?
When it works it prints very well, all the salad fork parts were printed on it and are high quality imo so I definitely want to keep this printer running
I actually have a spare mainboard I could send you if you send it back when youâre done lol (Iâm in the US), If I canât get these to play nice with the stock toolhead board+mainline klipper I was going to throw them into some old flashforges and run the extruders off the main board instead.
What e-stop screen warning?
Meh shipping it overseas two times⌠
I have the bottom open so itâs on its side sorry for the orientation but basically that estop will come up if the connection to the tool head drops and if you hit restart, it restarts fine and you can use fluidd but it either stays at the estop screen or that reloading screen so youâre limited to just the web interface after that.
I donât think Iâve ever shipped overseas so I donât have a frame of reference for cost, but I guess with the way things are I could see it being a lot lol
So idk what I did, I reflashed the OS image, it was stuck on the estop screen so I couldnât connect to a network, and the first run text file didnt seem to work to connect the wifi, so I tried flashing the RP2040 to use USB leaving the program cable plugged in after, and for whatever reason that let it restart the screen and stay at the home/network page long enough for me to get it connected to the network again.
I then added the update manager to mainsail, updated that and klipper, and now itâs cold booting fine. Iâm worried about trying OS updates again because that screen bridge program sucks and might get screwed up again.
What prompted me to post here initially was that it was powered on just sitting idle and randomly started beeping and had the estop screen then I couldnât get it to work again until I went through all this.
So I guess I will leave it idle for a little while and see if it stays connected. Not really a helpful post but just posting itâs behavior and my findings.
EDIT: Wow user reply limits make ZERO SENSE
Wanted to add I left it sitting powered on all night just being idle and it didnât freak out.
FW restarts via the webUI seem to work now, but if the screen ever goes to that resetting message it will hang there.
To fix it you can run:
systemctl restart makerbase-client.service
The screen will reinitialize with that.
I also upgraded to debian 11 but commented out the armbian repo before doing so according to this post Bullseye Upgrade
So to @grafalex I would recommend trying to start fresh with the OS but before you do reflash the toolhead to stock if you backed it up. I should have but didnât =[ , if not youâll have a fun time trying to get the screen to not error out with the estop message so you can connect it to the wifi
I have some progress debugging my issue with toolhead board. I flashed micropython and wrote a simple program, that periodically sends a messages to UART - this program always works fine. Same with C++ version of the program. At the same time klipper firmware works only in 20% of runs. My guess is Klipper firmware fails to initialize for some reason prior initializing UART.
While I am now studying Klipper sources and documentation, does anyone know if it is possible to enable logs over the USB CDC? If someone already familiar with the Klipper code, the advise would save me some time.
Thanks for the links, the EBB42 board may fit to the SK1 toolhead, but the mount holes seem to be a little different. The biggest issue, though, is that it will require changing the main board as well. Iâll keep it as a backup plan.