Discussions sur la Qidi Q2

[JoOj]

Il y a 5 heures, tranbert a dit :

- En impression fermée sans chauffage de l'enceinte, ce qui est le plus audible ce sont les accélérations et les basses que ça génère. Et aussi si on fait du remplissage avec croisement, ça fait un peu tout trembler. Mais c'est tout à fait supportable, faudrait mettre des pieds isolants que certains vont sûrement nous calculer...

Sur ce point en particulier : plafonne les accélérations à 6000 mm/s2 et tu devrais supprimer le plus gros du bruit pour une perte de temps plutôt raisonnable (autour de 15% de temps d'impression en plus)

 

Il y a 5 heures, tranbert a dit :

Je peux faire des enregistrements si j'ai le temps entre deux tests de "oh tu peux me faire une pièce pour la boite à chats qui ferme plus steuplè ?"

 

Te tracasses pas : ca m'intéresse mais je ne suis pas encore à en acheter une nouvelle, donc 0 urgence

[tranbert]

il y a 9 minutes, JoOj a dit :

plafonne les accélérations à 6000 mm/s2

Je vais tester ça, merci.

[V3DP]

il y a une heure, tranbert a dit :

Je vais tester ça, merci.

Une autre solution est d'augmenter les micro pas des moteurs X et Y à 32 micro pas interpolés si ils sont à 16. à changer dans les rubriques du printer.cfg. Ca réduit le bruit sans dégrader les performances.

A voir si le contrôleur tient la charge sur la durée, car la modificaiton va augmenter un petit peu la charge du MCU. Sur les X Max 3 ça ne pose pas de problèmes.

[tranbert]

il y a 44 minutes, V3DP a dit :

augmenter les micro pas des moteurs X et Y à 32 micro pas interpolés si ils sont à 16.

Ha oui ça se tente aussi... Merci !

 

[V3DP]

@tranbert En me relisant, je me suis aperçu qu'il y avait une mauvaise interprétation possible.

Il faut garder l'interpolation sur les 2 moteurs et passer le nombre de micro pas de 16 à 32.

[fran6p]

Il y a 15 heures, JoOj a dit :

plafonne les accélérations à 6000 mm/s2

Plutôt que plafonner arbitrairement l'accélération, je me base sur les données issues des tests de compensation de résonances.

Ayant installé, Shake and Tune, les graphiques indiquent pour chaque modèle de mise en forme, les accélérations maximales utilisées. Ensuite dans la section [printer] du fichier printer.cfg, il suffit de modifier la valeur de max_accel.

Avec le Klipper de Qidi, basé sur une version standard de Klipper, il n'est pas possible, contrairement à Kalico, de différencier les accélérations par axe. Cela oblige donc à utiliser la valeur la plus petite de l'accélération maximale d'un axe (la plupart du temps, c'est le Y qui limite). 

Actuellement sur ma Q2 :

[printer]
kinematics:corexy
max_velocity: 600
max_accel: 6400
max_z_velocity: 20
max_z_accel: 500
square_corner_velocity: 8
…
#*# [input_shaper]
#*# shaper_type_x = zv
#*# shaper_freq_x = 52.0
#*# shaper_type_y = mzv
#*# shaper_freq_y = 46.8

 

 

[JoOj]

J'adore ! Merci !

[tranbert]

pour info klipper extrait de la q2 a ce que jai compris  

 

https://github.com/53Aries/Q2-Klipper

[tranbert]

Il y a 23 heures, fran6p a dit :

Ayant installé, Shake and Tune

Si tu as le temps, car n'oublions pas qu'un article est en travaux : Est-ce que ceci est utilisable ?

Klipper Shake&Tune plugin for Qidi Plus 4  https://github.com/stew675/klippain-shaketune-for-qidi-plus4 

A priori selon le discord Q2 ça l'est. Pas encore testé.

Là J'essaye le script [screws_tilt_adjust] pour le réglage assisté des vis du plateau, ça aide bien en fait ce petit truc.

J'imagine que mieux le plateau est calé manuellement, moins le système va travailler pour compenser les défauts, ce qui est toujours du temps gagné et des vibrations en moins. En tout cas, on peut tester pour voir.

