Faire les mises à jour de Klipper et de Moonraker sur une SK1

[fran6p]

Je pense mais je n'en suis pas certain que la communication ne peut s'établir car dans le menuconfig, on demande une connexion USB or le câble reliant la carte mère à la fille utilise une connexion UART.

Pourrais-tu tester en modifiant dans le menuconfig: la ligne «Communication Interface» pour utiliser le mode UART comme ci-dessous :

Pour au final avoir :

Sauvegarder, préparer le firmware:

make -j4

Le firmware préparé sera à nouveau un klipper.uf2, il faudra le flasher via le passage en mode émulation de stockage du RP2040, en débranchant le câble de communication UART, branchant le câble USB (à faire imprimante éteinte) puis en pressant le bouton BOOT jusqu'à passer le RP2040 dans le mode «correct» (tu connais la procédure désormais ).

Au cas où le RP2040 ne soit pas en mode émulation, tu peux tester la combinaison de pression sur les boutons BOOT / RESET :

• presser BOOT,
• le maintenir enfoncé,
• presser RESET,
• relâcher les boutons

Le bouton RESET est en haut de la carte (BOOT en bas) :

Une fois le firmware flashé, éteindre, débrancher le câble USB, rebrancher le câble UART, allumer et croiser les doigts, serrer les fe…es, prier St Murphy, allumer des cierges, faire appel au marabout du coin

[pascal_lb]

Il y a 3 heures, fran6p a dit :

allumer et croiser les doigts, serrer les fe…es, prier St Murphy, allumer des cierges, faire appel au marabout du coin

hélas malgré tout cela ça ne fonctionne toujours pas 

je l'ai fait 2 fois pour être sur

J'ai bien la carte fille qui passe en émulation 

[pascal_lb]

@fran6p apparemment @bistory test aussi la même version d'Armbian que nous https://www.facebook.com/groups/868971071459953/user/61555013783996 je lui ai posé la question pour savoir quelles options il utilise avant de compiler on verra bien si il répond 

[fran6p]

Je commence à sécher Je suppose que tu as bien re-préparé le firmware (RP2040, UART0 gpio0/gpio1).

Sans rapport, peut-être, quoi que

Ton dernier lsusb, retourne des identifiants identiques pour la carte principale et celle de la tête ( 1d50:614e ) (Openmoko RP2040 / STM32F401XC) mais normalement la carte de la tête ne devrait plus être listée car la connexion se fait en UART plus en USB sauf si tu as utilisé lsusb alors que le câble USB était encore connecté.

Le [mcu MKS_THR] contient d'origine serial: /dev/ttyS0 ?

