Zero on mainline Klipper?

Sovol Zero
42

Very much disagree, two members were having a discussion on things and along came the thought police (you). No new thread needed, as I said you could have simply moved on but here we are…

I suspect you’ve killed the thread so you’ve got your wish, well done party pooper :partying_face:

43

K1maXburst repo Features

There’s a lot here, I’m still going through it. Some key things that pop WRT to the Zero:

  • Yes
    • MPC heater control (like vvuk and Cass67’s repos)
    • per-axis acceleration Motion control (also like Cass67’s repos)
  • Maybe?
    • Runtime/compiler optimizations: not yet assessed for the Zero.
      • While the H616 clearly could use some help, its mostly OK, and certainly far from the champion of starved klipper hosts
  • No
    • The K1’s 4 analog bedside load cells don’t have little in common with the Zero’s problematic “tare-tapper”

Re-hosting the Zero mainboard

  • The klipper MCU is NOT accessible on the general CAN bus - only the toolhead and optional chamber heater
  • Other H616 peripherals (ethernet, wifi, hdmi, camera) would need to be re-implemented

Few options, none of them great:

  1. Demote the H616 to a bridge, so it can connect to the next bridge and access the MCU (conceivably could work with the S3 or other phone)
  2. Reflash the H750 to either:
    a. provide CAN over the spare PB8/9 pins, connect to the host that way (works with another board/SoC)
    b. expect the host on the main CAN bus, and make sure the H616 isn’t spamming it trying to get it the old way
  3. Keep the H750 as is, tap & cut the USB lines on PA11/12 (also notionally phone-able route)
  4. Reflash the H750 to provide UART/FTDI (a combination of options 2 and 3, but frankly not better than either of them)

Honestly, if I had to do this, I’d pick the first one and hate it, and just end up replace the whole mainboard.

Reusing phones

  • Love the principle, I do it where I can. haven’t on a printer yet
    • The effort regarding the power and connectivity are the sticking points
  • OTG splitters or hubs are a good alternative to hardware power mods, especially when tied to a state-of-charge limiter is employed
    • newer Androids carry some limit, say 80%, as stock now.
    • ACCA and other LineageOS/rooting tools are more configurable
    • I use a deep limit, only 30-40%, for these always-connected applications. let the stock battery live for years, your goal is just to keep from dipping into Battery Saver mode under peak usage
    • External BT controlled power switches, like the Chargie, are another way to provide power to a phone without cooking the battery
44

I think reflashing the main MCU for CAN on the existing transceiver would make it available to any CAN equipped host without having to install a transceiver on PB8/9. SSH into the H616 and uninstall kipper then only the “new” host pings the klipper firmware on the MCU.

45

good call, edited my list to include it

46

I appreciated @cardoc pointing out our discussion has strayed from the original post. I not only value his expertise but have been inspired by his thoughtfulness, helpfulness and patience with most everyone, leading me to think anything he offers is done with the best of intentions.

Considering this is the Sovol forum perhaps it is inappropriate to be discussing the K1 to the extent we already have. I was eager to do so because my K1 has more issues in need of work than my Sovol printers. I thought to get very far requires hardware mods and was excited to learn from you that there may be more to gain from better software than I imagined possible. Your github currently though is more tease than solution as the most interesting improvements of utilizing the MSA vector math in c_helper and the python runtime are offered as binary blobs and getting my printers on open source is a top priority for me.

Hopefully @rpcyan has sufficiently redeemed this thread by bringing it back around to the Zero that we can get back on track with or without the help of moderators. I would like to continue the discussion of the K1 too but would gladly do it in a different thread or a different platform however others prefer.

47

What do you hate about the bridging approach? Is it the wasted power or the added complication and potential points of failure? Or do you expect it to have performance issues from throughput bottle necking, added latency or something else? I find bridging enticing because it appears simple and easily reversible or changeable which enables contemplating using a dodgy piece of kit such as an old cell phone which might die at any time and could be hard to replace with something nearly the same when it does.

48

My concern is the complication and potential points of failure. Just feels a little fragile to me, but you are right that the reverse/revert-ability of it is handy for experimenting & iterating