Ha et j'ai dû re-graisser les vis Z, j'avais un grincement super aigu vers le haut à droite. Trop de travail pour la pauvre bête 

 

 

il y a une heure, tranbert a dit :

ça aide bien en fait ce petit truc.

 

[fran6p]

Il y a 2 heures, tranbert a dit :

j'ai dû re-graisser les vis Z,

Elles n'étaient pas recouvertes de graisse en sortie de carton  ?

Il y a 3 heures, tranbert a dit :

Est-ce que ceci est utilisable ?

Pour Shake and Tune, je n'ai eu aucun besoin de passer par une version modifiée pour la Plus4 (j'avais d'ailleurs décrit la procédure sur le Discord, mais visiblement, d'autres plus «savants» tiennent à utiliser le S&T modifié pour la +4. Why ? Ont-ils testé la procédure standard ? Croyances magiques ? Autre ?

Je m'étonne d'ailleurs qu'ils aient réussi à faire une mise à jour (a minima nécessaire car git n'est pas installé d'origine sur l'OS de Qidi) sans réaliser de modifications dans les sources de dépôts Debian. Depuis la sortie de la version Trixie (v13), la Bullseye (v10) est passée en status «oldoldstable» et donc n'est plus atteignable autrement que par les archives Debian .

 

[tranbert]

Il y a 2 heures, fran6p a dit :

Elles n'étaient pas recouvertes de graisse en sortie de carton  ?

Ha sisi, mais visiblement ça leur a fait du bien, elles se tiennent calmes...

 

Il y a 2 heures, fran6p a dit :

Croyances magiques ? Autre ?

C'est ce qui me fait un peu peur sur ce discord, chacun (et moi aussi je sais)  y va de sa recette et applique un truc qui n'est peut-être pas optimisé. Et la modifie, car une recette, ça se modifie toujours, "Très bon ton risotto, j'ai remplacé le riz par des bananes et mes petits ont adoré"

Ça démontre aussi la pauvreté des "manuels" de Qidi qui n'explique pas vraiment comment se servir "pour de vrai" de leurs produits. Alors ok, pas du Prusa, mais un juste milieu peut être.

 

Modifié (le) Septembre 9 par tranbert

[fran6p]