Que donne un «ls /dev/serial/by-id/*» ?

Si plusieurs lignes apparaissent, y en a t'il une contenant la suite …_rp2040_… si oui alors tester en remplaçant le paramètre serial: avec /dev/serial/by-id/usb-Klipper_rp2040_…

Sinon, je me pose encore ces questions:

• le firmware est-il flashé sur la carte ?
• s'il l'est, est-ce un problème de communication ? pas la bonne interface ?

Je n'ai encore jamais utilisé les outils de débogage de Klipper donc pas sûr que ce soit utile

Pour l'utiliser (peut-être faudra-t'il arrêter le daemon Klipper «sudo systemctl stop klipper» ?)

cd ~/klipper
~/klippy-env/bin/python ~/klipper/klippy/console.py /dev/ttyS0

Normalement si la communication n'arrive pas à s'établir (le serial déclaré dans la section [mcu MKS_THR] est /dev/ttyS0), tu auras un message se répétant disant un truc du genre (copie écran via mon W10 avec WSL2 où la communication ne peut évidemment pas s'établir :

Citation

==================== attempting to connect ====================
INFO:root:Starting serial connect
WARNING:root:Unable to open serial port: [Errno 13] could not open port /dev/ttyS0: [Errno 13] Permission denied: '/dev/ttyS0'
WARNING:root:Unable to open serial port: [Errno 13] could not open port /dev/ttyS0: [Errno 13] Permission denied: '/dev/ttyS0'
WARNING:root:Unable to open serial port: [Errno 13] could not open port /dev/ttyS0: [Errno 13] Permission denied: '/dev/ttyS0'

Sinon, tu peux tenter d'envoyer la commande STATS

Citation

francis@ARRAKIS-DUNE:~/klipper$ ~/klippy-env/bin/python ./klippy/console.py /dev/ttyS0
INFO:root:Building C code module c_helper.so

  This is a debugging console for the Klipper micro-controller.
  In addition to mcu commands, the following artificial commands are
  available:
    DELAY : Send a command at a clock time (eg, "DELAY 9999 get_uptime")
    FLOOD : Send a command many times (eg, "FLOOD 22 .01 get_uptime")
    SUPPRESS : Suppress a response message (eg, "SUPPRESS analog_in_state 4")
    SET   : Create a local variable (eg, "SET myvar 123.4")
    DUMP  : Dump memory (eg, "DUMP 0x12345678 100 32")
    FILEDUMP : Dump to file (eg, "FILEDUMP data.bin 0x12345678 100 32")
    STATS : Report serial statistics
    LIST  : List available mcu commands, local commands, and local variables
    HELP  : Show this text
  All commands also support evaluation by enclosing an expression in { }.
  For example, "reset_step_clock oid=4 clock={clock + freq}".  In addition
  to user defined variables (via the SET command) the following builtin
  variables may be used in expressions:
    clock : The current mcu clock time (as estimated by the host)
    freq  : The mcu clock frequency

Pour la connexion du pseudo câble USB sur la tête, j'ai trouvé une image du PCB arrière qui montre comment doit se faire la connexion :

Donc de l'autre côté, si je ne me trompe pas (de gauche à droite) : D-, D+, GND, 5V. C'est bien ainsi que ton câble USB est connecté?
 

Désolé mais là, il faudra peut-être que d'autres apportent des idées  

Modifié (le) Juillet 15, 2024 par fran6p

[pascal_lb]

Il y a 5 heures, fran6p a dit :

Je suppose que tu as bien re-préparé le firmware (RP2040, UART0 gpio0/gpio1).

oui

Il y a 5 heures, fran6p a dit :

normalement la carte de la tête ne devrait plus être listée car la connexion se fait en UART plus en USB sauf si tu as utilisé lsusb alors que le câble USB était encore connecté.

oui elle était encore connecté, mais le cable UART était déconnecté

Il y a 5 heures, fran6p a dit :

Le [mcu MKS_THR] contient d'origine serial: /dev/ttyS0 ?

oui

[mcu MKS_THR]

serial: /dev/ttyS0

restart_method: command

Il y a 5 heures, fran6p a dit :

Que donne un «ls /dev/serial/by-id/*» ?

il n'y a qu'une seule ligne

mks@mkspi:~$ ls /dev/serial/by-id/*
/dev/serial/by-id/usb-Klipper_stm32f401xc_5A0064000351323532393238-if00

Il y a 5 heures, fran6p a dit :

le firmware est-il flashé sur la carte ?

apparemment oui car quand j'envoi le firmware la carte est en émulation de stockage, et ensuite elle n'y est plus

Il y a 5 heures, fran6p a dit :

s'il l'est, est-ce un problème de communication ? pas la bonne interface ?

pour être sur, je viens de sonder le cable UART (4 fils) et il y a bien la continuité, j'ai vérifié car après quelques jours d'utilisation de la machine j'avais eu un problème sur ce câble qui donnait le même message d'erreur (d'ailleurs ça fait 3 mois que TT doit m'en envoyer un autre il va falloir que je les relance) mais là c'est bon

Il y a 5 heures, fran6p a dit :

Normalement si la communication n'arrive pas à s'établir (le serial déclaré dans la section [mcu MKS_THR] est /dev/ttyS0), tu auras un message se répétant disant un truc du genre (copie écran via mon W10 avec WSL2 où la communication ne peut évidemment pas s'établir

voilà le message :

En fait j'ai déjà vu ça dans le klippy.log mais je n'ai aucune idée de la signification 

Citation

==================== attempting to connect ====================
INFO:root:Starting serial connect
INFO:root:Timeout on connect
ERROR:root:Wait for identify_response
Traceback (most recent call last):
  File "/home/mks/klipper/klippy/serialhdl.py", line 68, in _get_identify_data
    params = self.send_with_response(msg, 'identify_response')
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mks/klipper/klippy/serialhdl.py", line 262, in send_with_response
    return src.get_response([cmd], self.default_cmd_queue)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mks/klipper/klippy/serialhdl.py", line 319, in get_response
    self.serial.raw_send_wait_ack(cmds[-1], minclock, reqclock,
  File "/home/mks/klipper/klippy/serialhdl.py", line 254, in raw_send_wait_ack
    self._error("Serial connection closed")
  File "/home/mks/klipper/klippy/serialhdl.py", line 61, in _error
    raise error(self.warn_prefix + (msg % params))
serialhdl.error: Serial connection closed
 

 

Il y a 5 heures, fran6p a dit :

D-, D+, GND, 5V. C'est bien ainsi que ton câble USB est connecté?

oui pour souder la prise il a fallu que je démonte la carte c'est par rapport à ça que j'ai mis les fils dans le bon ordre

Il y a 5 heures, fran6p a dit :

Désolé mais là, il faudra peut-être que d'autres apportent des idées  

ne soit pas désolé, tu m'as déjà donner une sacré coup de mains, je ne serais pas arrivé là sans ton aide

Mille merci 

éventuellement Mr @Savate une idée ou pas  
 

Modifié (le) Juillet 15, 2024 par pascal_lb

[pascal_lb]

J'ai eu une réponse de @bistory sur face de bouque, apparemment sur la sienne ce n'ai pas un rp2040 mais un stm32, il va falloir que je regarde à la loupe si je vois une référence 

Édit.

C'est un

RP2-B2 22/07

PCX 080 00

Donc c'est bien un RP2040 si en plus c'est pas les mêmes cartes  sur toutes les machines

Modifié (le) Juillet 16, 2024 par pascal_lb

[fran6p]

Il est possible normalement d'installer le firmware sur le RP2040 en utilisant l'ancienne méthode.

La préparation du firmware ne change pas:

=> Préparer via menuconfig (RP2040, No bootloader, etc.)

[*] Enable extra low-level configuration options
Micro-controller Architecture (Raspberry Pi RP2040) --->
Bootloader offset (No bootloader) --->
Flash chip (W25Q080 with CLKDIV 2) --->
Communication interface (????) --->
USB ids --->
() GPIO pins to set at micro-controller startup

Pour la ligne Commucation interface, c'est là que je ne sais pas vraiment quoi utiliser (USB si la carte était utilisée ensuite uniquement via USB sinon UART (plutôt GPIO0/1) sans en être certain car le schéma électronique n'est pas disponible )

Après la configuration, appuyez sur q pour quitter, sélectionnez Oui / Yes lorsque invité à sauvegarder.

Donc:

cd ~/klipper/
make menuconfig
make

 

Câble UART déconnecté, câble «USB» connecté, passer la carte en mode DFU (BOOT / RESET).

lsusb

devrait afficher le RP2040 passé en mode DFU :

=> ID 2e8a:0003 Raspberry Pi RP2 Boot

Utiliser la commande suivante pour flasher (le device doit correspondre à celui affiché via lsusb)

make flash FLASH_DEVICE=2e8a:0003

Le retour de cette commande devrait être plus explicite (enfin, j'espère )

Si la connexion n'était qu'en USB (mais il faudrait dans ce cas, fournir le 24V autrement), il n'y aurait plus besoin d'appuyer sur le bouton Boot pour les mises à jour suivantes. Il suffirait d'entrer la commande suivante pour flasher le micrologiciel:
make flash FLASH_DEVICE=/dev/serial/by-id/usb-Klipper_rp2040_4550357128922FC8-if00

(Note : évidemment, remplacer **/dev/serial/by-id/xxx** par l'ID réel trouvé via ls /dev/serial/by-id/ ).

 

