pijalu

Ah oui, ca, c'est définitivement à changer Attention tu as cela dans la partie extruder machine ET filament. (Dans mon cas, la rétractation semble ok avec tant le PLA que le PETG. Y'a moyen d'être plus bas mais n'ayant pas de soucis, je touche pas) Nota: les profils ont des aussi des flow/max flow un chouïa WTF, donc a vérifier tant qu'à faire.

hmm, perso je suis assez standard me semble (sur la version community) et pas de soucis particulier

çà c'est purement un effet placebo - aucun changement si ce n'est le choix de faire maintenant monter la chambre à 50 degré, comme ça, quand il va purge Y'a aussi la détection AI qui semble etre mise on par défault: mais le modèle reste le même et déclaré par Artillery comme immature... suite a trop de faux positifs... Bon, il reste possible que le LCD fasse encore une dégueulasserie pour mitiger les erreurs du modèles (Source: J'ai une certaine habitude de packaging Artillery...) Dans mon cas - je reste sur la 1.0.11.0 et je conseille a toute personne de rester au max sur 1.0.12.0 Cette release est au plus preparatoire à leur AMS mais ne fixe aucun des problèmes fondamentaux sur la gestion des filaments et en introduit d'autres. Comme dit pas le support: L'imprimante est calibrée pour le filament a basse temperature: PLA... Fun stuff: Je suis me semble censuré sur le FB officiel (au moins en partie), fo dire, j'avais mis en évidence que leur impression démo avait un léger soucis d'adherence... Vu qu'ils demandent à certain 40 euro pour envoyer des pièces de rechange sous garantie, j'imagine le kit d'uprade à 500 boulles... Mais tu reçois une Bambu avec un sticker Artillery3D... Et tant qu'a faire, car c'est peut-etre la source de la mauvaise information sur l'algo du lit: il y a une version 2.x et un update de nom: Artillery M1 Pro S1: https://wiki.artillery3d.com/m1/maintenance/m1-pro-s1-optimized-ap-board-algorithm-software-installation-tutorial-guide

C'est presque la même release (et donc purement fix pour le multi-material) - seul changement: le soft LCD semble avoir été recompil...