Mon seul conseil, actuellement, est de ne pas utiliser la détection IA (désactiver toutes les options via l'écran). Comme le processus d'analyse «en temps réel» est fait localement de manière logicielle, le processeur Rockchip RK3308B-S est saturé, la mémoire vive (512 Mo) est surchargée (il suffit de regarder dans Fluidd l'utilisation du système).

Cela, avant que je désactive l'IA, m'a provoqué plusieurs échecs sur des impressions longues (PETG-GF, ABS)  que je n'ai plus rencontré depuis cette modification. À voir, si ce n'était que chez moi, ou d'autres «vrais» testeurs auraient eu de semblables soucis ?

Sinon, mon test est complété par un nouveau chapitre (matériels).

 

[pascal_lb]

Il y a 5 heures, fran6p a dit :

Mon seul conseil, actuellement, est de ne pas utiliser la détection IA (désactiver toutes les options via l'écran). Comme le processus d'analyse «en temps réel» est fait localement de manière logicielle, le processeur Rockchip RK3308B-S est saturé, la mémoire vive (512 Mo) est surchargée (il suffit de regarder dans Fluidd l'utilisation du système).

Dommage pour une fois qu'il y avait une IA 

[fran6p]

Il y a 10 heures, pascal_lb a dit :

pour une fois qu'il y avait une IA 

Je préfère la CN (connerie naturelle) , c'est plus efficace.

 

[tranbert]

Ha tiens ce matin au démarrage "boot failed, restart the machine, if it fails again contact support".

Bon le deuxième boot n'a pas faillé, tout va bien j'espère 

 

[Grayshif]

Bonjour,

Est-ce que vous auriez une piste à me conseiller pour améliorer le résultat j'imagine que plus c'est plat mieux c'est

[fran6p]

@Grayshif

Bonjour,

Est-ce que tu rencontres des problèmes d'adhérence ?

Non => ne touche à rien, le maillage (bed mesh) sera utilisé pour compenser.

Oui => suis la procédure indiquée dans la vidéo du Wiki de Qidi (imprime d'abord les pièces ).

Tu peux aussi ajouter une section screws_tilt_adjust au fichier printer.cfg pour savoir quel coin ajuster :

[screws_tilt_adjust]
screw1:30,32
screw1_name: front left
screw2: 240,32
screw2_name: front right
screw3: 240,242
screw3_name: rear right
screw4: 30,242
screw4_name: rear left
horizontal_move_z: 10
speed: 50
screw_thread: CW-M4 

Actuellement ton «range» de 0,52 est surtout dû au coin avant droit en (0,275). 

 

[Grayshif]

j'ai lancé une impression qui utilise beaucoup de petite pièce et une grande partie du plateau  et certaine ce sont décollé je vais essayer de remettre ça d'aplomb

[fran6p]

Comme tu n'indiques pas quel filament a été utilisé, le décollement de parties peut être dû à de nombreux facteurs (surface bien dégraissée, température du lit pas assez chaude, vitesse de première couche trop rapide, …).

De plus, si les petites pièces ont une faible surface d'accroche sur le plateau, même un nivellement / tramming parfait ne changera pas grand-chose , une bordure pourrait plus aider.

Mes dernières impressions avec des filaments un poil plus techniques (PETG-GF, PET-CF) ont tellement bien adhéré que j'en ai bien sué à les retirer (depuis j'ai ajouté un offset dans le paramétrage du filament avec le trancheur QidiStudio).

Révélation

 

Modifié (le) dimanche à 12:34 par fran6p

[Grayshif]

j'ai utilisé du pla rapido de chez qidi et j'ai laissé les paramètres par defaut. Je nettoie le plateau après chaque impression avec de l'ipa. J'imagine que la vitesse élevé n'aide pas a bien faire adhérer les pièces sur le plateau surtout qu'elle sont nombreuses mais très petite

la bordure c'est la base vraiment j'oublie tout. Par contre j'ai bien ajouté les lignes dans le printer.cfg. Pour lancer le test j'utilise cette commande SCREWS_TILT_CALCULATE c'est bien ça

 

Très pratique le réglage des vis

Mon range est de 0.2980 maintenant

[tranbert]

Le 09/09/2025 at 19:13, fran6p a dit :

Cela, avant que je désactive l'IA, m'a provoqué plusieurs échecs sur des impressions longues (PETG-GF, ABS)  que je n'ai plus rencontré depuis cette modification.

J'ai pensé à un truc  : si on a réglé la résolution à 1280*720 je ne suis pas sûr que les zones de détection de l'IA prennent en compte cette modification de résolution. C'est une supposition tirée de mon utilisation de Frigate + IA, les zones de détection définies sont figées. Si derrière l'image change, elles restent inchangées. 

Mais je ne sais pas si on a accès aux réglages de l'IA sur la Q2. Ni si i'IA utilise le flux de crowsnest, d'ailleurs

Si c'est le cas, si on reste en 640*480 cela lui fait peut-être moins de données à analyser. Sur Frigate on a deux flux, l'un en résolution max pour l'enregistrement et un "sous-flux" qui nourrit l'IA.

Dans mon cas, une fois sur la Q2, j'ai mis l'IA en route et elle a tout coupé, je suppose à cause d'un cheveu qui rebiquait sur les lignes de purges. Enfin, c'est ce que je pense, car la pièce était sans aucun défaut visible.

Par contre, avec l'IA en fonction, j'ai parfois une erreur en fin d'impression et jamais si l'IA est déconnectée. : 

Stats 16987.8: gcodein=0  mcu: mcu_awake=0.001 mcu_task_avg=0.000003 mcu_task_stddev=0.000003 bytes_write=12797412 bytes_read=3527625 bytes_retransmit=110 bytes_invalid=0 send_seq=280262 receive_seq=280262 retransmit_seq=280168 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168005235 THR: mcu_awake=0.000 mcu_task_avg=0.000004 mcu_task_stddev=0.000004 bytes_write=3620551 bytes_read=1217980 bytes_retransmit=9 bytes_invalid=0 send_seq=79390 receive_seq=79390 retransmit_seq=2 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=72001613 adj=71999343 heater_bed: target=0 temp=57.6 pwm=0.000 chamber: target=0 temp=33.5 pwm=0.000 Chamber_Thermal_Protection_Sensor: temp=33.5  sysload=5.68 cputime=3670.905 memavail=188376 print_time=5495.499 buffer_time=0.000 print_stall=0 extruder: target=0 temp=162.7 pwm=0.000
Stats 16988.8: gcodein=0  mcu: mcu_awake=0.001 mcu_task_avg=0.000003 mcu_task_stddev=0.000003 bytes_write=12797418 bytes_read=3527785 bytes_retransmit=110 bytes_invalid=0 send_seq=280263 receive_seq=280263 retransmit_seq=280168 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168005251 THR: mcu_awake=0.000 mcu_task_avg=0.000004 mcu_task_stddev=0.000004 bytes_write=3620557 bytes_read=1217996 bytes_retransmit=9 bytes_invalid=0 send_seq=79391 receive_seq=79391 retransmit_seq=2 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=72001612 adj=71999331 heater_bed: target=0 temp=57.6 pwm=0.000 chamber: target=0 temp=33.6 pwm=0.000 Chamber_Thermal_Protection_Sensor: temp=33.8  sysload=5.68 cputime=3670.986 memavail=185548 print_time=5495.499 buffer_time=0.000 print_stall=0 extruder: target=0 temp=162.7 pwm=0.000
MCU 'mcu' shutdown: Timer too close
This often indicates the host computer is overloaded. Check
for other processes consuming excessive CPU time, high swap
usage, disk errors, overheating, unstable voltage, or
similar system problems on the host computer.
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

 

Il y a 7 heures, fran6p a dit :

Tu peux aussi ajouter une section screws_tilt_adjust au fichier printer.cfg pour savoir quel coin ajuster :

Cadeau de la maison si comme moi vous vous êtes plantés entre front, left right rear et tout ça.

[screws_tilt_adjust]
screw1: 30, 32
screw1_name: avant gauche
screw2: 240, 32
screw2_name: avant droite
screw3: 240, 242
screw3_name: arriere droite 
screw4: 30, 242
screw4_name: arriere gauche
horizontal_move_z: 10
speed: 50
screw_thread: CW-M4

 

[fran6p]

Toutes les imprimantes que j'ai eu à tester ayant une fonction «IA» (détection de spaghetti) m'ont provoqué des faux-positifs, rarement de réelles détections. Désormais, je les désactive. Si j'ai besoin d'avoir de tels garde-fous, je préfère me reposer sur Obico, Octoeverywhere ou Simplyprint.

Actuellement, les solutions propriétaires ressemblent plus à du «gadget» qu'autre chose. Même avec mes vieilles imprimantes (CR10, CR10V2, CR6-SE, CR30,…), j'ai rarement eu de plat de spaghetti à me mettre sous la dent…, c'est arrivé quelques fois, mais très peu souvent. Si la première couche est bonne, normalement l'impression va jusqu'au bout. La plupart du temps, quand j'avais eu des «fried nozzle» (terme utilisé par Qidi sur l'écran de la Q2 ), c'étaient généralement les supports qui en étaient la cause (solution: éviter au maximum l'utilisation de supports).

La Q2 a 512 Mo de RAM, le processeur Rk3308B-S n'est pas un foudre de guerre. L'analyse des détections d'impression se fait localement sur la carte via le programme main. Tout est dans le dossier /usr/local/bin/algo_app :

Citation

mks@linaro-alip:~$ ls -l /usr/local/bin/algo_app/
total 12396
drwxrwxr-x 19 root root     4096 Sep  1 13:40 _internal
drwxrwxr-x  2 root root     4096 Sep  1 13:40 configs
drwxrwxr-x  3 root root     4096 Sep  1 13:40 html
-rwxrwxr-x  1 root root 12669664 Aug 23 10:13 main
drwxrwxr-x  2 root root     4096 Sep  1 13:41 video_output
drwxrwxr-x  2 root root     4096 Sep  1 13:40 weights

Ce programme est lancé comme un processus (daemon) :

Révélation

mks@linaro-alip:~$ cat /etc/systemd/system/algo_app.service
[Unit]
Description=Start algo_app
After=network.target moonraker.service

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/usr/local/bin/algo_app/main
WorkingDirectory=/usr/local/bin/algo_app
Restart=always
RestartSec=15
MemoryHigh=200M
MemoryMax=250M
User=root
Group=root
Environment=PYTHONPATH=/usr/local/bin/algo_app
Environment=LD_LIBRARY_PATH=/usr/local/bin/algo_app/_internal/lib

# 确保工作目录存在并有正确的权限
ExecStartPre=/bin/mkdir -p /usr/local/bin/algo_app/video_output
ExecStartPre=/bin/mkdir -p /var/log/algo_app
ExecStartPre=/bin/chown -R root:root /usr/local/bin/algo_app
ExecStartPre=/bin/chmod -R 775 /usr/local/bin/algo_app

«main» est un binaire dont les symboles ont été retirés lors de la compilation. Peut-être qu'avec ghidra, il serait possible de le décompiler, mais je n'ai pas le temps de faire des essais.

Ce qui est sûr, c'est que la désactivation via l'écran des fonctions d'IA et encore mieux, l'arrêt du daemon et sa désactivation, font chuter l'utilisation de la RAM et l'occupation du processeur (Fluidd, Système, Utilisation du système => graphiques Charge et mémoire système) .

Révélation

En ssh :

sudo systemctl stop algo_app

sudo systemctl disable algo_app

 

Modifié (le) lundi à 10:37 par fran6p

[tranbert]

Il y a 6 heures, fran6p a dit :

Tout est dans le dossier /usr/local/bin/algo_app :

Ha oui, il semble y avoir une api de gestion à http://ipq2:9010

Le pass est dans le fichier config.xml dans /usr/local/bin/algo_app/configs, mais je ne sait pas exploiter ça, le web est "fermé" selon le message que l'on a une fois logué.

D'ailleurs si on traduit les commentaires du xml via google, ça parle de "nouilles sautées" et pas frites  

 

Révélation

<config>
<!-- Port du service API -->
<api_port>9010</api_port>
<!-- Port Moonraker -->
<moonraker_port>7125</moonraker_port>
<force_printer_status>False</force_printer_status>
<!-- Utilisateur web de gestion -->
<management_web_user>qidi</management_web_user>
<!-- Mot de passe web de gestion -->
<management_web_password>qiditech</management_web_password>

<!-- Paramètres d'entrée vidéo -->
<video_input>
<!-- Sélection de la source vidéo : Faux : Flux vidéo (caméra ou flux réseau) Vrai : Fichier vidéo -->
<is_video_file>False</is_video_file>

<!-- Configuration du fichier vidéo -->
<video_files>
<!-- Chemin du dossier vidéo -->
<video_files_dir>video_input</video_files_dir>
<!-- Nom du fichier vidéo sélectionné -->
<video_files_name>test.mp4</video_files_name>
<!-- Nombre d'images entre les inférences pour le fichier vidéo -->
<video_files_frame_lost>1</video_files_frame_lost>
</video_files>
<!-- Indique si l'image présentant la plus petite zone d'occlusion de la tête d'impression entre deux détections doit être utilisée pour la détection -->
<min_occluded_frame>Faux</min_occluded_frame>
</video_input>

<!-- Paramètres de sortie vidéo -->
<video_output>
<!-- Dossier de sortie vidéo -->
<video_output_dir>../../../../home/qidi/video</video_output_dir>

<!-- Paramètres vidéo bruts -->
<video_output_raw>
<!-- Enregistrer Vidéo brute -->
<is_save_raw_video>True</is_save_raw_video>
<!-- Combien de millisecondes l'image doit-elle être enregistrée ? -->
<save_raw_video_interval>30000</save_raw_video_interval>
<!-- Enregistrer l'image optimale pour chaque couche (lorsque la tête d'impression est la plus éloignée de la caméra). À utiliser avec min_occluded_frame pour de meilleurs résultats. -->
<is_save_layer_best_view>True</is_save_layer_best_view>
</video_output_raw>

<!-- Configuration vidéo post-détection -->
<video_output_detect>
<!-- Enregistrer la vidéo post-détection -->
<is_save_detect_video>False</is_save_detect_video>
<!-- Combien de millisecondes l'image doit-elle être enregistrée ? -->
<save_detect_video_interval>5000</save_detect_video_interval>
<!-- Enregistrer l'image des nouilles frites détectées comme image -->
<save_detect_video_pic>Faux</save_detect_video_pic>
<!-- Enregistrer l'image des nouilles frites comme vidéo -->
<save_detect_pic_to_video>Vrai</save_detect_pic_to_video>
</video_output_detect>

<!-- Paramètres de détection -->
<detect_setting>
<!-- Activation ou non d'une inférence -->
<is_detect_flag>Vrai</is_detect_flag>
<!-- Activation ou non de la détection PEI -->
<is_pei_check>Faux</is_pei_check>
<!-- Activation ou non de la détection de corps étrangers -->
<is_foreign_check>False</is_foreign_check>
<!-- Activation ou non du détachement du modèle d'impression et de la détection de mouvement -->
<is_md_check>False</is_md_check>
<!-- Détection du calque de départ -->
<start_layer>2</start_layer>
<!-- Configuration de l'affichage des classes. La valeur « True » s'affiche, la valeur « False » ne s'affiche pas. Les classes sont affichées dans l'ordre. -->
<class_vis>[true, true, true]</class_vis>

<!-- Paramètres d'inférence -->
<detect_config>
<!-- Seuil de confiance -->
<conf_thres>0,48</conf_thres>
<!-- Seuil IOU -->
<iou_thres>0,2</iou_thres>
<!-- Numéro de thread interne -->
<intra_num>1</intra_num>
<!-- Numéro de thread externe -->
<inter_num>1</inter_num>
</detect_config>

<!-- Configuration de l'action post-détection -->
<detect_action>
<!-- Paramètres de déclenchement de l'alarme -->
<alarm>
<is_open_alarm>False</is_open_alarm>
<!-- Déclencher l'alarme après la détection de 5 nouilles frites. 0 : Désactiver ce paramètre -->
<count>5</count>
<!-- Déclencher une alarme si le score des nouilles sautées est supérieur à 10. 0 : Désactiver ce paramètre -->
<conf>10</conf>
</alarm>

<!-- Action pour le nombre d'images de nouilles sautées -->
<find_count>
<!-- Déclencher une alarme après avoir détecté n nouilles sautées. 0 : Désactiver ce paramètre -->
<count>15</count>
<!-- Suspendre l'impression -->
<is_pause_print>False</is_pause_print>
<!-- Annuler l'impression -->
<is_cancel_print>False</is_cancel_print>
</find_count>

<!-- Action pour le score des nouilles sautées -->
<conf_count>
<!-- Nombre cumulé de points de nouilles sautées : 0 : Désactivé -->
<conf>15</conf>
<!-- Suspendre l'impression ? -->
<is_pause_print>Faux</is_pause_print>
<!-- Annuler l'impression ? -->
<is_cancel_print>Faux</is_cancel_print>
</conf_count>

<!-- Le modèle se désengage de l'action de mouvement ? -->
<md_count>
<!-- Nombre cumulé d'occurrences de mouvement : 0 : Désactivé -->
<count>6</count>
<!-- Suspendre l'impression ? -->
<is_pause_print>Faux</is_pause_print>
<!-- Annuler l'impression ? -->
<is_cancel_print>Faux</is_cancel_print>
</md_count>

</detect_action>
</detect_setting>
</config>

 

 

edit + tard : 

Alors en furetant un peu, à http://1ipq2:9010/static/setting/settings.html il y a une page de gestion des paramètres de l'analyse et des comportements de l'IA. J'ai pas trop envie de tout casser, je regarde juste.

 

Modifié (le) lundi à 17:10 par tranbert