Bizarre, cette affaire de carte utilisant des contrôleurs différents d'après @bistory .

Makerbase avec ses cartes MKS-THR (36 ou 42) utilise des Raspberry Pi RP2040. Cela m'étonnerait fortement que Twotrees ait demandé une version (deux versions en fait si TomBasement dit vrai) de leur carte à Makerbase (celle de Qidi est aussi fabriquée par MKS avec un contrôleur RP2040)

De toute façon si c'était un STM32 utilisé en lieu et place du RP2040, ce ne serait certainement probablement pas celui qu'il a utilisé (STM32F401) pour préparer son firmware (déjà erroné pour la carte principale un STMF402 au lieu du STMF407) mais plutôt un STM32F072 ou encore un STM32G0B1 (comme de nombreuses cartes CAN (BTT, MellowFly, Huvud, …)

Modifié (le) Juillet 16, 2024 par fran6p

[pascal_lb]

il y a 23 minutes, fran6p a dit :

Pour la ligne Commucation interface, c'est là que je ne sais pas vraiment quoi utiliser (USB si la carte était utilisée ensuite uniquement via USB sinon UART (plutôt GPIO0/1) sans en être certain car le schéma électronique n'est pas disponible

Je vais cette après midi tester les 2 on verra bien

 

[fran6p]

Si le flash fonctionne, comme tu as utilisé une distribution «vierge», l'écran ne sera plus du tout fonctionnel mais je sais que tu le sais (Le BTT Ktouch, s'il sort un jour, pourrait alors être utile )

