As many on the Slack may have heard, our lead Redeem developer has taken leave of the project for personal reasons. I personally wish him well.
However as a result, it does leave us a bit in the lurch - Redeem was on its way to a release in Umikaze 2.2.1 but before I feel I can release that version, there are a few issues that need to be fixed.
But - I’m not a Redeem developer. I can dabble and tweak the odd thing here or there, but I haven’t a clue where to start on fixing the issues that were encountered.
After a lot of discussion on the development channel in Slack, we have come to the conclusion that perhaps Klipper is a better firmware to use on the Replicape. This means, of course, having to make a whole new image and testing and everything that goes with that.
The question is, how many would like to keep Redeem as the firmware and that I focus on instead finding a developer to jump in and fix it?
How many of you would rather jump to Klipper where there’s an active community already, and the support on Replicape or Recore only implies having to contribute to the hardware description within Klipper?
Or should we try to keep Redeem semi-alive despite the issues as they are, and also provide a Klipper-based configuration?
Please make your voice heard:
Find a developer for Redeem to pick it up again
Migrate to Klipper exclusively
Make images for both Redeem and Klipper, waiting for Redeem to pick up again
Can you describe what functionality missing from Klipper is provided by Redeem?
Overall, Redeem is basically a monoculture motion platform with a small user base, which makes it hard for people to choose to volunteer to put their time into improvements. Klipper is fairly robustly cross-platform, and work put into klipper will positively impact more people. Especially with the failure of the negotiations to build the Revolve, thinking about the Re* hardware platform as a Klipper target should make it more attractive overall to more people.
With Klipper, they already have Beaglebone installation instructions, so instead of building a custom image, perhaps the focus could be on helping improve those instructions where improvement can be made, and providing documentation with sample configurations for Klipper-on-Re* boards?
I don’t have the space to do any of the work, so this is only providing an external perspective from someone with a long history working in open source, not implying that I have the answers. I do think that you’d want to provide an alternative perspective that addresses this if you were going to attract another key Redeem developer though, because I’d think that anyone else showing up and interested in joining in the fun would see the same patterns I just highlighted.
I fully agree with you Michael. Redeem is an isolated solution!
Klipper is benefiting from lot’s of developers and basically integration to BBB is done, proven and working well (for me >10h print time now). Quality is improved vastly due to pressure advance.If the MCU core is done once for Klipper the HW-adaption is done and everything new in Klipper will be available for recore/replicape also.
BBB is a bit complicated because the -ti and the -bone kernels are different (even depending on version) in PRU handling. It took me 2h to fiddle the right solution.
@Jon_Charnas is doing an ansible build for Klipper on BBB which is nice, because it’s an easy starter for a basic user. I hope he is pushing his changes to the init scripts and stuff to the Klipper project directly.
I hope @Elias_Bakken is sharing the internals of the AR100 used inside the A64 as soon as possible to the Klipper developers or even better => He is implementing the MCU part directly for that. Documentation is excellent and even the PRU implementation of the BBB could possible be a draft to copy from.
Looking forward. And I am really not missing Redeem.
I just thought about some thing that is in Redeem and not in Klipper, but found nothing (that I was using, and also nothing else I could think of).
While I agree that Redeem is a monoculture monoplatform firmware, the one missing feature from Klipper - in my opinion, is the ability to use GCodes to actually configure the printer dynamically.
Small difference, perhaps, but the ability to simply say “oh - my motor’s inverted, let me run Mxyz to straighten it out and save that to the config file with M500” was very powerful.
I honestly think we can probably make a PR to bring that to Klipper - but it’ll be more difficult to implement because of the multi-MCU system that Klipper supports. Or maybe not - the other major difficulty will be to get the Redeem users to convert their configs to a Klipper configuration.
The use of pin numbers in the config is something that Redeem did not have - and frankly, that was a good thing. Having users needing to find out which endstop or which stepper is controlled by which pin is, frankly, something inherited from the arduino… At least when it comes to a fixed hardware board like Replicape or Recore where there is no flexibility regarding pin selections.
I am not - not yet at least. I will open a PR, but ideally the Umikaze build project will provide a set of ansible scripts that will make sure to install the right kernel and service files all in one without needing to install anything else - the power of ansible is that you can easily make targets to pick & choose what you want to install as part of the whole slew of features available for installation.
The target was to get actual working klipper.pru and klipper.service scripts into the Klipper project. Best would be something that is kernel-type and version agnostic (should be that hard).
And updating the documentation there to show the essentials in uEnv.txt depending on kernel version (to get pru up and running).
Best would be to update the “install_ubunu_replicape” and “install_debian_replicape” scripts to work properly always.
Well, this is what I already said to you in slack. Getting the Klipper documentation and setup scripts into fully working mode for replicape will be (from my point of view) more beneficial than building an image.
If the above step is done the building of an image is a small step addon.
That’s a significant factor for me. I remember being confused by this Smoothieware thread:
I couldn’t understand how a feature successfully implemented on 16-bit Arduino was not possible to efficiently implement on 130Mhz smoothieboard running smoothieware, though it certainly makes sense that offloading to the slicer is a reasonable engineering choice of where to apply effort.
@Jon_Charnas I really like the idea of using scripts to set up an existing, separately-maintained image instead of building a custom image. It’s more flexible, and it’s aligned with what a lot of other projects do. Since BB is a smaller community than RPi by orders of magnitude, it seems like fitting in is valuable. And, it should be less work!
LOL. Pressue advance needs to be implemented by the FW since the extruder needs to match the movement in detail. Even more with special acceleration curves as in Klipper soon.
As you noted earlier, depending on which kernel version (4.4, 4.14 or 4.19) and variation (bone or ti) the way to access the PRUs becomes different.
This means I don’t expect to be able to provide a one-shot solution that works cross-kernels. Better to make the scripts enforce the known working version that we validate with.
Regarding the pin name aliases, I need to look at it in more detail. I’m still stuck in getting the proper uEnv.txt booting the image I build off my test BBBW.
