Bonjour J-Max,
Je pense que l'approche Klipper est féconde, pour plusieurs raisons :
1 - L'essentiel étant traité sur un ordinateur, les ressources informatiques, et donc les fonctionnalités, pourront augmenter indéfiniment, tout en gardant sur les machines des contrôleurs simples et pas chers.
2 - Le logiciel étant écrit principalement en Python, le firmware va cesser d'être une affaire de spécialiste. On pourra y mettre son grain de sel, et je suis sûr que de nouvelles choses seront inventées. On y récoltera au passage un peu de désordre dans les versions, sûrement, mais pas plus que pour Marlin...
3 - Klipper est très bien adapté à une architecture électronique décentralisée, avec un tout petit contrôleur pour chaque organe de la machine, comme le plateau chauffant, chaque Hot-End /extrudeur, et chaque moteur/endstop, le tout communiquant sans fil pour recevoir la liste d'événements à exécuter, et se synchroniser. Il n'y aurait plus de "carte pour imprimante 3D" qui fait tout, et impose sa personnalité et ses performances à la machine, mais des organes mécaniques ou thermiques "intelligents" et interchangeables. C'est d'ors et déjà possible, et ça ouvre des tas de possibilités...
4 - Ceux qui ont essayé affirment que l'amélioration de qualité est immédiate et flagrante. Klipper ne fait aucune approximation par segments linéaires lors du calcul des pas, et, comme sur ReprapFirmware, n'utilise pas l’algorithme de Bresenham. Les moteurs avanceront d'un micropas juste au moment exact où, selon la physique et en tenant compte des inerties, ils sont censé avancer pour suivre une trajectoire donnée, et peu importe la quantité de calculs nécessaires. Aucun petit contrôleur ne peut faire ça, surtout pour une Delta ou une autre cinématique compliquée. Même si les Firmwares actuels, à force d'évolutions, d'astuces et d'adaptations, donnent de bons résultats, c'est vrai, il y a néanmoins d'innombrables compromis inévitables, les trajectoires ne sont qu'approchées, et il y a des artefacts.
5 - Klipper prend en compte, sans compromis ni approximation, la viscosité et la non-linéarité de l'extrusion (Pressure Advance), comme les dernières versions de ReprapFirmware. D'autres le prétendent aussi, avec plus ou moins de succès, mais par une forme ou une autre d'astuce ou d'approximation.
6 - Enfin, en ce qui concerne le Raspi, il n'est utilisé que parce qu'il est commode, disponible à pas cher, et qu'il y en a souvent déjà un d'installé, à cause d'Octoprint. On pourrait aussi bien utiliser un ordinateur de bureau, un smartphone (?), ou une station de calcul. Une des implémentations les plus brillantes de Klipper utilise un BeagleBone, avec les PRUs en guise de contrôleur : là, ça dépote à 500 kHz sur tous les axes !
Mais de toute façon, le Raspi 3 est bien assez puissant : quatre coeurs avec unités de calcul en virgule flottante, plein de mémoire, que demande le peuple ? La cohabitation avec Octoprint ne pose aucun problème, à condition d'utiliser un Raspi 2 ou 3. Le Raspi Zéro n'est pas assez puissant. Il faut bien comprendre que les calculs de Klipper sont complètement désynchronisés des mouvement de la machine, et ont lieu bien avant ceux-ci. Les aléas de timing de l'OS n'ont donc aucune incidence : c'est bien là l'astuce !
Klipper n'en est qu'à ses débuts, mais déjà, à mon avis, peu de choses l'empêchent d'égaler ce qui se fait de mieux aujourd'hui, selon moi, à savoir ReprapFirmware sur une carte DuetWiFi en 24V. (€€€€€ !)
Il nous faudrait une carte genre RAMPS/DUE , mais fiable, et en 24V, équipée de drivers de moteur genre Pololu, mais avec courant réglable par logiciel.
https://hackaday.com/2017/12/26/fast-3d-printing-with-raspberry-pi-but-not-how-you-think/
P.S. Je viens de lire sur le forum de Klipper qu'une carte clone de Smoothieboard a été adaptée pour fonctionner comme simple exécuteur en aval de Klipper, en oubliant Smoothieware. Par rapport à une RAMPS/arduino, on y gagne en fréquence de pas maximale (300 kHz au moins). Ces cartes ne sont pas très chères, et acceptent 24V.