quand j'ai eu des soucis de shifts, j'avais aussi du envoyer un STL... j'avais pas fait attention et c’était pas le bon... (manquais les supports... autant dire que c’était une fabrique à Barilla) et zon pas réagit ... enfin... zon jamais réagit... J'aime beaucoup le point "c'est les supports de Satan" De mon coté j'ai du bol: ils discutent pas - là j'ai demander un ressort pour l'extrudeur, ils m'ont envoyer un extruder complet (sans la carte THR que j'ai déjà du faire remplacer car dessoudée) Mais bon, cette imprimante restent hantée La M1, si j'ai pas calibré au couteau, elle t'explose à la gueule... la j'ai un joli filament PLA mate rose qui a juste pas envie, mais sort sans le moindre chipotage sur ma Anycubic K1s en mode "PLA-j'ai-pris-les-defaults" J'ose même pas imaginer avec les "Bouffe à Panda"

Et Artillery a retirer la version 1.0.12.07 - on est a nouveau en 1.0.12.00...

Pour le fun: Nouveau firmware - 1.0.12.07 Tout les changements semblent lié à leur AMS - aucun fixes sur les problèmes de calibrages, de mesh ou consort... Donc attention - je sens bien que l'on va avoir pire que la M1 Pro: la M1 Pro avec un module multi-couleur /hâte

mais où est le fun et le goût du risque /sarcasm

intéressant - j'ai snif la machine OTA et rien dessus. Les RN semblent me dire que c'est un nouveau bricolage dans le client LCD, qui est déja une infamie - eg: un morceau du start print... qui contient en hardcode une serie de gcode, qui ne valide rien et fait des sleeps... aka: Faire un truc propre avec des macros c'est trop demander... je me demande parfois comment cette imprimante est capable de booter... Et tant qu'a faire, pour les curieux (et vu que je ne pense pas que Artillery regarde ce forum): il existe 2 versions du firmware: - La générale: http://studio.ota.artillery3d.com:9190/home/downloadnewest?customerType=Yuntu_m1&firmwareType=Yuntu_m1_client_deb - La version debug de MKS: http://studio.ota.artillery3d.com:9190/home/downloadnewest?customerType=Yuntu_m1&firmwareType=Yuntu_m1_test L'access à la version de test se fait via la création d'un fichier sur l'imprimante: /home/mks/printer_data/gcodes/DEBUG_MKS.txt à l'heure actuelle: pas de changement entre les deux

Hmm Le service d'update OTA me dit que l'on est tjs en 1.00.12.00 - cf http://studio.ota.artillery3d.com:9190/home/downloadnewest?customerType=Yuntu_m1&firmwareType=Yuntu_m1_client_deb

Pour être honnête avec toi, pour l'instant je n'ai jamais eu à vraiment déboucher le hotend - bon j'imprime seulement avec le PLA fournit et les PETG les moins cher d'amazon... points important: - Je tourne (évidement) sur la version community - J'ai fix les profiles via calib temp tower, retract, flow et max flow - eg: PETG (tecbear): 0.97 flow, 0.63 PA, 240 hot, 85 1st/80 bed, volu 20mm3/s, no cool: 3 layer, part cooling min: 20% - 30s, max: 80% - 12, aux fan: 0% - rien custom pour l'extruder (0.4 pour la retract - 40mms), zhop on all surfaces - pour les motions, faire la calib et prendre les valeurs donnée. ATTENTION: la tension se dégrade avec l'usage très très vite, c'est une merde à tensionneur et les vises sont trop tendre... donc la, pour l'instant, je suis tomber a 3500 (j'étais a 8k) mais j'ai pas le nerf de refaire la tension tant que je shift pas - Je fait la charge à la main avec le LCD: Je home, hotend a 250, je coupe en biseau le filament, quand le hotend est a temperature, j'utilise le tab mouvement, je charge dans le tube et je fais une extrusion et je regarde tout en poussant un peu le filament, et quand c'est bon, je change la temperature à zero. - J'ai eu des fuites d'extruder entre la tête et le bloque de chauffe, uniquement avec du PETG (tiens donc) et seulement du suitage... la chaussette se durci et tu te retrouve avec de l’adhésion sur les bords... et donc... blob... et donc.... layer shifts. Mise a 250 et reserage (of course, c'est pas une tete hexa...) - fait gaffe a pas peter le bloque de chauffe, le senseur ou péter la tête dans le bloque de chauffe) - Si tu démontes l'extrudeur - vérifie bien son alignement car il est très facile de le mettre mal.... donc mettre un filament (droit) dans l'extruder jusqu'au hotend pour valider l'alignement avant serrage Pour le reste - je suis à 0.13 z-off "fluidd", 0 dans la config probe - je clean mon plateau eaux chaude et produit de vaisselle à chaque impression - je brime toute piece qui me fait douter (parfois Orca est bcp trop optimiste) et ça va. J'ai aussi une collection de colle uhu (version Action - Bison) au cas ou, mais pour l'instant, pas nécessaire

