Qidi X Max 3 - Probleme de shutdown de Klipper

[fran6p]

Le problème avec les outils de Sineos, en tout cas pour moi, est que je n'arrive pas à lire les fonds blancs (mes yeux ont pourtant bien été «réparés» (cataracte) et nouvelles lunettes adaptées à ma nouvelle vision). Quand j'active une extension Firefox (Dark background & light text) pour passer en mode sombre, les graphiques deviennent illisibles (plus d'échelles ni de texte) .

[V3DP]

@fran6p C'est vrai que ses graphiques sont très instructifs, mais difficiles à lire. Les axes et les échelles sont trop fins.

Je viens de relancer la machine avec le job client de 17h, mais en ayant joué sur le paramètre résolution d'Orca

 

Pour une impression en 300 microns, ca devrait passer.

Ce qui a réduit mon fichier de 3 Mo, mais surtout le nombre d'instructions pour les périmètres est passé pour la première couche de 80 à 49. Donc moins de segments dans les arrondis.

J'ai gardé le service MCU Host démarré.

On va voir si ça marche.

Dans Qidi Slicer et Qidi Studio, le paramètre est à 0.012 mm. Perso je préfère la méthode de Cura avec la longueur max d'un segment et la déviation.

[V3DP]

Bonne nouvelle ! Mon job s'est terminée après 17h d'impression. Bon il y a eu une heure de pause pour une fausse alerte du capteur de filament, mais je ne pense pas que ça ait eu un impact.

L'analyse des logs d'hier soir et d'aujourd'hui montre que jusqu'à 30% de la bande passante du MCU est utilisée en début de job (grosse pièce de 370 * 270 * 75) et qu'en fin de job ça diminue du fait qu'il ne reste que 2 ilots à chaque bout. Ce qui est intéressant, c'est que la charge du MCU est plus importante en idle que lors de l'impression.

 

Tout porte à croire que le souci est directement lié aux paramtétrages du slicer qui saturent les MCU : moteur d'extrusion Arachnee, résolution du slicing principalement.

Je vais faire attention sur les prochaines grosses pièces aux paramétrages, car je n'ai pas constaté le problème sur les petites pièces.

Je m'interroge sur le paramètre résolution mis par Qidi à 0,0125 pour des impression de grande taille ou de hauteur de couche importante.

 

[fran6p]

 

[pjtlivjy]

salut @V3DP alors j'ai imprimé des pièces dans ces volumes et dans ces durées, je n'ai jamais eu ce problème par contre je n'imprimer jamais en 0.3 mm de hauteur de couche.

[V3DP]

Il y a 1 heure, pjtlivjy a dit :

alors j'ai imprimé des pièces dans ces volumes et dans ces durées, je n'ai jamais eu ce problème par contre je n'imprimer jamais en 0.3 mm de hauteur de couche.

@pjtlivjy Merci du retour. J'ai eu le souci aussi avec des pièces bien plus petites, en 100 microns de hauteur de couche, mais avec des arrondis de partout.

Est-ce que tu utilisais Qidi Slicer ou Qidi Studio avec les paramètres par défaut pour la résolution (celui que j'ai mis à 0,05 au lieu de 0,012) et le moteur de slicing classic ?

Ca m'intéresse si tu as la possibilité de retrouver tes fichiers d'impression.

[pjtlivjy]

alors j'utilise maintenant exclusivement Qidi studio maintenant @V3DP avec les paramètres par défaut dont le fameux 0.012 et j'utilise le moteur classic.

quand tu dis les les fichiers d'impressions, que veux tu dire ? mes imprimantes sont toutes sous le système d'origine.

[V3DP]

il y a 12 minutes, pjtlivjy a dit :

quand tu dis les les fichiers d'impressions, que veux tu dire

Je parlais des projets au format .3mf. Il y a toutes les infos.

Mais comme tu as répondu à ma question, à savoir que tu utilises les paramètres par défaut de Qidi Studio (et j'imagine de Qidi Slicer avant), pas de soucis.

Mon raisonnement actuel, vu les 2 machines, quelque soit leur age / utilisation me font le problème de shutdown pour une erreur "Timer too close" soit sur la tête, soit sur la MCU de la carte, que remplacer / nettoyer la connectique ne change rient, c'est que c'est lié aux paramétrages utilisés dans le slicer.

Et que j'utilise Orca, avec majoritairement le moteur Arachnee, une résolution d'impression de 0.012 sur des pièces pleines de congés et relativement volumineuses / longues à imprimer quand ça plante.

Je vais continuer à tourner avec les paramètres "standard" mais une résolution plutôt de 0.05 sur les grosses pièces pour voir si ça se confirme que c'est ça.

Et si c'est bon, je reviendrais à 32 micro pas interpolés pour diminuer le bruit et augmenter un peu la précision.

[V3DP]

Je viens de voir dans le GitHub de Phil1988 sur les changements de FreeDi 2.0 la chose suivante

In FreeDi v2.00 the mainbaord MCU baudrate changed from 250000 to 500000 to prevent "timer to close" errors.
This is a rare problem, but users of beacon/carto might need it.

Comme il est basé sur Armbian 25 et Klipper 0.13 comme mes X Max 3 Libérées, il y a peut-être une piste à creuser.

A priori la compilation du firmware du MCU a été faite avec une communication de 500000 bauds et le printer.cfg est modifié en conséquence

For X3 series users (X-Smart3, X-Plus3, X-Max3)

I recommend using the provided X_4.bin from ~/FreeDi/mainboard_and_toolhead_firmwares/v0.13.0-154/.
Its a compiled klipper version for the mainboard MCU with 500000 baud rate instread 250000.
This speeds up the communication and can help "timer too close" errors especially for some beacon/carto users.
You then have to change the printer.cfg section accordingly to:

[mcu]
serial: /dev/ttyS0
restart_method: command
baud: 500000

[souriceaux]

@V3DP, je peux si cela t’intéresse te faire suivre ce fameux câble en provenance de la Xplus3 que j'ai acheté pour pièces.

 

[V3DP]

il y a 24 minutes, souriceaux a dit :

, je peux si cela t’intéresse te faire suivre ce fameux câble en provenance de la Xplus3 que j'ai acheté pour pièces.

Merci, mais j'ai reçu deux cables USB C de remplacement en fin de semaine dernière de Qidi EU.

[V3DP]

Je viens de regarder les spécifications du STM32F401 (le STM32F402 étant la version chinoise) la communication série en USART1 (ce qui est le cas de nos Qidi) est données jusqu'à 10,5 Mbit/s suivant le mode. Donc le passage à 500000 bit/s de la vitesse de l'interface série de communication avec le Rockship ne devrait pas poser de problèmes.

De son coté le Rockchip 3328 a un contrôleur UART qui supporte jusqu'à 8bit en transmission avec un débit de 1500000 bit/s 

Reste à voir si ça fonctionne en reflashant le mcu après avoir compilé avec un débit pour le port série à 500000.

[fran6p]

il y a 12 minutes, V3DP a dit :

Reste à voir si ça fonctionne en reflashant le mcu après avoir compilé avec un débit pour le port série à 500000.

La recompilation puis le flashage est obligatoire pour être prise en compte (et en ajoutant le débit dans la section [mcu]).

À tester, sous réserve que cela règle le problème et n'en crée pas d'autres… (j'ai analysé pas mal de configurations et consulter le site de référence (le discourse de Klipper) et rarement vu cette modification, mais si M. Freedi le dit alors).

Tu testes et reviens nous dire quoi 

 

[V3DP]

il y a 54 minutes, fran6p a dit :

À tester, sous réserve que cela règle le problème et n'en crée pas d'autres… (j'ai analysé pas mal de configurations et consulter le site de référence (le discourse de Klipper) et rarement vu cette modification, mais si M. Freedi le dit alors).

Oui, c'est bien là le souci. C'est pour cela que je suis prudent.

Bon flasher dans un sens puis dans l'autre la carte mère c'est simple et rapide une fois qu'on a retiré le capot.

Par contre voir les effets indésirables, c'est plus compliqué. Et pour l'instant personne n'a dit que cette manip était "Sure et efficace".

Je vais essayer sur une machine cet après midi. Par contre, pour avoir des résultats, ça risque d'être plus long.

[fran6p]

Pour l'USB, je ne sais pas vraiment (Klipper fixe par défaut la vitesse à 250000, raison pour laquelle on peut ne pas la spécifier dans une section [mcu]).

Pour un bus CAN, la fréquence du bus, par défaut, est de 1000000 (bitrate), mais un bus CAN est mieux protégé des perturbations (en théorie évidemment).

 

[V3DP]

Il y a 1 heure, fran6p a dit :

our l'USB, je ne sais pas vraiment (Klipper fixe par défaut la vitesse à 250000, raison pour laquelle on peut ne pas la spécifier dans une section [mcu]).

En l'occurence ce qui est modifié, c'est la vitesse de l'interface série UART entre le STM32 et le RK3328. Normalement ca ne devrait pas changer la vitesse de l'USB vers la carte MKS_THR.

[fran6p]

C'est «marrant». Ayant accès au fichier printer.cfg de la Anycubic Kobra S1, les deux «mcu» utilisent une vitesse de transfert de 576000 . Et depuis que j'imprime avec, pas rencontré de «timer too close» (d'autres soucis, mais pas celui-là) :

Citation

[mcu]

serial : /dev/ttyS3

restart_method : command

baud : 576000

fw_max_size: 40960

fw_sector_size: 2048

fw_ota_sector_offset: 20

 

[mcu nozzle_mcu]

serial : /dev/ttyS5

restart_method : command

baud : 576000

fw_max_size: 40960

fw_sector_size: 2048

fw_ota_sector_offset: 20

Donc après recompilation du firmware puis flashage de la carte (X_4.bin) ça devrait fonctionner.

Modifié (le) il y a 3 heures par fran6p

[V3DP]

Je viens de re-flasher toutes les MCU en version 0.13.154 avec le baud rate à 500000. Tout redémarre correctement avec la modification du printer.cfg pour indiquer la vitesse de communication. (Au passage j'ai essayé de réimplémenter Katapult, mais c'est la Katastrophe. Impossible à flasher Kata..... donc retour à la méthode directe).

Je vais préparer un petit job pour voir ce que ça donne.

[fran6p]

il y a 25 minutes, V3DP a dit :

j'ai essayé de réimplémenter Katapult, mais c'est la Katastrophe. Impossible à flasher Kata.....

J'ai dû avoir beaucoup de chance quand je l'ai eu fait. Mon Klipper étant aussi en version 0.13.x, je vais probablement essayer de reflasher les MCUs pour mettre à jour les firmwares encore en version 0.12.x. Ça attendra un peu, car il faut 1) que je redémarre la KS1 (lit chauffant défaillant finalement remplacé par Geekbuying, Anycubic ne voulant plus prendre en charge mon modèle ) et 2) faire (volontiers) un peu de dépannage pour @souriceaux qui a finalement réussi à redémarrer sa X-Plus3.

 

Modifié (le) il y a 2 heures par fran6p