(Qidi Q2) Fluidd suivi gcode en synchro avec l'impression ?

[tranbert]

Bonsoir,

J'ai un doute : dans Fluidd on peut avoir le suivi en temps réel des couches en synchro avec l'imprimante. À la Octoprint.

Mais dans la version de fluidd de Qidi studio sur Q2, il n'y a pas de suivi, juste l'affichage d'un contour de l'objet, avec la possibilité de l'exclure. Mais aucun suivi ni défilement.

C'est "normal" ou c'est un bug chez moi ? C'est pareil chez vous ?

 

 

 

 

[hyoti]

Je n'ai pas la Q2,

mais dans Fluidd pour avoir le suivi des couches en temps réel pendant l'impression,

il faut d'abord charger le fichier, il ne charge pas automatiquement (pour diminuer la charge CPU si pas utile).

Sur le haut à droite sur ta capture d'écran il semblerait que le fichier n'est pas chargé ( charger le fichier actuel en surbrillance)

si c'est bien le cas, pas de bug.

  

Modifié (le) Septembre 4 par hyoti

[tranbert]

il y a 26 minutes, hyoti a dit :

Sur le haut à droite sur ta capture d'écran il semblerait que le fichier n'est chargé( charger le fichier actuel en surbrillance)

si c'est bien le cas, pas de bug.

Oui, c'est que je pensais, mais même si je charge, rien de rien, aucun suivi.

Bon, je vais voir si je trouve quelque chose. Merci pour l'info.

 

[fran6p]

C'est une fonction que je n'utilise habituellement pas (ça surcharge trop le CPU, surtout avec certains microcontrôleurs faméliques).

Je viens de tester et la version modifiée de Fluidd par Qidi ne gère que l'exclusion d'objet, pas le suivi de l'impression couche après couche.

 

[tranbert]

il y a 9 minutes, fran6p a dit :

C'est une fonction que je n'utilise habituellement pas (ça surcharge trop le CPU, surtout avec certains microcontrôleurs faméliques).

Je viens de tester et la version modifiée de Fluidd par Qidi ne gère que l'exclusion d'objet, pas le suivi de l'impression couche après couche.

OK donc c'est "normal". C'est vrai que sous Octoprint j'ai un rasp qui n'a que ça à faire, ça aide et ça donne de mauvaises habitudes.

Merci !

[hyoti]

Il y a 2 heures, fran6p a dit :

Je viens de tester et la version modifiée de Fluidd par Qidi ne gère que l'exclusion d'objet, pas le suivi

Est-ce pareil sur la X max3 ?

[fran6p]

il y a 48 minutes, hyoti a dit :

 Est-ce pareil sur la X max3 ?

Pas sur ma XM3 libérée qui utilise les logiciels «vanilla» de l'écosystème Klipper .

Qidi utilise sa propre version de Fluidd, modifiée par rapport à la version actuelle de Fluidd. Probablement que lors du développement initial, la version de Fluidd sur laquelle ils se sont basés n'avait pas la gestion «multi-filaments». Gestion qu'ils ont ajoutée à leur Qidi-version  et par effet de bord, cela aurait désactivé le suivi de l'impression du Gcode… conjecture de ma part .

La section «QBox» dans Fluidd :

En plus, lors d'une mise à jour du firmware, Fluidd est réinstallé avec leur version… j'avais mis à jour via KIAUH (réinstallé, car celui de Qiidi est bancal), Fluidd en dernière version, une mise à jour a remis la Q2 dans son état antérieur (idem pour mes modifications faites à moonraker.conf, printer.cfg, gcode_macros.cfg, …) .

Les rares fois où j'utilisais ce suivi du Gcode, j'utilisais PrettyGcode, un «greffon» additionnel installé via KIAUH. 

Il y a 3 heures, tranbert a dit :

donc c'est "normal".

Suivant le point de vue, ce n'est pas un bug, mais une fonctionnalité .

Modifié (le) Septembre 5 par fran6p

[hyoti]

Merci

Sur la K2 plus, Fluidd gère le suivi graphique du gcode mais pas le multicouleur.

(En cours d'impression ou pas) Creality 6.2 ne gère pas le suivi du gcode (exclusion seulement), mais  le multicouleur, (quand même)

pas de courbe de température du MCU.

Fluidd donne la température de MCU mais lequel ?

[fran6p]

il y a 22 minutes, hyoti a dit :

Fluidd donne la température de MCU mais lequel ?

Sur la Q2, je n'ai pas réussi à ajouter l'affichage de la température des microcontrôleurs de la carte STM32F407, ni celle de la tête…

En ajoutant les sections qui habituellement vont bien, ça provoque une erreur et empêche Klipper de démarrer / redémarrer  => le sensor_type:temperature_mcu provoque une division par zéro .

La seule, fonctionnelle est celle de l'affichage de la température du Rockchip (ajoutée manuellement)… et celle de la QidiBox quand elle est connectée. 

[temperature_sensor Rockchip]
sensor_type:temperature_host
min_temp:5
max_temp:80

## Tests
# sensor_type: temperature_mcu provoque une erreur !
#[temperature_sensor STM32]
#sensor_type:temperature_mcu
#sensor_mcu:mcu
#min_temp:5
#max_temp:80

#[temperature_sensor Toolhead]
#sensor_type:temperature_mcu
#sensor_mcu:THR
#min_temp:5
#max_temp:80
## /Tests

Quand la Qbox est connectée :

Là encore, je soupçonne le Klipper de Qidi, basé pour leur développement sur une version 0.12.x à laquelle ils ont ajoutés leurs modifications (et obfuscations/offuscations? avec des fichiers .so (Python passé à la moulinette de Cython) au lieu de fichiers Python «purs» (.py)).

 

Modifié (le) Septembre 5 par fran6p

[hyoti]

il y a une heure, fran6p a dit :

obfuscations/offuscations?

Pas évident, j'utilise plutôt le premier terme..

J'ai trouvé en anglais la différence d'usage entre les deux mots, logique mais déjà "obscure" 

https://redkiwiapp.com/en/english-guide/synonyms/offuscation-obfuscation

[fran6p]

Obfuscation utilise littéralement le terme anglais, offuscation est plus «français»… mais c'est comme digital / numérique  (j'aime les «BD» de Gee : https://grisebouille.net/amour-numerique/).

 

[hyoti]

Merci je ne connaissais pas.