Révélation

Il y a bien un paquet Debian proposé par TwoTrees (twotrees.deb) dans ses mises à jour software, mais il risquerait de perturber le système: il réinstalle dans le home de mks, en plus du dossier twotress (contient le programme communiquant entre l'écran TJC et Moonraker), les dossiers klipper_config et gcode_files (contient un dossier lib probablement utilisé pour faire la correspondance à l'aide de fichiers .json et .csv (traductions)  et l'interface graphique de l'écran TJC) qui ne sont plus utilisés avec les versions récentes de Moonraker (qui utilise maintenant un dossier principal printer_data pour regrouper config, gcodes, et autres dossiers).

De plus même en réinstallant ce paquet, il manque tous les éléments «makerbase-client» permettant d'exécuter ce programme au lancement du système)

[pascal_lb]

il y a 29 minutes, fran6p a dit :

Le BTT Ktouch, s'il sort un jour, pourrait alors être utile

C'est un peu pour ça que je l'ai commandé

Tu l'as eu ou ce texte ?

[fran6p]

il y a une heure, pascal_lb a dit :

Tu l'as eu ou ce texte ?

Lequel ?

[pascal_lb]

Il y a 1 heure, fran6p a dit :

Il y a bien un paquet Debian proposé par TwoTrees (twotrees.deb) dans ses mises à jour software, mais il risquerait de perturber le système: il réinstalle dans le home de mks, en plus du dossier twotress....

A moins que ce soit toi mais comme c'est en texte masqué

[fran6p]

Je l'ai caché, juste pour ne pas polluer plus le sujet

C'est juste une analyse du contenu des fichiers .img (un .deb aussi) ou des fichiers de mises à jour fournies par Twotrees (sans se prendre trop la tête, les fichiers «img» peuvent facilement être décompressés à l'aide de 7zip sinon sous Linux, le binaire «binwalk» est un précieux atout dans l'analyse de systèmes )… Je commence à avoir un peu de pratique avec la Creality SonicPad, le FlsunPad, la Qidi Xmax3, plus des «acquis» antérieurs.

Modifié (le) Juillet 16, 2024 par fran6p

[pascal_lb]

il y a une heure, fran6p a dit :

C'est juste une analyse du contenu des fichiers .img (un .deb aussi) ou des fichiers de mises à jour fournies par Twotrees (sans se prendre trop la tête, les fichiers «img» peuvent facilement être décompressés à l'aide de 7zip sinon sous Linux, le binaire «binwalk» est un précieux atout dans l'analyse de systèmes )… Je commence à avoir un peu de pratique avec la Creality SonicPad, le FlsunPad, la Qidi Xmax3, plus des «acquis» antérieurs.

je comprend mieux, jamais essayé ça, mais testerai pour voir

Bon maintenant une bonne nouvelle  ça a fonctionné et klipper est démarré, je crois que je vais aller mettre un cierge au pied de la status de Saint Fran6p 

Maintenant ça communique avec la tête j'ai les températures

 

J'ai d'abord compilé avec l'option USB et après avoir fait 

mks@mkspi:~$ make flash FLASH_DEVICE=2e8a:0003
make: *** Aucune règle pour fabriquer la cible « flash ». Arrêt.

j'ai donc recompilé avec l'option UART et là j'ai eu ça

mks@mkspi:~/klipper$ make flash FLASH_DEVICE=2e8a:0003
  Building rp2040_flash
