electroremy Posté(e) Juin 13 Auteur Posté(e) Juin 13 il y a une heure, Kachidoki a dit : Tu t'es quand même vachement bien embêté la vie pour positionner la sonde. Normalement c'est buse contre le plateau et l'épaisseur approximative d'un rislan, comme ça : Oui fidéle à ma réputation "pourquoi faire simple quand on peut faire compliqué" Après je n'avais pas de rislan ni autre objet de 1.5mm de haut sous la main, en revanche j'avais ce comparateur et en vie de m'en servir il y a une heure, Kachidoki a dit : Sinon good job. Tu as pratiquement tout ce qu'il faut pour transformer ton extruder en MK3S+. En gros t'es plus très loin de la MK2.5. Quitte à réimprimer toutes les pièces, tu devrais mettre une buse renforcée et les faire en PCCF. Une chaussette silicone serait pas mal non plus vu que tu travailles toujours à des températures élevées. Oui c'est ce que je me disait aussi Après le but c'était de faire une mise à jour pas chère, et aussi... "de ne pas toucher à ce qui fonctionne" J'avais aussi une autre crainte : comme l'imprimante a 8 ans, et qu'elle a quand même fonctionné un certain temps dans une enceinte à 60°C, j'ai peur que certaines pièces soient devenues cassantes. Donc j'ai limité au maximum le démontage / remontage. Et... il faut d'abord que je remette en route mon imprimante pour pouvoir réimprimer des pièces A voir si je refais l'extrudeur... les pièces que j'avais refaites en ABS ont bien résistées, et je maitrise l'impression de ce matériaux. Je souhaite réutiliser les pièces que j'ai déjà, et si besoin, utiliser les pièces détachées du kit MMU1 (c'est pas que je sois radin, mais je n'aime pas le gâchis) Pour le moment je vais m'amuser un peu avec l'IDE Arduino et le code source du firmware. Là, je sèche un peu sur les macro dans le code (je ne maitrise pas bien cet aspect du C++) Je souhaite en profiter pour améliorer un point que je trouve très agaçant de l'interface : le réglage des températures Qu'il s'agisse de la température du lit ou de la buse, il faut régler une valeur élevée (100°C pour le bed et 200°C à 260°C pour la buse) à partir de zéro, en tournant un bouton cranté dont chaque cran augmente la température de 1°C Le code concerné utilise des macros que je ne comprends pas bien. Voici les lignes de codes qui sont appelées pour régler la température avec le fameux bouton : MENU_ITEM_EDIT(int3, MSG_NOZZLE, &target_temperature[0], 0, HEATER_0_MAXTEMP - 10);//3 MENU_ITEM_EDIT(int3, MSG_BED, &target_temperature_bed, 0, BED_MAXTEMP - 10);//4 Voici les macros que l'on trouve plus haut : /* Helper macros for menus */ #define START_MENU() do { \ if (encoderPosition > 0x8000) encoderPosition = 0; \ if (encoderPosition / ENCODER_STEPS_PER_MENU_ITEM < currentMenuViewOffset) currentMenuViewOffset = encoderPosition / ENCODER_STEPS_PER_MENU_ITEM;\ uint8_t _lineNr = currentMenuViewOffset, _menuItemNr; \ bool wasClicked = LCD_CLICKED;\ for(uint8_t _drawLineNr = 0; _drawLineNr < LCD_HEIGHT; _drawLineNr++, _lineNr++) { \ _menuItemNr = 0; #define MENU_ITEM(type, label, args...) do { \ if (_menuItemNr == _lineNr) { \ if (lcdDrawUpdate) { \ const char* _label_pstr = (label); \ if ((encoderPosition / ENCODER_STEPS_PER_MENU_ITEM) == _menuItemNr) { \ lcd_implementation_drawmenu_ ## type ## _selected (_drawLineNr, _label_pstr , ## args ); \ }else{\ lcd_implementation_drawmenu_ ## type (_drawLineNr, _label_pstr , ## args ); \ }\ }\ if (wasClicked && (encoderPosition / ENCODER_STEPS_PER_MENU_ITEM) == _menuItemNr) {\ lcd_quick_feedback(); \ menu_action_ ## type ( args ); \ return;\ }\ }\ _menuItemNr++;\ } while(0) #define MENU_ITEM_DUMMY() do { _menuItemNr++; } while(0) #define MENU_ITEM_EDIT(type, label, args...) MENU_ITEM(setting_edit_ ## type, label, (label) , ## args ) #define MENU_ITEM_EDIT_CALLBACK(type, label, args...) MENU_ITEM(setting_edit_callback_ ## type, label, (label) , ## args ) #define END_MENU() \ if (encoderPosition / ENCODER_STEPS_PER_MENU_ITEM >= _menuItemNr) encoderPosition = _menuItemNr * ENCODER_STEPS_PER_MENU_ITEM - 1; \ if ((uint8_t)(encoderPosition / ENCODER_STEPS_PER_MENU_ITEM) >= currentMenuViewOffset + LCD_HEIGHT) { currentMenuViewOffset = (encoderPosition / ENCODER_STEPS_PER_MENU_ITEM) - LCD_HEIGHT + 1; lcdDrawUpdate = 1; _lineNr = currentMenuViewOffset - 1; _drawLineNr = -1; } \ } } while(0) Ce que je comprends, c'est que MENU_ITEM_EDIT est une macro qui permet de régler une valeur avec le bouton, avec une valeur maxi et une valeur mini. Pour moi ce n'est pas très clair, je ne maitrise pas bien les macros en C++ Si j'avais écris ce code, j'aurais utilisé des fonctions à la place de ces macros. Je voudrais changer le comportement pour le réglage de la température du lit (bed) et de la buze (nozzle) pour avoir des fonctions séparées, mais je ne sais pas comment réécrire ces fonctions séparément (donc sans macro) pour ensuite les modifier Une fois ce travail de réécriture faite, ce sera facile de faire ce que je veux, à savoir : Pour la température de la buse : quand elle est à zéro (démarrage de l'imprimante ou arrêt de l'impression), que dès le premier clic de rotation du bouton dans le sens des aguilles d'une montre je passe directement à 180°C - et inversement, si je tourne le bouton dans le sens anti-horaire, que ça passe à zéro juste après 180° Pour la température du lit : avoir des pas de 5°C jusque 95°C et ensuite avoir des pas de 1°C Et bien sûr, ajouter un menu pour régler la température de l'enceinte (mais il faudra aussi que je permette au GCODE de préciser la température de l'enceinte, ce qui implique également de créer un nouveau profil d'imprimante dans Prusa Slicer) Je pense également changer l'agencement des menus et sous-menus, les fonctions que j'utilise souvent sont dans des menus différents c'est casse-pied. Il s'agit aussi de préserver la durée de vie du fameux bouton rotatif.
electroremy Posté(e) Juin 15 Auteur Posté(e) Juin 15 (modifié) Bonjour, J'ai trouvé comment modifier le code pour prendre en charge un capteur de filament, il n'y a pas grand chose à faire, car le code nécessaire est déjà présent il suffit de l'activer comme expliqué ici : https://www.thingiverse.com/thing:5136321 J'ai flashé le firmware de mon imprimante : tout fonctionne correctement, la sonde SUPERPINDA est prise en charge, le préchauffage de la PINDA ne se fait plus, et le capteur de filament fonctionne (si le filament n'est plus détecté l'imprimante lance des bips et la commande de changement de filament) Mais la joie fut de courte durée. J'ai continué à travailler sur le firmware, mais tout nouveau flashage échoue. J'ai redémarré l'imprimante, redémarré l'ordinateur, c'est toujours la même erreur "vérification error, first mismatch at byte 0x3c000 0x22 != 0xbb" Et bien sûr, impossible d'utiliser l'imprimante, qui ne fonctionne plus. Le microcontrôleur de ma carte RAMBo1.3a serait-il déjà mort ? Si c'est le cas, il faut remplacer toute la carte (le microcontrôleur étant un boiter CMS soudé avec de nombreuses broches) Je n'avais mis à jour le firmware que 2 ou 3 fois... avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex" avrdude-slic3r: writing flash (253318 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 43,53s avrdude-slic3r: 253318 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex contains 253318 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 32,41s avrdude-slic3r: verifying ... avrdude-slic3r: verification error, first mismatch at byte 0x3c000 0x22 != 0xbb avrdude-slic3r: verification error; content mismatch avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. Ici une personne a eu le même soucis que moi en 2018 (erreur à la même adresse) https://forum.prusa3d.com/forum/original-prusa-i3-mk2-s-hardware-firmware-and-software-help/firmware-flashing-fails-stk500v2-command-command-failed-verification-error-content-mismatch/ mais pas de réponse à son post, dommage Après d'autres recherches : Le problème pourrait venir de la première mise à jour du firmware qui aurait écrasé le bootloader, ce qui empêche ensuite de mettre à nouveau à jour le firmware C'est assez tordu car la première mise à jour se passe bien, donc on ne pense pas que le problème vient de là. https://github.com/prusa3d/Prusa-Firmware/issues/910 https://arduino.stackexchange.com/questions/52798/avrdude-verification-error https://github.com/MarlinFirmware/Marlin/issues/17598 https://forum.prusa3d.com/forum/original-prusa-i3-mk2-s-hardware-firmware-and-software-help/failure-to-flash-self-compiled-firmware/ https://reprap.org/forum/read.php?13,824293,824442 Bonne nouvelle, ma carte mère n'est pas HS Il faut maintenant trouver la manip pour soit restaurer le bootloader, soit flasher le firmware en se passant de bootloader A bientôt J'ai retrouvé dans mes affaires un USBasp qui permet de programmer des Arduino directement via leur port ICSP Mais il n'est pas détecté sur mon ordinateur... Je tente autre chose : reflasher le firmware original de l'imprimante 1_75mm_MK2-RAMBo13a-E3Dv6full.hex avec PrusaSlicer Surprise : ça fonctionne (mais je ne sais pas pourquoi) avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\1_75mm_MK2-RAMBo13a-E3Dv6full.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\1_75mm_MK2-RAMBo13a-E3Dv6full.hex" avrdude-slic3r: writing flash (245286 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 42,97s avrdude-slic3r: 245286 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\1_75mm_MK2-RAMBo13a-E3Dv6full.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\1_75mm_MK2-RAMBo13a-E3Dv6full.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\1_75mm_MK2-RAMBo13a-E3Dv6full.hex contains 245286 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 31,42s avrdude-slic3r: verifying ... avrdude-slic3r: 245286 bytes of flash verified avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. Bonne nouvelle l'imprimante n'est pas HS Et le bootloader serait donc intact (sinon, impossible de charger le firmware d'origine) Je me dis que le firmware original a dû remettre l'imprimante dans un état correct. Je tente alors de flasher mon firmware Et j'ai la même erreur : avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex" avrdude-slic3r: writing flash (253318 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 43,53s avrdude-slic3r: 253318 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex contains 253318 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 32,44s avrdude-slic3r: verifying ... avrdude-slic3r: verification error, first mismatch at byte 0x3c000 0x02 != 0xbb avrdude-slic3r: verification error; content mismatch avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. A noter la différence de taille : 1_75mm_MK2-RAMBo13a-E3Dv6full.hex : 689 952 octets Firmware.ino.rambo.hex : 712 542 octets Mais là où c'est incompréhensible, c'est que mon firmware personnalisé avait quand même fonctionné UNE SEULE FOIS. Donc, ce premier flashage de mon firmware personnalisé à "abîmé" quelque chose qui empêche de le charger encore... Mais qui n'empêche pas de charger le firmware d'origine, sans que le chargement de ce firmware d'origine restaure ce qui avait été abîmé EDIT : Je pensais avoir trouvé une solution : Un warning me disait dans l'IDE Arduino que le fichier stk500boot_v2_mega2560.hex était manquant dans arduino-1.6.13\hardware\marlin\avr\bootloaders J'ai trouvé et placé le fichier manquant, et obtenu un fichier Firmware.ino.with_bootloader.rambo.hex Mais quand je flash ce fichier dans l'imprimante, j'ai toujours cette erreur : avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex" avrdude-slic3r: writing flash (261406 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 44,57s avrdude-slic3r: 261406 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex contains 261406 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 33,36s avrdude-slic3r: verifying ... avrdude-slic3r: verification error, first mismatch at byte 0x3c000 0x02 != 0xbb avrdude-slic3r: verification error; content mismatch avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. Modifié (le) Juin 15 par electroremy
electroremy Posté(e) Juin 15 Auteur Posté(e) Juin 15 Nouvelle tentative : réduire le code... J'ai trouvé une façon efficace de le faire : retirer les langues pour ne laisser que l'anglais. De toutes façon la MK2s ne proposait pas le Français 100 Ko de gagnés quand même ! Alors là, c'est bizarre : Si je flash la version avec Bootloader (Firmware.ino.with_bootloader.rambo.hex - 607 ko) j'ai une erreur... mais l'imprimante fonctionne correctement y compris avec mes modifications avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex" avrdude-slic3r: writing flash (261406 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 38,01s avrdude-slic3r: 261406 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.with_bootloader.rambo.hex contains 261406 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 27,98s avrdude-slic3r: verifying ... avrdude-slic3r: verification error, first mismatch at byte 0x3e1b9 0x79 != 0x72 avrdude-slic3r: verification error; content mismatch avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. En revanche, si je flash la version sans bootloader (Firmware.ino.rambo.hex - 600 ko), le flashage est un succès, et tout fonctionne correctement bien sûr : avrdude-slic3r -v -p atmega2560 -c wiring -P COM4 -b 115200 -D -U flash:w:0:C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex:i avrdude-slic3r: Version 6.3-20160220-prusa3d, compiled on Apr 10 2025 at 13:39:24 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch Using Port : COM4 Using Programmer : wiring Overriding Baud Rate : 115200 AVR Part : ATmega2560 Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PA0 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Wiring Description : Wiring Programmer Model: AVRISP Hardware Version: 15 Firmware Version Master : 2.10 Vtarget : 0,0 V SCK period : 0,1 us avrdude-slic3r: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0,01s avrdude-slic3r: Device signature = 0x1e9801 (probably m2560) avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: reading input file "C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex" avrdude-slic3r: writing flash (218386 bytes): avrdude-slic3r: stk500v2_command(): command failed Writing | ################################################## | 100% 38,01s avrdude-slic3r: 218386 bytes of flash written avrdude-slic3r: verifying flash memory against C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: load data flash data from input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex: avrdude-slic3r: input file C:\OneDrive\DATA\DONNEES\_Impr3D\SuperPinda_MK2s\Prusa-Firmware-3.2.3\Firmware\Firmware.ino.rambo.hex contains 218386 bytes avrdude-slic3r: reading on-chip flash data: Reading | ################################################## | 100% 27,99s avrdude-slic3r: verifying ... avrdude-slic3r: 218386 bytes of flash verified avrdude-slic3r: safemode: hfuse reads as D0 avrdude-slic3r: safemode: efuse reads as FD avrdude-slic3r: safemode: Fuses OK (E:FD, H:D0, L:FF) avrdude-slic3r done. Thank you. Donc problème résolu... mais je ne sais pas pourquoi Une chose à noter : le flashage de mon firmware n'oblige pas l'utilisateur à refaire la calibration. Autre truc bizarre : le code suivant pour faire un "pullup" ne fonctionne pas : #define FR_SENS 20 ... #ifdef FILAMENT_RUNOUT_SUPPORT SET_INPUT(FR_SENS); WRITE(FR_SENS,HIGH); #endif J'ai connecté le capteur de filament entre le 0V (GND) et l'entrée SDA Lorsque le filament est présent, l'imprimante le prend en compte (dans le menu Calibration -> Show end stops, j'ai bien "FIL0" qui s'affiche) Mais quand le filament n'est plus là ou bien que je débranche le capteur, l'affichage hésite rapidement entre "FIL0" et "FIL1" L'instruction WRITE(FR_SENS,HIGH) n'active donc pas le pullup ; il faudra que j'ajoute une résistance manuellement
Kachidoki Posté(e) Juin 16 Posté(e) Juin 16 Salut @electroremy, J'imagine les montagnes russes chez toi. ^^ Je n'ai pas encore regardé pour ton souci de bootloader (d'ailleurs il ne devrait jamais être touché pour ne pas "bricker" la carte), mais pour la pullup tu ne devrais pas plutôt utiliser SET_INPUT_PULLUP(PIN) ? Là j'ai l'impression que tu configure la PIN en entrée simple et que derrière tu écris dedans.
electroremy Posté(e) Juin 16 Auteur Posté(e) Juin 16 il y a une heure, Kachidoki a dit : Salut @electroremy, J'imagine les montagnes russes chez toi. ^^ Avec l'habitude (nombre de projets électroniques foirés après des heures de travail) ça ne fait plus rien... au pire j'aurais trouvé une RAMBo1.3a d'occasion Après, c'est quand on en chie qu'on apprend des choses, quand ça fonctionne trop "facilement" on n'apprend rien, et c'est presque frustrant - pour que ce soit intéressant il faut une sorte d'équilibre c'est à dire en baver un peu mais pas trop quand même il y a une heure, Kachidoki a dit : Je n'ai pas encore regardé pour ton souci de bootloader (d'ailleurs il ne devrait jamais être touché pour ne pas "bricker" la carte), Je pense que Prusa a bien fait les choses et a protégé la carte contre les fausses manip, avec un bootloader maison. il y a une heure, Kachidoki a dit : pour la pullup tu ne devrais pas plutôt utiliser SET_INPUT_PULLUP(PIN) ? Là j'ai l'impression que tu configure la PIN en entrée simple et que derrière tu écris dedans. Etant fatigué je me suis contenté de faire un copié-collé du code trouvé sur le Thingiverse sans trop regarder A noter qu'avec ce câblage, la led intégré du capteur Dual Sensor Guard acheté il y a des années chez Hotends.fr ne fonctionne pas (la polarité est inversée) - mais c'est mieux car si un fil se coupe ou si le capteur se débranche, l'imprimante se met en sécurité. De plus, j'ai juste à câbler les broches GND et l'entrée, ne pas apporter le +5V au capteur limite les risques de court circuit éventuels. Hotends continue toujours à vendre ce capteur https://hotends.dozuki.com/c/Capteur_Dual_Guard_Sensor - à l'époque j'avais déjà la version équipée des petits morceaux de tube PTFE. Il faudra que je le fixe à la bonne position par rapport à mon support de bobine pour que le capteur se déclenche en cas de noeud dans la bobine. A voir si ce capteur est compatible avec le TPU. J'ai aussi acheté pour quelque euros un lot de 10 CTN 100K 1% sur Amazon, ainsi que des résistances de puissance pour le chauffage que je vais monter sur des morceaux de tôle alu (car les plaques de véroboard que j'utilisaient comme résistance ont trop chauffé, et finalement des résistances de puissance "normales" coutent moins cher)
electroremy Posté(e) Juin 23 Auteur Posté(e) Juin 23 Bonjour, Quelques nouvelles Ca avance, j'ai pu modifier le firmware pour mesurer la température de l'enceinte, l'afficher et modifier la consigne avec l'écran de l'imprimante et son bouton rotatif. Je dois encore programmer la régulation de température. Plusieurs autres idées sont venues : - sécurité en cas de panne ou de coupure de thermistance - renvoit des alarmes vers un circuit externe pour être prévenu depuis une autre pièce - autoexinction à la fin de l'impression et du refroidissement... Pour faciliter la mise au point, j'ai "sortit" tous les entrées/sorties non utilisées de la carte RAMBO sur une plaquette d'essai, et aussi fait passer les connexions des thermistances de la buse et du lit sur cette plaque (ce qui me permet de simuler facilement des défauts, pour vérifier si mes modifications du firmware les détectent) : La carte RAMBO ne pourra pas tout gérer, il faut un boitier électronique au niveau de l'enceinte... qui existe déjà d'ailleurs mais tout est séparé : éclairage, refroidissement carte mère et alimentation, résistances chauffantes, alimentation 12V pour les ventilo et l'éclairage, alimentation de labo pour le chauffage J'aimerais aussi ajouter des capteurs de températures pour éviter une surchauffe de la carte RAMBO, de l'alimentation de l'imprimante, du caisson et aussi une redondance (histoire d'utiliser le lot de thermistances achetées) Je pensais faire une carte analogique "électronique à Papa" mais j'arrive vite à un cimetière avec de nombreux amplificateurs opérationnels, quantité de composants discrets et un affichage rudimentaire à base de LED... de plus les fonctionnalités de ce type de cartes sont figées donc la conception du schéma et les tests sur carte prototype doivent être faits avec soin, pour être sûr de ne rien oublier... J'ai donc cédé au "modernisme" et je vais utiliser une carte Arduino UNO avec un écran graphique tactile. J'en ai déjà plusieurs en stock, acheté pour mon projet domotique qui est en stand by : La partie analogique sera très réduite (pour relier les entrées de l'Arduino aux capteurs et à l'imprimante 3D, et les sorties de l'Arduino et de l'imprimante 3D aux "actionneurs"). Il sera possible de faire évoluer les fonctionnalités juste en modifiant le code source de l'Arduino et le firmware de l'imprimante. Avantage : je ne pars pas de zéro car pour le projet domotique j'avais pas mal bossé en réécrivant une grande partie des bibliothèques qui gèrent l'écran graphique et sa dalle tactile - y compris le code de calibration de la dalle tactile que j'ai pu intégrer au code du projet (car de base avec ces écrans tactiles, il faut téléverser un sketch de calibration, puis calibrer l'écran, et ensuite téléverser le sketch du projet). Je tâcherais quand même de veiller à une certaine sécurité, notamment pour que les courts-circuits ou les coupures des sondes et capteurs soient détectés, et quelques astuces dans le cheminement du câblage pour qu'une coupure d'alimentation se fasse dans le sens de la sécurité. Je pense aussi ajouter un "watchdog" analogique pour vérifier que mon Arduino et l'imprimante 3D ne sont pas plantés ; concrétement, dans la procédure qui vérifie périodiquement les températures, je vais ajouter une instruction qui change l'état d'une sortie digitale, qui va donc clignoter. Le watchdog sera un circuit analogique simple à base de temporisation réinitialisées par ces changements d'état. En cas de plantage, la sortie ne clignotera plus et le watchdog coupera la puissance. On déborde du projet initial qui consistait à "seulement" remplacer la PINDA V1 par une SUPERPINDA, mais en même temps c'est l'occasion de faire des améliorations que j'avais imaginé mais laissé de côté. Et c'est aussi l'occasion de mener enfin à terme un projet électronique avec Arduino et écran graphique tactile, et rentabiliser les heures de travail passer dessus. En effet j'avais quasiment terminé la partie logicielle et interface Arduino/Ecran tactile du projet domotique, mais c'est en pause car je dois faire plein d'autres travaux avant... et finalement d'autres technologies domotiques sembles plus intéressantes... c'était frustrant d'abandonner ce travail, mais grâce à l'imprimante 3D je trouve une utilisation. 1
Kachidoki Posté(e) Juin 24 Posté(e) Juin 24 Quel projet en perspective. J'ai quelques "remarques" même si ç'en est pas vraiment car c'est ton projet . Il y a 7 heures, electroremy a dit : Je pense aussi ajouter un "watchdog" analogique pour vérifier que mon Arduino et l'imprimante 3D ne sont pas plantés Tu parles de watchdog analogique, mais les MCU possèdent déjà un watchdog, pourquoi ne conviendrait-il pas ? En soft et notamment lorsqu'on utilise des OS où il est pratiquement impossible de s'assurer que toutes les tâches tournent avec un seul watchdog, on utilise des mécanismes logiciels. Il y a plusieurs façons de procéder, mais le principe c'est d'avoir un timer logiciel par tâche ou fonction à surveiller. Le reset du vrai watchdog se fait en un point unique, généralement dans la boucle principale, conditionné par un flag. Si l'un des timers arrive à échéance alors le flag est positionné et le reset du vrai watchdog n'est plus effectué. On peut aussi forcer directement un reset, mais certains micro donnent la possibilité de connaître la cause du reset dans un registre, ça peut servir au redémarrage pour prendre une décision particulière. Il y a 7 heures, electroremy a dit : La carte RAMBO ne pourra pas tout gérer, il faut un boitier électronique au niveau de l'enceinte... Si tu passes sur une architecture "multi-cpu", il faudra veiller à blinder la communication avec parité/checksum, acquittement et répétitions. Par expérience professionnelle ce n'est jamais simple à blinder correctement lorsqu'on arrive dans des cas éloignés du nominal et/ou avec des longueurs de câble (Prusa en a fait les frais sur son xLCD). Du coup tu te rapproches d'un klipper en séparant les fonctions, ça pourrait être une autre approche qui te simplifierait ces aspects pour te laisser te concentrer sur le code utile. Ca a l'avantage par exemple de rendre ton caisson compatible avec n'importe quelle imprimante qui tournerait sous kilpper. Il y a 7 heures, electroremy a dit : J'ai donc cédé au "modernisme" et je vais utiliser une carte Arduino UNO avec un écran graphique tactile. Une autre suggestion qui va pas te plaire : vu où tu en es pourquoi pas changer carrément de carte mère au profit d'une carte mère 32-bit "moderne" ? Avec ça tu aurais une toute nouvelle machine, silencieuse comme une MK3 et rapide comme une MK4. En bonus, beaucoup de ressources pour ajouter toutes les fonctions que tu veux. Il y a 7 heures, electroremy a dit : Et c'est aussi l'occasion de mener enfin à terme un projet électronique avec Arduino et écran graphique tactile, et rentabiliser les heures de travail passer dessus. En effet j'avais quasiment terminé la partie logicielle et interface Arduino/Ecran tactile du projet domotique, mais c'est en pause car je dois faire plein d'autres travaux avant... et finalement d'autres technologies domotiques sembles plus intéressantes... c'était frustrant d'abandonner ce travail, mais grâce à l'imprimante 3D je trouve une utilisation. Je pense que tout bon développeur passe par là, on se lance dans un projet passionnant, on y passe un temps fou, des nuits blanches... Soit on arrive au bout parce que c'était un vrai projet utile, soit on s'arrête presque à la fin parce que c'était juste pour le fun. Quand j'étais ado j'ai passé un temps fou à concevoir un annuaire pour les VHS de mes parents, avec un PIC et un LCD alphanumérique. Je suis arrivé presqu'au bout, mais le micro était plein et n'avait plus assez d'espace pour stocker toutes les chaines de caractères. Mais j'ai appris le fonctionnement des écrans LCD et des claviers matriciels, joué avec de la compression pour le texte etc... Et c'est bien là l'essentiel => L'important n'est pas de pouvoir réutiliser le travail effectué, mais surtout de pouvoir réutiliser les connaissances et l'expérience cumulées lors de ces projets, pour développer les projets suivants en repartant sur de meilleures bases encore.
electroremy Posté(e) Juin 24 Auteur Posté(e) Juin 24 (modifié) Bonjour, Alors non ce ne sera pas vraiement "mutli-CPU", l'Arduino UNO va juste gérer l'enceinte de manière quasi indépendante. La communication entre l'imprimante et l'Arduino UNO sera rudimentaire et unidirectionnelle (imprimante 3D-> Arduino UNO Enceinte) : - une sortie "alarme" - une sortie "demande autoextinction" - deux sorties "commande chauffage" L'Arduino UNO va, en plus, gérer des sondes de température supplémentaires pour surveiller "l'état de santé" des composants de l'enceinte et de l'imprimante Je souhaite conserver la carte RAMBO. Je souhaite à la base conserver un maximum de composants d'origine de la MK2s, pour faire évoluer cette imprimante à cout minimal ; d'autres personnes pourraient reprendre mon firmware pour faire évoluer leur MK2s avec des modifications simples et peu couteuses mais tout de même utiles: - sonde SUPERPINDA à la place de la PINDA V1 - capteur de filament - mise à jour "gratuite" du firmware pour détecter les coupures de thermistances malgrès les défauts de la carte RAMBO qui n'arrive pas à lire des températures basses La gestion de l'enceinte chauffée, la broche de sortie pour une alarme externe, la broche de sortie "autoextinction", le chien de garde analogique sont des bonus facultatif ; mon firmware pourra tourner sans que ces fonctionnalités soient utilisées. Je serais content si mon projet permet à des makers de donner facilement et pour un cout modique une seconde vie à des MK2s qui dorment dans des placards. Si les modifications sont trop importantes, trop compliquées et top chères, on retombe dans l'évolution MK2.5s+ ; et là ce sera plus rentable de changer d'imprimante (pas forcément une Prusa d'ailleurs...) S'agissant du chien de garde, avoir un chien de garde physiquement externe au CPU permet aussi de détecter une défaillance matérielle du CPU. C'est une approche "ceinture et bretelles" mais c'est un truc que j'ai envie de faire... et comme ça j'ai quand même un petit bout "d'électronique à papa" dans mon projet. Ca reste un loisir, j'utilise des composants que j'ai déjà en stock, et que je sais utiliser. Ce n'est pas un "vrai" projet destiné à être rentable ou commercialisé, les choix des composants et des technologies ne seraient pas du tout les mêmes. Modifié (le) Juin 24 par electroremy
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant