pijalu

Juste pour information Hier, Anycubic a suivi la tendance et a ouvert le code de son firmware, incluant un même port de Klippy en Go (). J’ai signalé l’absence du toolchain ARM et ils l’ont ajouté en moins d’une heure. J’ai effectué un mini-fix et soumis un pull request qui a été mergé. Ils sont attentifs — ce n’est pas un simple dump de sources. Le code est propre et on sent de l’implication. Point négatif : c’est une grosse piqûre de rappel. J’ai donc décidé de donner un ultimatum à Caleb / Artillery. Depuis des mois, on me répond « on regarde / on y travaille »… suivi y compris de blocages sur Fluidd. Après des mois de promesses, ils m’ont envoyé un dépôt GitHub censé être « les sources de Klipper » qui ne contient même pas tout les fichiers binaires de l’imprimante (certain bien...) et ne correspond donc à rien de fonctionnel — je n’ai même pas osé partager ça - ma version de Klipper est de loin plus à jour. Je suis fatigué : Ils ont introduit de l’obfuscation dans le firmware, y compris après certaines de mes remarques — de manière maladroite, mais l’intention est là. Ils n’ont pas le contrôle sur le software: le firmware et la solution OTA sont gérés par MKS (Makerbase). Artillery / YunTu n’a apparemment aucune maîtrise sur ce travail — ce qui explique qu’un firmware aussi mauvais n’ait pas été corrigé après plus d’un mois. J’ai reçu des versions contradictoires entre le support et Caleb : « On va ouvrir » / « C’est propriétaire ». La sécurité de l’imprimante est douteuse, tant sur le plan logiciel que matériel — même certains concepteurs originaux ont laissé des commentaires inquiétants sur les risques, en s’exonérant des conséquences potentielles. (en chinois) Même le simple fait de pouvoir reflasher le firmware vers 1.0.10.00 m’a demandé des jours de discussions avec eux. Sans accès clair et complet aux sources, il est insensé de continuer. J’arrêterai donc mes activités sur la M1 demain si je n’obtiens pas une réponse claire. Je préfère consacrer mon temps libre à autre chose plutôt qu’à chercher des solutions de contournement et me faire balader...

en effet Je pars d'un lit livré avec 1.8 (lol) - après une session manuelle: 0.8 En retirant les "bloques": 0.44 Mais le lit est un lointain: Le centre a un soucis qu'il est impossible de "sauver": Pour être complet: je fais le level à la main sur les 4 coins avec stepper Z off/on (pour centre et off sur XY pour déplacer la tête) vu le creux

Salut à tous Je suis un des guguses qui bricole sur la M1 / le patcher (et qui doit avoir passer 50h d'impression de tests et 10x plus à insulter l'imprimante dans le garage) Car je pense qu'il est intéressant que je partage aussi ici quelques infos techniques (en vrac) : - Un des problèmes de la M1 est que la sonde subit pas mal de perturbations induites par les éléments de chauffage (Artillery avait mis ce problème sur le dos du ventillo) . En chauffe, la sonde peut se mettre à faire des erreurs (de plus de 0.5mm). La probabilité d'avoir le sondage avec le lit en chauffe n'est pas constante, ce qui signifie qu'une imprimante qui est parfaitement paramétrée peut subitement se retrouver avec un z-off incorrect subitement (plus la température du lit est importante, plus la probabilité d'erreurs va augmenter). - Une partie du code d'Artillery tente de valider les écarts (paramétré à 0.02) pour faire un "reset" de la probe à tout les étages. Ceci peut même entraîner un nombre infini de probing dans certains cas très particulier (ex: Buse sale et lectures qui ne convergent pas - la limite de 10 probes n’étant pas prise en compte dans tous les cas). - Le problème existe non seulement pour le meshing mais également pour le Z homing (fait via probe...) - Pour le meshing, il sera moins visible ou donnera des problèmes de 1er couche sur certaines parties du lit mais si le problème se situe lors du Z homing... l'offset Z sera plus important/moins important que prévu et ce sera "la cata, la cataaa, la catastrophe !" - Artillery a aussi changé le code Klippy du homing et c'est intéressant: Ils font 2 probes pour définir si la sonde est fonctionnelle (pas d’écarts de plus de 0.02mm)... et font un 3ème sondage sans validation pour donner le point 0 (aka : le homing Z est très risqué) Une partie des corrections communautaires tente de solutionner ces soucis : * Les sondages (mesh et G28 Z) se font maintenant en coupant les chauffages de buses et du lit - ceci devrait limiter les erreurs de mesures aléatoires * Le code Klippy de homing est changé pour utiliser la dernière mesure validée pour définir le point 0 - ceci devrait limiter les erreurs de homing Z (point amusant - c’était un todo en chinois...) En outre - les macros ont été révisées en partie (on a des limites sur ce que l'on peut changer sans casser les fonctions de l'écran) et prennent en compte les températures de lit et filaments - Moonraker/Fluidd sont mis à jour (avec les changements faits par Artillery) et permettent de supporter les choix utilisateur (bed mesh, shaper,...) y compris via Orca. Nota: Pour le Z-off - il est important de le configurer via FLUIDD et non pas via le LCD : Le LCD fait un mélange de set_gcode_offset et changement de configuration du probe offset. Vu que nous savons et restaurons le set_gcode_offset, l'usage du LCD double ce paramètre... et nous ne savons pas changer cette partie du firmware. Il est important après l'installation de mettre à jour le gcode de l'imprimante car les changements sont majeur: https://github.com/pijalu/artillery-m1-klipper/blob/main/INSTALL.md Pour les curieux et ceux qui veulent participer - tout est dispo dans des repo github: - https://github.com/pijalu/artillery-m1-klipper/ : Les configurations Klipper et macros extra - https://github.com/pijalu/artillery-m1-klipper-code/tree/artillery-m1-fixes : Code Klipper utiliser par Artillery comme base, avec une partie des changements Artillery qui ont su être récupéré (Pas de code C - donc seul les modules klippy et les pyc decompiler - quelque composants ont ete compiler en module binaire via cython et donc.. perdu) - https://github.com/pijalu/artillery-m1-moonraker/tree/feature/diy-macros : Moonraker à jour, avec les changements Artillery porté et les fixes communautaires (pour permettre la prise en compte de parametres de temperature lit/filaments) - https://github.com/pijalu/artillery-m1-orca : Les profils communautaires pour la M1 - https://github.com/pijalu/printer-patcher : L'outil multiplate-forme de patching, un "GUI" qui est capable d’exécuter des commandes via SSH sans que l'utilisateur ne doivent faire des tours de magie. Il n'est pas conçu spécifiquement pour la M1, tout se passe via config/actions.yaml et les scripts placé dans scripts. Les scripts sont exécuté en headless (pas d'output/pas input - seul les outils de diagnostique donne des sorties écrans en temps réel) Je suis assez vocal chez Artillery (faite de même svp) - J'ai documenté tout les fixes et je partages toutes les informations/repo, tout en rappelant l'importance de l'opensource... Ils me disent être occupé sur le point. Un détail important: Ils font appel a des compagnies externes (qu'ils ne veulent pas citer - makerbase au moins en partie) donc a prendre avec des pincettes...