gcc -c -Wall -ggdb -I../rp2040/ `pkg-config libusb-1.0 --cflags` main.c -o main.o
gcc -c -Wall -ggdb -I../rp2040/ `pkg-config libusb-1.0 --cflags` picoboot_connection.c -o picoboot_connection.o
gcc  main.o picoboot_connection.o `pkg-config libusb-1.0 --libs` -o rp2040_flash
  Flashing out/klipper.uf2 to 2e8a:0003
sudo lib/rp2040_flash/rp2040_flash out/klipper.uf2

[sudo] Mot de passe de mks :
Loaded UF2 image with 131 pages
Found rp2040 device on USB bus 2 address 2
Flashing...
Resetting interface
Locking
Exiting XIP mode
Erasing
Flashing
Rebooting device

J'ai rebranché et redémarré et le miracle est arrivé 

Si je comprend bien il faut que je supprime le "max_accel_to_decel" mais faut il le remplacer par autre chose ?

pour le reste je pense qu'il faut modifier le "/home/mks/gcode_files" par "/home/mks/printer_data/gcodes"

Je vais pouvoir commencer les tests et voir si tout fonctionne, surtout le réglage du lit automatique

Modifié (le) Juillet 16, 2024 par pascal_lb

[fran6p]

Trop fort le @fran6p 

Ça fonctionne et c'est le principal

il y a 14 minutes, pascal_lb a dit :

Si je comprend bien il faut que je supprime le "max_accel_to_decel" mais faut il le remplacer par autre chose ?

Oui, c'est une option «dépréciée» qui à terme sera abandonnée. Extrait de mon «printer.cfg» ( pas encore finalisé )

il y a 17 minutes, pascal_lb a dit :

pour le reste je pense qu'il faut modifier le "/home/mks/gcode_files" par "/home/mks/printer_data/gcodes"

Oui, Fluidd / Mainsail sont plutôt explicites et donnent la solution (juste à la fin la section [virtual_sdcard])

Pour le réglage du lit automatique, aucune idée si ça fonctionnera: il sera touojurs temps d'aller voir comment TT l'a mis en place (en espérant que ce ne soit pas comme Creality ou Qidi… en modifiant des fichiers Klipper).

Quand / si ce sera fonctionnel, tu pourrais faire un tuto (ou ouvrir un dépôt Github) et à toi la renommée … pour taquiner @bistory tu pourrais aussi ouvrir un ticket sur son dépôt pour indiquer qu'ici sur le forum, on a trouvé LA solution.

[pascal_lb]

Quelques infos complémentaires pour prouver que l'on est bien sur la version d'Armbian Bookworm  

Le réglage du lit automatique, le nivellement fonctionne il faut que je regarde le réglage du Zoffset et les réglages vibratoires car ça c'était lancé depuis l'écran

il y a 6 minutes, fran6p a dit :

Trop fort le @fran6p 

Oui je confirme, grand merci à toi !!!

il y a 7 minutes, fran6p a dit :

Quand / si ce sera fonctionnel, tu pourrais faire un tuto (ou ouvrir un dépôt Github) et à toi la renommée … pour taquiner @bistory tu pourrais aussi ouvrir un ticket sur son dépôt pour indiquer qu'ici sur le forum, on a trouvé LA solution.

oui je pense que je vais aller mettre un message sur son compte face de bouque 

Pour le tuto oui je vais refaire un truc au propre dans un autre sujet, avec ta permission je te citerai et de te piquerai quelques passages ou images de tes posts de la XM3

Pour le dépot Github je ne connais pas le fonctionnement mais j'irai jeter un coup d'œil

[fran6p]

il y a 18 minutes, pascal_lb a dit :

Pour le tuto oui je vais refaire un truc au propre dans un autre sujet, avec ta permission je te citerai et de te piquerai quelques passages ou images de tes posts de la XM3

Aucun problème, tout ce que j'écris ici ou sur mes dépôts est en libre utilisation… chacun en fait l'usage qu'il veut / peut