Pour le marché chinois, un recours francais peut avoir un effet. Et même si basé en chine, bloqué les moyens de paiement reste tout à fait possible. Sans PayPal et autre agence de paiement, la survie est complexe. (C'est une des méthodes qui ont été employés pour fermer des Fileshares) Nota: de même que le retrait de la certification CE, qui résultent dans la saisie et destruction. Bon, j'ai un côté procédurier et j'ai peut-être l'avantage de vivre avec une juriste qui me donne une vision que le législateur a une force que l'on oublie car elle nécessite une certaine paperasse. Ici je vois un coût de port absolument ahurissant, et pas la notion de frais de douane donc j'ai franchement l'impression que le support prend notre ami pour un pigeon. (Ils ont essayé avec moi mais après mise en demeure ils ont été plus constructif...)

En Belgique, c'est purement et simplement interdit - En France, également, avec une finesse, qui pour moi est dans le cadre de l'envoi fait par le consommateur: https://www.economie.gouv.fr/particuliers/mes-droits-conso/bien-consommer/tout-savoir-sur-la-garantie-legale-de-conformite# "Aucun frais ne peut vous être demandé pour le remplacement, la réparation, la résolution ou la réfaction du contrat, hormis des frais d’envoi postal qui doivent vous être remboursés dans un délai de 14 jours. Demandes maintenant le remboursement de ces frais - en cas contraire, ouvre un litige et rappel: l'action de groupe est possible - ce qui rend les choses nettement plus accessible. Je pense que de nombreux utilisateurs (français) sont mécontent...

Pour le PETG, attention si tu utilises les profils Artillery qui sont pas bien-dans-leur-tete... et si c'est avec une machine non-tweak - c'est un suicide Perso, j'ai un coté sado-maso qui fait de moi un amoureux du PETG et si tu rajoutes que j'avais eu des mails du support d'Artillery qui m'expliquais que le firmware n'est pas apte a l'imprimé tu va comprendre que je n'imprime plus que cela. Nota: j'ai eu des soucis avec le hotend qui fuitais et donc des blobs et souvent des layers shift... mais après un bon serrage à température, le hotend ne coule plus et plus de layershift à la con. Point sympa: la M1 monte sans soucis à (et sans doute au delà) 20mm3/s (test Orca max flow qui est passé comme une lettre à la poste) Pour le plateau - dans mon cas, ils ont envoyé le truc gratos car la mise à la terre était incorrect... et résultait dans du courant fantôme pas sympa lorsque le lit chauffait : J’espère que quand tu dis 40euro de port c'est une blague... j'ai acheter des pièces de rechange (je me prépare pour tenter un jour le TPU 85a, qui semble être un boss de l'escape room M1) et le port étais gratos:

En theorie oui - mais tu peux tjs contacter leur support... qui sait tu auras peut-être de la chance

Sur la version "community" - z-off a 0.13 (probe=0) PETG: - Max flowrate: j'arrive sans soucis a 20mm3/s (faire le test Orca ) - flow ratio: YOLO et dans les 0.97 (! totalement faux dans les anciens profil Artillery) - retract: retractation test, dans les 0.4 (! totalement faux dans les anciens profil Artillery) - Cooling: Plus global - Min fan: 20%/30s - Max fan: 80%/12s - Aux Fan: 0% (OFF !!!)

Pas le 1er a avoir eu le soucis.... Tu peux tenter un ticket chez support pour obtenir une nouvelle poop-chute et tenter de la remettre droite. Vérifie aussi l’état de ton hotend - il est probable que la buse soit deviser et ce retrouve plus basse que normal - ce qui va ruiner tes impressions et aussi... plier le scraper Courage.... il faut considéré la M1 comme une imprimante escape-room: le plaisir est d'arriver a sortir un truc

Car j'ai un coté autistique "Sheldon" et l'IA est un péché mignon: On parle ici d'une IA de classification Par default, l'AI n'apprend pas - l'app vient avec ses poids et ne les changera pas - vu qu'un training est assez lourd. Et c'est tout le problème: tu as besoin d'avoir des informations classifiés, de qualité, pour "apprendre" et faire du training (/fine-tune) mais il n'y a pas, a ma connaissance, d’envoi des images vers Artillery ni de question "Spag/Pas Spag". Pour avoir un outil plus malin tu devrais avoir: - Avoir un opt-in pour dire que tu veux "participer" a l’amélioration (tu acceptes de partager) - Lors d'une détection - confirmer/infirmer le cas - a ce moment, une image (ou video) devrait être envoyer avec le label (c'est bien des spag, c'est pas des spag) - Un training(=fine-tune vu que l'on ne part pas de zéro) devrait être relancer avec un ratio "training" / "validation" des nouvelles images (on ne valide pas sur des images utilisée pour le training) + "validation" des anciennes pour définir si le modèle régresse ou non (bien que la régression n'est pas obligatoirement un problème) Dans le cadre de Obico,les details de Obico: https://www.obico.io/blog/2019/08/14/3d-printing-deep-learning-training/ J'ai pas regarder tres loin mais je ne pense pas que le code (actuel) fasse du fine-tuning automatiquement - cela reste possible car les poids sont disponible mais cela demande un peu de travail: https://gitlab.rylanswebsite.com/rylan-meilutis/obico-server/-/blob/zzh/docs/model_training.md Et encore une fois, voila pourquoi je regrette que nos amis d'Artillery ne "pige" pas l’intérêt d'avoir une communauté active - ce genre de truc leurs permettrait d'etre nettement plus efficace que d'outsourcer chez Makerbase et avoir des cochonneries comme résultat... (eg: Le nouveau LCD, il contient pas mal de macro hardcoded... qu'il lance au fur et a mesure... même pas un template ou autre... tu dois changer les 200Mb de l'executable...)

et on a déjà la confirmation officielle: Artillery conseille de désactiver l'AI qui ne marche pas Et pour l'instant - pas de chemin pour passer vers 1.0.11.0 de 1.0.12.0... Si j'avais les nerfs, je ferais une image de mon imprimante mais la... bof

En vitesse car j’étais curieux: Pas de changement dans les config/macro klipper - qui sont pourtant les plus critiques... Le client LCD semble être au moins recompil...

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...