Aller au contenu

GO Print

PierreG

Membres
  • Compteur de contenus

    961
  • Inscrit(e) le

  • Dernière visite

  • Jours remportés

    1

6 abonnés

À propos de PierreG

  • Date de naissance 01/01/1961

Information

  • Genre
    Masculin
  • Lieu
    Québec
  • Intérêts
    Bricolage du bois et des matières. Programmation informatique. Camping.
  • Imprimantes
    Voron 2.4 R2
    CR-10 V3

Visiteurs récents du profil

1 713 visualisations du profil

Récompenses de PierreG

Experienced

Experienced (11/14)

  • One Year In
  • Posting Machine Rare
  • Very Popular Rare
  • Reacting Well Rare
  • Dedicated

Badges récents

341

Réputation sur la communauté

1

Sujets solutionnés !

  1. @Savate Finalement, le problème était situé au niveau du moteur et du fil Z. Une fois le moteur et le fil remplacé, tout est rentré dans l'ordre... Bizarre, mais au final tout est bien qui finit bien !!
  2. Hello @Savate il me semblait qu'un BLTtouch qui clignote c'est parce qu'il est en erreur ??
  3. Bonne journée à vous chers amis. Je suis à aider un ami a transférer sa Ender 3 sur Klipper, et je suis coincé avec un bug. Il a installé une SKR 1.2 dans son imprimante, et un BLTouch. Mais quand je veux faire fonctionner le BLTouch, je n'arrives pas à trouver les bons parametres. Voici les parametres pour le BLTouch: [bltouch] sensor_pin: P1.25 control_pin: P2.0 pin_up_reports_not_triggered: True pin_up_touch_mode_reports_triggered: False x_offset: -43 y_offset: -6 z_offset: 1 samples:2 [safe_z_home] home_xy_position: 156, 116 speed: 300 z_hop: 8 z_hop_speed: 5 En utilisant le mode DEBUG de Klipper, voici la séquence pour tester le BLTouch que j'utilises : 1-BLTOUCH_DEBUG COMMAND=touch_mode 2-BLTOUCH_DEBUG COMMAND=pin_down Le pointeau descend bien 3-QUERY_PROBE Réponse : OPEN 4-il pousse le pointeau vers le haut Le pointeau remonte, le BLTouch clignote en rouge, et Query_probe répond TRIGGERED J'ai tenté de mettre ^ devant le P1.25, mais en faisant ca, le moteur Z bloque et refuse de bouger. J'ai chercher sur le web, et c'est varié comme solution... quelque uns doivent mettre le ^ , et d'autres ont ajoutés les lignes pin_up_reports, supposéement pour les clones de BLTouch Auriez-vous une piste à me suggérer pour régler ce problème ?? P.S. On a bien mis dans [stepper_z] la ligne endstop_pin: probe:z_virtual_endstop Merci d'avance
  4. Sur mon Pi ( Pi 4 B 8Go RAM) je n'ai que deux ports utilisés, le U2C et la carte Octopus. Je vais valider ce point... Comme mentionné plus haut, j'ai un Raspberry Pi 4 avec 8 Go de RAM... Il a toujours tres bien fonctionné depuis un an... J'y avais pensé... c'est certain que de retirer le U2C ferait un peu de place sous la bête !!! Je me posais aussi la question si ce n'était pas la derniere version de Klipper qui pouvait foutre le trouble... j'avais upgradé à la derniere version, mais j'ai du faire machine arriere parce qu'il se passait toute sorte de bizarreries avec l'imprimante !!! En ce moment, je suis sous la v0.12.0-0-g0d67d9c4. Autre élément que j'ai remarqué hier soir lors d'une tentative d'impression... dans Fluidd, j'ai 6 graphs qui me donne l'état de différents éléments.. l'un deux me donne la charge de Klipper (la charfe du Pi d'une certaine facon ??), et juste avant le shutdown, le graph me montre des charges allant jusqu'à 150 % alors que tout le reste demeure très bas... J'avoue ne pas avoir trop d'idée où chercher pour trouver cette surcharge momentanée !!!
  5. Bonjour à vous.... Depuis plusieurs jours, je recois une erreur lors de mes impressions: "MCU 'CanBus' shutdown: Timer too close" Le Canbus en question est ma tete stealthburner qui est drivé par un EBB SB2209, branché à un module U2C, lui-même branché en USB à mon RPi. D'apres plusieurs lecture trouvée sur le web, ca peut etre causé par une surcharge de mon RPi, ou d'un problème de communication (coupures). J'ai vérifié la charge du RPi sur Fluidd, et je nai jamais atteint plus de 3% avant le shutdown. Ma carte SD est à 50% (16Go). J'ai essayé de changer le sports USB, ou cas où ca serait dû à un faux contact du connecteur. Je ne sais donc plus trop quoi vérifier. Si quelqu'un a une ou des pistes, je suis preneur !!! Je joins mon fichier klippy.log. Merci à l'avance. klippy.log.txt
  6. Bonjour chers amis !! Après plusieurs recherches, et surtout, apres avoir visionné des dizaines de vidéos sur Youtube (j'en ai les deux yeux dans le meme trou à force), j'ai fini par comprendre la patente... Il me fallait tout d'abord installer un bootloader sur le SB2209, pour que l'écriture du fichier BIN puisse se faire via Canboot (maintenant appelé Katapult) Donc en gros: 1- on installe Katapult sur le Pi, et on créé le fichier katapult.bin; 2-on flash le SB2209, en USB, en utilisant les outils de Katapult; 3-On créé le fichier klipper.bin; 4-On flash le SB2209 via Canbus. Je vais refaire la manipulation pour etre bien certain que tout est OK, et je mettrai ma procédure ici pour ceux que ca interresse !! Mes deux références pour y arriver : https://github.com/Esoterical/voron_canbus/tree/main/toolhead_flashing youtube.com/watch?v=oet_vidHm7c Bonne journée.....
  7. Bonne journée à vous les amis... Il y a eu une mise à jour récente de Klipper, qui est passée de la version 0.11 à 0.12 je crois. J'ai mis ma Voron à jour, mais je recois le message que mes deux MCU (carte mère Octopus et SB2209) doivent également être mis à jour. Pour ce qui est de la carte mere, ca se passe très bien... je recompile un klipper.bin, je le met sur une carte SD, et je redémarre ma carte sur la carte SD... Bingo, c'est réglé. Mais pour mon SB2209, qui est branché à mon Pi via un U2C, ca ne passe pas comme lettre à la poste. J'aimerais bien pouvoir le mettre à jour en utilisant la liaison Canbus mais après plusieurs essai, ca ne fonctionne pas. J'ai tenté cette procédure : https://github.com/Esoterical/voron_canbus/blob/main/Updating.md#updating-toolhead-klipper Ca semble assez complet, mais je n'arrive pas à flasher le SB2209. Quelqu'un a-til déjà réussi à flasher de cette facon ?? Merci d'avance !!
  8. Pas vraiment... Mais tu peut te servir des fichiers de config (configuration.h , configuration_adv.h et plateformeio.ini) pour modifier la nouvelle version de Marlin.... Dans la version que je t'avais envoyé, j'avais mis mes initiales à la fin de chaque ligne que j'ai modifiées.
  9. @Macktool Salut confrère... Je ne connais pas tant le Orange Pi, mais il doit probablement ressembler au Raspberry Pi dans son mode de fonctionnement... Je te suggèrerais de laisser de côté la carte SD fournie avec ton kit, et de remonter un OS complètement neuf et propre pour ta Voron 2.4 sur une nouvelle carte SD de tres bonne qualité (une 16 Go est amplement suffisant pour l'OS et les fichiers Gcodes) Je te fourni ma procédure d'installation dans le fichier texte ci-joint. Tout est là, pour faire fonctionner ma Voron 2.4. Pour te connecter au Pi, tu dois utiliser SSH avec Putty sur ton ordi (à voir si le kit fournis les identifiants, sinon essai user : pi mdp: raspberry Installation Voron.txt
  10. Juste pour que ca soit plus limpide... Certains capteurs de filamant possèdent deux fonctions: - Présence d'un filament - Mouvement du filament La présence de filament (tous les capteurs de filament ont au minimum cette caractéristique) détermine si tu es arrivé à la fin de ta bobine de filamant, ou que ton filament s'est cassé en amont du capteur. Dans un cas comme dans l'autre, ton capteur va envoyer un signal pour signaler que ton extrudeur va tomber a sec d'ici peu. C'est la portion [filament_switch_sensor mon_capteur]. Le mouvement de filamant tant qu'à lui, va détecter si le filament arrête d'avancer durant l'impression. Ca peut être provoqué par un bourrage de l'extrudeur, ou une cassure du filament entre le capteur et l'extrudeur. C'est la portion [filament_motion_sensor mon_capteur] qui va gérer cela. Dans ton cas, ton capteur ne gère que la présence d'un filament, et va signaler l'absence de celui-ci dans le capteur. Ca ne dérange pas de laisser le code pour le [filament_motion_sensor], mais comme celui-ci ne sera jamais sollicité, ca ne fais qu'encombrer ton code, et pourrait porter à confusion pour quelqu'un d'autre qui lirais ton printer.cfg.
  11. Pour corriger le problème créé par Debian, ouvre une fenettre SSH sur ton pi et fais les 3 commandes suivantes : sudo cp /usr/lib/udev/rules.d/60-serial.rules /usr/lib/udev/rules.d/60-serial.old sudo wget -O /usr/lib/udev/rules.d/60-serial.rules https://raw.githubusercontent.com/systemd/systemd/main/rules.d/60-serial.rules sudo reboot Si ton Debian est problématique, ca devrait le régler (en tout cas ca le fait très bien avec mon RPi)
  12. Bon matin tous le monde (enfin, bonne fin d'après-midi pour la majorité d'entre vous ) Concernant ce sujet, notre ami Le GüeroLoco a fait une entrevue fort intérressante il y a un mois de celà... Il a rencontré un chercheur en santé environnementale et au travail, de l'Université de Montréal, Ludwig Vinches. La vidéo dure 53 minutes, mais elle est fort instructive. En conclusion, un filtre au charbon pour éliminer les COV (composés organiques volatils), et un filtre HEPA pour éliminer les particules ultra-fines. Bonne écoute !!
  13. @RicoDarksky Comme l'a mentionné @fran6p, la premiere partie de ton code, soit celle concernant le filament_motion_sensor, c'est inutile. Ton capteur ne détecte que la présence de filament. Ici, petite correction à effectuer : [filament_switch_sensor toolhead_runout] switch_pin: ^!P1.25 pause_on_runout: True # Va effectuer une pause avant d'éxécuter le runout_gcode runout_gcode: M117 Fin de Filament # déplacer avant le lancement de M600, sinon le message risque d'apparaitre apres le changement de filament SET_FILAMENT_SENSOR SENSOR=0 # désactive le détecteur pour éviter des ON/OFF répété et des comportements aléatoires de Klipper M600 # manque un 0 insert_gcode: M117 Filament insere SET_FILAMENT_SENSOR SENSOR=1 # je le met ici, mais il serait préférable de l'inclure dans ta macro RESUME ! et finalement : [gcode_macro M600] description: Filament change gcode: PAUSE Y=10 ; everything needed is defined there # placer sous gcode: et avec minimum deux espaces devant le code ! G91 G1 E-10 F1500 # tu pourrais placer une ligne qui va retirer ton filament de l'extrudeur (ajuster la longueur de 10mm selon la tete) G90 Voilà.... Fran6P pourra compléter ou corriger au besoin !!
  14. @fran6p Effectivement, j'ai vu ces deux macros et leur utilité. Lors de mes tests je n'ai pas eu de problèmes de foot-ware mais je vais les ajouter, par prévention !!! J'ai vu qu'on utilisait ces macros pour mettre le détecteur "EN" lors du print_start, et le mettre "HORS" lors du end_start et cancel_print !
  15. @RicoDarksky @hyoti Je "+1" avec @fran6p Je viens tout juste d'installer un BTT smart filament sensor V2.0, et mon codage dans printer.cfg est celui-ci : Détection de présence de filament [filament_switch_sensor switch_sensor] switch_pin: ^PG12 #Connecteur STOP06 sur carte Octopus 1.0 pause_on_runout: False runout_gcode: M600 M117 Fin de Filament insert_gcode: M117 Filament insere #Détecteur de mouvement du détecteur BTT [filament_motion_sensor filament_sensor] switch_pin: ^PG13 #Connecteur STOP07 sur carte Octopus 1.0 detection_length: 5 extruder: extruder pause_on_runout: False event_delay: 3.0 pause_delay: 1.0 #0.5 runout_gcode: M117 Runout Detected! runout_gcode: M600 M117 Filament coince insert_gcode: M117 Filament insere Pour le moment, je n'ai pas besoin de macros pour traiter les autres particularités du détecteur de filament. Il me reste plus qu'a trouver le moyen de retarder la mise en pause, pour que l'extrudeur consomme du filament, et éviter la perte de près de 600 mm de filament (distance en le détecteur et la buse sur une Voron 2.4) P.S. Je n'ai pas besoin de mettre pause_on_runout à true, puisque de toute facon, l'appel a la pause est intégrée dans ma macro M600
×
×
  • Créer...