A terme, il faudra peut-être que tu fasses une image de ton système actuel car apparemment la eMMC originelle de TwoTrees semble être une 8 Go (j'avais aussi pour la XM3 débuté avec la 8 Go mais après installation de nombreux outils tous plus indispensables les uns que les autres (Klippain Shake & Tune (très pratique pour tout ce qui est «compensation de résonnances» (input shaping), Crowsnest, Timelapses, KAMP (uniquement pour la ligne de purge), octoeverywhere, Spoolman, TMC autotune, KlipperBackup, …) la place libre s'amenuisait très fortement.

Mon image actuellement a été refaite sur la première eMMC que j'avais achetée (celle sans ses oreilles ) de 16 Go (si je suppprimais tous les timelapses, je pourrais récupérer au moins 3 Go)

Pour faire mes images de système, j'utilise un outil «portable» très simple : ImageUSB

Modifié (le) Juillet 16, 2024 par fran6p

[pascal_lb]

il y a 15 minutes, fran6p a dit :

A terme, il faudra peut-être que tu fasses une image de ton système actuel

oui il va falloir que j'en achète une plus grande

il y a 15 minutes, fran6p a dit :

Pour faire mes images de système, j'utilise un outil «portable» très simple : ImageUSB

oui je connais c'est toi qui me l'a fait connaitre 

je viens d'essayer de rebrancher ma camera mais en faisant 

mks@mkspi:~$ sudo systemctl enable webcamd
[sudo] Mot de passe de mks :
Failed to enable unit: Unit file webcamd.service does not exist.

je pense que comme c'est une version brut il faut installer quelque chose... Crowsnest ?

Pour le timelaps c'est bon je connais

edit.

par contre dans les mises à jour j'ai des paquets qui sont à installer, je pense que maintenant je peux le faire ?

Modifié (le) Juillet 16, 2024 par pascal_lb

[fran6p]

il y a 28 minutes, pascal_lb a dit :

je pense que comme c'est une version brut il faut installer quelque chose... Crowsnest ?

Oui, il le faut.

Il faudra une fois installé, modifier le fichier crowsnest.conf (la ligne device: ) pour y indiquer le périphérique vidéo à utiliser ( lsusb puis un ls /dev/video* ). Mais il peut y avoir plusieurs /dev/video

Exemple sur XM3 :

Citation

mks@mkspi:~$ ls /dev/video*
/dev/video0  /dev/video1  /dev/video2  /dev/video3  /dev/video4  /dev/video5  /dev/video6
mks@mkspi:~$ ls -l /dev/video*
crw-rw---- 1 root video 81, 0 13 juil. 18:17 /dev/video0
crw-rw---- 1 root video 81, 1 13 juil. 18:17 /dev/video1
crw-rw---- 1 root video 81, 2 13 juil. 18:17 /dev/video2
crw-rw---- 1 root video 81, 3 13 juil. 18:17 /dev/video3
crw-rw---- 1 root video 81, 4 13 juil. 18:17 /dev/video4
crw-rw---- 1 root video 81, 5 13 juil. 18:17 /dev/video5
crw-rw---- 1 root video 81, 6 13 juil. 18:17 /dev/video6

Si la caméra est «compatible» V4L, tu peux au lieu du /dev/videoX utiliser le périphérique retourné par ( ls -l /dev/v4l/by-id/ | grep index0 ) => la caméra dans ce cas aura toujours le même périphérique même en changeant l'emplacement de connexion sur un des ports USB et en plus ça affiche le lien symbolique du /dev/videoX

Exemple, toujours sur ma XM3 (j'ai deux caméras connectées ) :

Citation

mks@mkspi:~$ ls -la /dev/v4l/by-id/ | grep index0
lrwxrwxrwx 1 root root  12 13 juil. 18:17 usb-Mintion_NZC_Mintion_NZC_SN0001-video-index0 -> ../../video3
lrwxrwxrwx 1 root root  12 13 juil. 18:17 usb-SYX-231020-J_HD_Camera-video-index0 -> ../../video5

Il faudra une fois Crowsnest réglé, ajouter la caméra dans l'interface Web (Fluidd / Mainsail ) pour qu'elle affiche son flux :

Modifié (le) Juillet 16, 2024 par fran6p

[bistory]

Salut @fran6p, en effet, il y a une erreur dans ma doc sur la THB, c'est bien un rp2040, je ne l'ai pas reflash lorsque j'ai fait le guide et il y a plusieurs mois qui se sont écoulés entre le moment où j'avais mis à jour Klipper et le moment où j'ai écrit le guide

Je vais le mettre à jour ASAP !

Concernant Armbian mis à jour, je suis en train de mettre un peu la pression à TwoTrees pour qu'ils me compilent leur logiciel qui gère l'écran pour Debian 12 car il est complètement incompatible avec

J'aimerais partager l'image disque une fois que ce sera réglé !

Pour le reste, la machine est une chouette base pour faire des trucs sympas mais TT a, comme d'hab, pas fait le taf niveau logiciel et il y a plusieurs mesquineries assez embêtantes (pas d'HDMI sur la mainboard, la gestion des ventilos est calamiteuse, les moteurs ne correspondent à rien de connu et sont configurés n'importe comment, la machine est incapable de tenir les 20k d'accel comme promis sans modification de la config, ...)

Merci à vous deux de m'avoir signalé les soucis dans la doc, c'est pour ça que j'ai mentionné qu'elle était en WIP

PS : Oui je suis aussi sur ce forum depuis bien longtemps avant la création de ma chaîne, mais FB a eu un peu raison de la peau des forums malheureusement et je ne passe plus souvent ici

[pascal_lb]

Salut @bistory effectivement on trouvait ça bizarre cette histoire de rp2040 et stm32 

J'ai vu que tu avais aussi installé un Armbian bookworm, tu en es ou ?

Ici ça avance grâce à @fran6p, la machine fonctionne, on va peaufiner les réglages

Pour l'écran, celui de la SK1 ne m'a jamais emballé, j'attend un écran BTT k-touch, il doit sortir fin juillet...

il y a une heure, bistory a dit :

PS : Oui je suis aussi sur ce forum depuis bien longtemps avant la création de ma chaîne, mais FB a eu un peu raison de la peau des forums malheureusement et je ne passe plus souvent ici

tu devrais passer de temps en temps, il y a des trucs et des gens sympas 

Modifié (le) Juillet 16, 2024 par pascal_lb

[fran6p]

Il y a 18 heures, bistory a dit :

les moteurs ne correspondent à rien de connu et sont configurés n'importe comment

Oui, j'ai vu : ils sont réglés à 1,5A pour les moteurs A / B ( X, Y) (ça me semble énorme) idem pour les moteurs Z réglés à 1 A mais pour les régler au mieux il faudrait disposer des datasheets (pour la Qidi XM3, au moins je dispose des datasheets pour A et B et l'extrudeur, celui du Z me semble erroné). Sur la Qidi, j'ai une partie des datasheets, par exemple, les moteurs X et Y sont des 1,5A (run_current à 1.07), celui de l'extrudeur est un 1.0A (run_current à 0.714). Pour le Z pas de datasheet «fiable», (run_current de 0.95 ce qui même pour piloter deux axes via synchronisation par courroie pourrait être un peu comme celui des X et Y un 1.5A (rated current))

Citation

[tmc2209 stepper_x]
uart_pin: PC0
run_current: 1.5
#hold_current: 0.5
stealthchop_threshold: 0
diag_pin:^PC1
driver_SGTHRS:90
interpolate: false

[tmc2209 stepper_y]
uart_pin: PB4
run_current: 1.5
#hold_current: 0.5
stealthchop_threshold: 0
diag_pin:^PB9
driver_SGTHRS:108
interpolate: false

[tmc2209 stepper_z]
uart_pin: PA15
run_current: 1.0
#hold_current: 0.5
stealthchop_threshold: 999999
interpolate: false

[tmc2209 stepper_z1]
uart_pin: PC11
run_current: 1.0
#hold_current: 0.5
stealthchop_threshold: 999999
interpolate: false

[tmc2209 stepper_z2]
uart_pin: PC3
run_current: 1.0
#hold_current: 0.5
stealthchop_threshold: 999999
interpolate: false

Ce serait effectivement bien que tu corriges la doc de ton dépôt (carte principale => STM32F402 (401 dans menuconfig) et RP2040 pour la tête).

Pour l'écran, j'avais le même problème après avoir passé ma Qidi XMax3 en mode open, pas de sortie HDMI sur la carte alors que le Rockchip 3328 le gère parfaitement. De nombreuses solutions sont faisables mais pas sans un gros effort / travail si on veut rester avec leur écran TJC (Nextion hors Asie), j'aborde ce sujet ici ou sur le dépôt Github associé (volontairement en français).

Il y a 18 heures, bistory a dit :

je ne passe plus souvent ici

C'est un tort car c'est ici que la bonne documentation se fait (jamais rien vu de bon sur FB ni même sur Discord, dans les deux cas, trop de prétendus «experts», à la rigueur certains posts sur Reddit… pour Klipper, le mieux c'est leur Discourse (un forum donc)), en plus ici c'est en français

Modifié (le) Juillet 17, 2024 par fran6p

[bistory]

il y a 3 minutes, pascal_lb a dit :

Salut @bistory effectivement on trouvait ça bizarre cette histoire de rp2040 et stm32 

J'ai vu que tu avais aussi installé un Armbian bookworm, tu en est ou ?

Ici ça avance grâce à @fran6p, la machine fonctionne, on va peaufiner les réglages

Pour l'écran, celui de la SK1 ne m'a jamais emballé, j'attend un écran BTT k-touch, il doit sortir fin juillet...

tu devrais passer de temps en temps, il y a des trucs et des gens sympas 

Bookworm est installé et fonctionnel, il n'y a que l'écran manquant. Tout le reste est opérationnel, il y a en plus Crowsnest, Mainsail à la place de Fluidd, Klipper Autotune (mais inutile puisqu'il manque les infos des moteurs), Shaketune, Autospeed et ma config adaptée pour qq optimisations

J'ai fait ça dans le cadre d'une ou plusieurs vidéos à venir donc ça va sortir asap !

Je suis d'accord pour l'écran, il est pas terrible et buggé mais j'essaye de rester sur le matos de base autant que possible

Oui je devrais passer plus souvent, tout comme sur facebook, sur instagram, tiktok, etc

il y a 6 minutes, fran6p a dit :

Oui, j'ai vu : ils sont réglés à 1,5A pour les moteurs A / B ( X, Y) (ça mes semble énorme) idem pour les moteurs Z réglés à 1 A mais pour les régler au mieux il faudrait disposer des datasheets (pour la Qidi XM3, au moins je dispose des datasheets pour A et B et l'extrudeur, cleui du Z me semble erroné)

Ce serait effectivement bien que tu corriges la doc de ton dépôt (carte principale => STM32F402 (401 dans menuconfig) et RP2040 pour la tête).

Pour l'écran, j'avais le même problème après avoir passé ma Qidi XMax3 en mode open, pas de sortie HDMI sur la carte alors que le Rockchip 3328 le gère parfaitement. De nombreuses solutions sont faisables mais pas sans un gros effort / travail si on veut rester avec leur écran TJC (Nextion hors Asie), j'aborde ce sujet ici ou sur le dépôt Github associé (volontairement en français).

C'est un tort car c'est ici que la bonne documentation se fait (jamais rien vu de bon sur FB ni même sur Discord, dans les deux cas, trop de prétendus «experts», à la rigueur certains posts sur Reddit… pour Klipper, le mieux c'est leur Discourse (un forum donc)), en plus ici c'est en français

J'ai fait des tests au "doigt mouillé" et les moteurs A/B prennent 1.6A sans broncher (45°C) donc ça m'a permis d'aller chercher les 20k d'accel.

Après c'est le refroidissement qui pêche, je suis en train de faire une tête d'impression pour monter un cpap mais j'en suis qu'au balbutiements...

La doc est corrigée

Allez j'essaierai de passer plus souvent mais en effet c'est surtout sur Discourse/Github/Reddit qu'on trouve les bonnes infos mais le peuple est surtout sur FB (à mon grand regret !)

[pascal_lb]

j'ai un message d'erreur et je ne comprend pas pourquoi... ça vient tout seul lorsque je me connecte

mks@mkspi:~$
Message from syslogd@mkspi at Jul 16 23:11:58 ...
 kernel:[   64.970607] Disabling IRQ #41
 

Modifié (le) Juillet 16, 2024 par pascal_lb

[bistory]

Il y a 7 heures, pascal_lb a dit :

j'ai un message d'erreur et je ne comprend pas pourquoi... ça vient tout seul lorsque je me connecte

mks@mkspi:~$
Message from syslogd@mkspi at Jul 16 23:11:58 ...
 kernel:[   64.970607] Disabling IRQ #41
 

Je l'ai aussi, ça vient des GPIO du processeur Rockchip. L'erreur vient probablement d'un driver qui ne les supporte pas...