electroremy

L'imprimante doit être énorme... bon c'est facile je critique mais en même temps le ratio volume imprimable / taille extérieure doit être nettement meilleur que ma MK2s et son caisson Je trouve que les deux fichiers que tu a testé sont très bien (le torture test et le Z max) Pour les matériaux... au hasard... de l'ABS standard (l'ABS basique, et pas les formules améliorées) Les autres membres du forum s'y connaissent mieux que moi en filaments techniques et difficiles à imprimer Surtout que la H2C est dans la gamme des imprimantes techniques Sinon le "Z max" en TPU en monobuse ce serait rigolo, pour voir à partir de quelle hauteur ça se dégrade à cause de la flexibilité de la pièce en cours d'impression Ce test qui va foirer à coup sûr permet aussi de tester si les caméras ou les capteurs de l'imprimante détectent le problème

Merci beaucoup pour ce test très détaillé Pour le poids, je n'ai pas bien compris : c'est la totalité de l'imprimante et des accessoires qui est dans un seul colis, ou juste le colis principal qui fait 50 kg ? C'est donc un transporteur qui livre (il y a une limite à 35 voire 30 kg par colis pour la manutention par une personne). L'imprimante seule pèse environ 32 Kg, c'est sous la limite mais elle restera difficile à déplacer par une personne seule. La purge est maintenant très réduite, mais c'est la tour de remise en pression qui pénalise le rendement en termes de perte de matière. Les impressions du "torture test" et du "Z Max" sont impressionnantes. Les vibrations et secousses dont on a parlé récemment dans un autre sujet ne semble donc pas pénaliser la qualité de l'impression Beaucoup de tests ont été faits en PLA... Avoir un "torture test" et un "Z Max" avec des filaments plus difficiles à imprimer aurait été plus intéressant, mais c'est peut être trop demander car notre testeur a déjà passé de très nombreuses heures pour réaliser l'ensemble du test Il y a une réflexion très intéressante dans le test, dans le paragraphe sur la comparaison avec la Snapmaker U1 : le système multifilament / multibuse de la Bambu H2C ultimate reste basé sur les AMS. En particulier, il impose de rembobiner le filament dans l'AMS à chaque changement de filament, même si une buse n'utilise que ce filament durant toute l'impression. Il ne peut donc y avoir en même que deux filaments chargés dans l'imprimante, un pour la buse droite et un pour la gauche (associée au système multibuse). Si j'ai bien compris, par rapport aux systèmes multibuses de la Snapmaker U1, de la Prusa XL et de la future Core One + Bondtech, cette solution a les inconvénients suivants : - durée de l'impression plus longue - difficile prise en charge des filaments flexibles - difficile de réduire le volume de la tour de mise en pression Le système AMS a été inventé à l'origine pour ajouter une fonctionnalité multicouleur voire multimatériaux aux imprimantes monobuse. Utiliser un AMS sur un système multibuse, c'est en quelque sorte brider des performances de ce dernier. J'ai hâte de voir le test du système Core One + Bondtech... Peut être que Prusa va de nouveau être le leader

Le 31 décembre j'ai acheté une bobine de PVB opaque rouge https://www.amazon.fr/dp/B0D25PK3HJ?ref=ppx_yo2ov_dt_b_fed_asin_title&th=1 Mais la livraison n'en finit pas d'être retardée à cause du mauvais temps En plus j'ai déjà une "commande" : le pic au sommet du sapin de Noël chez mes parents a rendu l'âme et apparament ce genre de décoration ne se trouve plus en magasin ; j'ai déjà trouvé des STL qui conviennent. J'ai aussi chez moi pas mal de pièces en ABS lissées avec l'acétone qui se sont fissurées... En fait c'est aléatoire, certaines pièces sont intactes et d'autres pas, sans lien avec l'intensité du lissage... ça doit dépendre de la marque et de la couleur du filament, et aussi de la géométrie de la pièce... J'ai du mal à maitriser l'intensité du lissage avec ma chambre à vapeur froide, qui doit dépendre de façon assez sensible de la température et de l'hygrométrie. De plus, le lissage à l'acétone de l'ABS occasionne toujours des déformations plus ou moins prononcées. Je ne ferais plus de lissage des pièces ABS (ou un très léger, pour redonner le brillant après ponçage) Je pense utiliser le PVB opaque lissé à l'alcool pour mes prochaines pièces décoratives à l'intérieur, non soumises à des contraintes. Malheureusement, le choix de coloris est très limité. C'est Polymaker qui propose le plus de choix mais 50€/kg minimum J'avais aussi testé le lissage du HIPS avec du D-limonène, ça fonctionne mais il y a des traces blanches sur les pièces, le séchage est long, le produit est cher, et le lissage ne peut se faire que par trempage.

Oui c'est bizarre... mais ça fonctionne... donc je n'y ai pas touché Je ne suis pas l'auteur de la lib et il n'y a pas de documentation, juste un exemple de code qui montre comment s'en servir Voici comment on utilise la lib : Dans le setup() du programme .INO, on appelle la fonction InitTouch() Note : l'écran aura dû être calibré avant avec un programme, qui permet de déterminer les valeurs de touch_x_left, touch_x_right, touch_y_top(touch_y_bottom, j'ai une procédure dans mon INO qui permet de le faire et qui conserve les bonnes valeurs en EEPROM (dans la lib initiale, il fallait charger un sketch de calibration dans l'Arduino et noter les valeurs sur une feuille de papier pour les écrire en dur dans le code ) Dans la boucle loop() du programme .INO, on appelle régulièrement la fonction dataAvailable() Si elle renvoit une valeur vraie, alors on appelle la fonction read() Dans le code, la broche IRQ est tantôt passée en INPUT ou en OUTPUT... il doit y avoir une raison (ou pas) à cela. Il faudrait que je regarde dans la datasheet du contrôleur ILI9341 et aussi celle de l'écran ou au moins son schéma Merci A bientôt

Bonjour, J'ai modifié la bibliothèque URTouch pour désactiver temporairement les interruptions mais ça ne résoud pas le problème - fonctionnement correct si les broches du port PL ne sont pas utilisées pour la dalle tactile - si les broches du port PL sont utilisées pour la dalle tactile, alors l'écran graphique LCD ne fonctionne plus (mais tout le reste du code, y compris le shield Ethernet qui utilise le même port SPI, fonctionne très bien) Pour éliminer tout problème venant d'ailleurs (problème de hardware, ou un autre bug ailleurs dans le projet), j'ai repris le code qui fonctionne, et ajouté manuellement des instructions qui écrivent sur les broches libres du port PL, aux endroits où je communique avec la dalle tactile : digitalWrite(42, HIGH); digitalWrite(43, HIGH); digitalWrite(44, HIGH); digitalWrite(45, HIGH); digitalWrite(46, HIGH); digitalWrite(42, LOW); digitalWrite(43, LOW); digitalWrite(44, LOW); digitalWrite(45, LOW); digitalWrite(46, LOW); Tout fonctionne correctement => C'est bien le code URTouch qui est en cause. Les corrections que j'ai apporté ne sont pas bonnes... ... mais je ne comprends pas pourquoi J'ai modifié les macros de la façon suivante : #define TOUCH_SAVE_PCR 1 #if (TOUCH_SAVE_PCR) #define cbi(reg, bitmask) oldSREG = SREG; cli(); *reg &= ~bitmask; SREG = oldSREG #define sbi(reg, bitmask) oldSREG = SREG; cli(); *reg |= bitmask; SREG = oldSREG #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) oldSREG = SREG; cli(); *reg |= bitmask; *reg &= ~bitmask; SREG = oldSREG #define pulse_low(reg, bitmask) oldSREG = SREG; cli(); *reg &= ~bitmask; *reg |= bitmask; SREG = oldSREG #else #define cbi(reg, bitmask) *reg &= ~bitmask #define sbi(reg, bitmask) *reg |= bitmask #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask) #define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask) #endif J'ai bien sûr dû ajouter la déclaration de la variable temporaire oldSREG dans les fonctions qui utilisent les macros - exemple ici : void URTouch::touch_WriteData(byte data) { byte temp; temp=data; #if TOUCH_SAVE_PCR byte oldSREG; #endif cbi(P_CLK, B_CLK); for(byte count=0; count<8; count++) { if(temp & 0x80) { sbi(P_DIN, B_DIN); } else { cbi(P_DIN, B_DIN); } temp = temp << 1; cbi(P_CLK, B_CLK); sbi(P_CLK, B_CLK); } } NB : impossible de déclarer oldSREG dans le code d'une macro, car si une fonction utiliser plusieurs fois la macro, la variable oldSREG est déclarée plusieurs fois, le code n'est pas conforme la compilation échoue. J'ai aussi dû remplacer if(temp & 0x80) sbi(P_DIN, B_DIN); else cbi(P_DIN, B_DIN); par if(temp & 0x80) { sbi(P_DIN, B_DIN); } else { cbi(P_DIN, B_DIN); } Comme avec ma modification les macros sbi() et cbi() ont maintenant plusieurs instructions séparées par des ";", les accolades sont nécessaires dans le bloc if/else Voici le code complet de URTouch modifié : #pragma once // DEFINE HERE THE PIN USED -------------------------------------------------------------- #if defined(ARDUINO_AVR_UNO) #define T_IRQ 5 // (PD5) #define T_CS 2 // (PD2) #define T_DOUT 7 // (PD7) MISO #define T_DIN 6 // (PD6) MOSI #define T_CLK 1 // (PD1) #else // ARDUINO MEGA // FONCTIONNE CORRECTEMENT : // #define T_IRQ 33 // (PC4) // #define T_CS 34 // (PC3) // #define T_DOUT 35 // (PC2) MISO // #define T_DIN 36 // (PC1) MOSI // #define T_CLK 37 // (PC0) // NE FONCTIONNE PAS : #define T_IRQ 42 // (PL7) #define T_CS 43 // (PL6) #define T_DOUT 44 // (PL5) MISO #define T_DIN 45 // (PL4) MOSI #define T_CLK 46 // (PL3) // AVEC L'ECRAN TFT BRANCHE AINSI SUR L'ARDUINO MEGA : // ILI9341_CS_PIN 49 (PL0) // ILI9341_DC_PIN 48 (PL1) // ILI9341_RST_PIN 47 (PL2) // ILI9341_MISO 50 (PB3) No choice, Mega Hardware SPI MISO // ILI9341_MOSI 51 (PB2) No choice, Mega Hardware SPI MOSI // ILI9341_CK 52 (PB1) No choice, Mega Hardware SPI CK #endif // --------------------------------------------------------------------------------------- #if !defined(TFT_SIZE_WIDTH) #define TFT_SIZE_WIDTH 240 #endif #if !defined(TFT_SIZE_HEIGHT) #define TFT_SIZE_HEIGHT 320 #endif #define PORTRAIT 0 #define LANDSCAPE 1 // Now calibration data is saved on EEPROM, and calibration software is included in the "setup menu" of the interface :-) // So you don't have to burn a separate calibration sketch and include calibration data in the INO file for each bord and each screen int touch_x_left, touch_x_right, touch_y_top, touch_y_bottom; // Hardware specific defines #define TOUCH_SAVE_PCR 1 #if (TOUCH_SAVE_PCR) #define cbi(reg, bitmask) oldSREG = SREG; cli(); *reg &= ~bitmask; SREG = oldSREG #define sbi(reg, bitmask) oldSREG = SREG; cli(); *reg |= bitmask; SREG = oldSREG #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) oldSREG = SREG; cli(); *reg |= bitmask; *reg &= ~bitmask; SREG = oldSREG #define pulse_low(reg, bitmask) oldSREG = SREG; cli(); *reg &= ~bitmask; *reg |= bitmask; SREG = oldSREG #else #define cbi(reg, bitmask) *reg &= ~bitmask #define sbi(reg, bitmask) *reg |= bitmask #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask) #define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask) #endif #define regtype volatile uint8_t #define regsize uint8_t #define PREC_LOW 1 #define URTouch_Prec 102 class URTouch { public: int16_t TP_X ,TP_Y; void InitTouch(byte orientation); bool read(); bool dataAvailable(); int16_t getX(); int16_t getY(); void calibrateRead(); byte FutureOrientation; void UpdateOrientation(); private: regtype *P_CLK, *P_CS, *P_DIN, *P_DOUT, *P_IRQ; regsize B_CLK, B_CS, B_DIN, B_DOUT, B_IRQ; int disp_x_size, disp_y_size; void touch_WriteData(byte data); word touch_ReadData(); byte orient; }; void URTouch::touch_WriteData(byte data) { byte temp; temp=data; #if TOUCH_SAVE_PCR byte oldSREG; #endif cbi(P_CLK, B_CLK); for(byte count=0; count<8; count++) { if(temp & 0x80) { sbi(P_DIN, B_DIN); } else { cbi(P_DIN, B_DIN); } temp = temp << 1; cbi(P_CLK, B_CLK); sbi(P_CLK, B_CLK); } } word URTouch::touch_ReadData() { word data = 0; #if TOUCH_SAVE_PCR byte oldSREG; #endif for(byte count=0; count<12; count++) { data <<= 1; sbi(P_CLK, B_CLK); cbi(P_CLK, B_CLK); if (rbi(P_DOUT, B_DOUT)) data++; } return(data); } void URTouch::UpdateOrientation() { orient = FutureOrientation; } void URTouch::InitTouch(byte orientation) { FutureOrientation = orientation; orient = orientation; disp_x_size = TFT_SIZE_WIDTH-1; disp_y_size = TFT_SIZE_HEIGHT-1; P_CLK = portOutputRegister(digitalPinToPort(T_CLK)); B_CLK = digitalPinToBitMask(T_CLK); P_CS = portOutputRegister(digitalPinToPort(T_CS)); B_CS = digitalPinToBitMask(T_CS); P_DIN = portOutputRegister(digitalPinToPort(T_DIN)); B_DIN = digitalPinToBitMask(T_DIN); P_DOUT = portInputRegister(digitalPinToPort(T_DOUT)); B_DOUT = digitalPinToBitMask(T_DOUT); P_IRQ = portInputRegister(digitalPinToPort(T_IRQ)); B_IRQ = digitalPinToBitMask(T_IRQ); pinMode(T_CLK, OUTPUT); pinMode(T_CS, OUTPUT); pinMode(T_DIN, OUTPUT); pinMode(T_DOUT, INPUT); pinMode(T_IRQ, OUTPUT); #if TOUCH_SAVE_PCR byte oldSREG; #endif sbi(P_CS, B_CS); sbi(P_CLK, B_CLK); sbi(P_DIN, B_DIN); sbi(P_IRQ, B_IRQ); } bool URTouch::read() { unsigned long tx=0, temp_x=0; unsigned long ty=0, temp_y=0; unsigned long minx=99999, maxx=0; unsigned long miny=99999, maxy=0; byte datacount=0; #if TOUCH_SAVE_PCR byte oldSREG; #endif cbi(P_CS, B_CS); pinMode(T_IRQ, INPUT); for (byte i=0; i<URTouch_Prec; i++) { if (!rbi(P_IRQ, B_IRQ)) { touch_WriteData(0x90); pulse_high(P_CLK, B_CLK); temp_x = touch_ReadData(); if (!rbi(P_IRQ, B_IRQ)) { touch_WriteData(0xD0); pulse_high(P_CLK, B_CLK); temp_y = touch_ReadData(); if ((temp_x>0) and (temp_x<4096) and (temp_y>0) and (temp_y<4096)) { tx += temp_x; ty += temp_y; if (temp_x<minx) minx = temp_x; if (temp_x>maxx) maxx = temp_x; if (temp_y<miny) miny = temp_y; if (temp_y>maxy) maxy = temp_y; datacount++; } } } } pinMode(T_IRQ, OUTPUT); tx -= minx + maxx; ty -= miny + maxy; datacount -= 2; sbi(P_CS, B_CS); if ((datacount==(URTouch_Prec-2)) or (datacount==PREC_LOW)) { if (orient == PORTRAIT) { TP_X = ty/datacount; TP_Y = tx/datacount; } else { TP_X = tx/datacount; TP_Y = ty/datacount; } return true; } else { return false; } } bool URTouch::dataAvailable() { bool avail; pinMode(T_IRQ, INPUT); avail = !(rbi(P_IRQ, B_IRQ)); pinMode(T_IRQ, OUTPUT); return avail; } int16_t URTouch::getX() { int c; if (orient == PORTRAIT) { c = long(long(TP_X - touch_x_left) * (disp_x_size)) / long(touch_x_right - touch_x_left); } else { c = long(long(TP_X - touch_y_top) * (-disp_y_size)) / long(touch_y_bottom - touch_y_top) + long(disp_y_size); } return c; } int16_t URTouch::getY() { int c; if (orient == PORTRAIT) { c = long(long(TP_Y - touch_y_top) * (disp_y_size)) / long(touch_y_bottom - touch_y_top); } else { c = long(long(TP_Y - touch_x_left) * (disp_x_size)) / long(touch_x_right - touch_x_left); } return c; } void URTouch::calibrateRead() { unsigned long tx=0; unsigned long ty=0; #if TOUCH_SAVE_PCR byte oldSREG; #endif cbi(P_CS, B_CS); touch_WriteData(0x90); pulse_high(P_CLK, B_CLK); tx=touch_ReadData(); touch_WriteData(0xD0); pulse_high(P_CLK, B_CLK); ty=touch_ReadData(); sbi(P_CS, B_CS); TP_X=ty; TP_Y=tx; } Remarque importe : ce code fait fonctionner correctement la dalle tactile, dans tous les cas j'arrive bien à détecter un appui sur l'écran tactile et à lire les coordonnées. D'ailleurs l'ensemble du projet fonctionne correctement, à condition de choisir des broches autres que celles du port PL pour la dalle tactile. A priori, mes modifications n'ont pas ajouté de bug supplémentaire. Le seul bug qui se produit, c'est quand on utilise les I/O du port PL pour la dalle tactile, cela empêche l'écran LCD graphique (dont les broches CS, RS et RST utilisent aussi le port PL) de fonctionner Les procédures étant courtes et avec peu de variables, je suis à peu près certain que le compilateur ne va pas utiliser la RAM mais un registre pour la variable oldSREG ; les opérations d'affectation seront donc rapides (surtout que les AVR ont de nombreux registres) - mais je n'en suis pas sûr. Je n'ai pas poussé mes investigations jusqu'à examiner l'exécutable généré - en fait... je n'ai jamais fait cette manip avec l'Arduino mais c'est peut être l'occasion d'essayer Si le problème vient de là, il faudra alors que j'utilise à la place des macros des fonctions INLINE ; la déclaration de la variable oldSREG sera dans le code des fonctions, ce sera une variable locale, avec l'attribut INLINE le compilateur va éviter tout seul les doubles déclarations. En réfléchissant au problème, quand on regarde la suite d'instructions suivante : oldSREG = SREG; cli(); *reg &= ~bitmask; SREG = oldSREG; il n'y a rien qui empêche une interruption d'être exécutée après oldSREG = SREG; mais avant cli(); mais si cette explication était bonne, le test que j'ai fait en ajoutant les digitalWrite(); sur les broches du port L aurait occasionné le bug ce qui n'est pas le cas

@fran6p C'est cela, oui... Donc voici la photo ; à gauche trempages de 30 secondes, à droite 15 secondes

Voici deux autres photos (cliquez dessus pour les voir en taille réelle) : J'ai aussi fait le test avec une pièce plus "massive", la réduction de la durée de la trempe (de 30 secondes à 15 secondes) a aussi nettement diminué les bulles (je ne peux pas encore mettre la photo car cela dépasse la taille maxi)

S'il n'y avait que des radiateurs la vanne pourrait être laissée à une position fixe. La valeur exacte de la température de l'eau envoyée dans les radiateurs n'est pas très critique, ce sont les robinets thermostatiques des radiateurs qui vont réguler le chauffage dans la pièce. En revanche le pilotage de la vanne est utile voire nécessaire pour réguler précisément la température du plancher chauffant. Il faudrait remettre un moteur ; s'il a du mal à tenir sur la vanne, pourquoi ne pas faire une fixation complémentaire avec l'imprimante 3D ou autre moyen ?

C'était donc une vanne 3 voies motorisée à la base Question à la con : quel est le rôle de cette vanne ? La commutation chauffage/production eau chaude et/ou la régulation ? Du coup il faut remettre la motorisation, ou sinon se contenter de laisser la vanne dans une position fixer et le chauffage sera régulé avec le thermostat et/ou des robinets thermostatiques

On en a parlé il n'y a pas longtemps sur le forum Pour résumer, il faut installer un plug-in dans le slicer pour imprimer avec des "brick layers", qui permettent d'avoir des pièces plus solides et étanches Avec cette technique, en modélisant une manette assez "épaisse", et avec un peu de chance, tu pourrais imprimer une manette en 3D assez solide pour l'application sans devoir utiliser un filament technique cher et/ou compliqué à imprimer.

Il y a une chose à tester : les "brick layers" - ou sinon augmenter le flow

C'est le soucis avec ce genre de pièce, la vanne n'étant pas manoeuvrée souvent, au début de chaque manipulation les efforts seront importants. Si la pièce d'origine qui était moulée par injection s'est brisée, ce sera difficile d'avoir un meilleur résultat en impression 3D Il peut être possible de renforcer la pièce en y insérant une ou plusieurs tiges ou vis en métal, mais vu la forme de la pièce il restera des points faibles... Une solution serait de faire cette pièce en deux parties : - pour la partie "dentée", qui actionne la vanne : un morceau de tube en acier dans lequel on fait des encoches avec une lime - une manette imprimée en 3D qui sera fixée sur l'autre extrimité du tube avec une meilleure prise, et qui acceuillera la vis permettant de maintenir la pièce sur la vanne Pour fixer la manette sur le tube : - il faudrait modéliser deux ou trois trous diamètre 2,5mm, perpendiculaires à l'axe de rotation de la vanne dans la manette imprimée en 3D - on place le tube dans la manette - on perce le tube avec un foret de 2,5mm en utilisant les trous dans la pièce imprimée en 3D comme guide de perçage - ensuite on visse dans la manette des petites vis à bois diamètre 4mm, le filetage de la vis à bois va tarauder la manette, la pointe des vis à bois va entrer dans les trous percés dans le tube en acier, ce qui assurera la fixation

Essayes de faire cette modification du moyeu (supprimer la partie qui dépasse) ; tu peux aussi augmenter la largeur des rayons vers le bas pour qu'ils soient en contact avec le bed. Ensuite, demande à Prusa Slicer de trancher la pièce sans support. Enfin, regardes si les surplombs ne sont pas trop prononcés, 45° ça peut le faire A bientôt

Je n'ai jamais utilisé de supports... J'ai imprimé que des pièces qui n'en n'ont pas besoin La pièce doit avoir une face plus ou moins "complète" en contact avec le bed, et ensuite "grandir" selon l'axe Z d'une manière que les supports ne soient pas nécessaires, sachant que des surplombs et des ponts "raisonables" sont imprimables sans supports. Ta pièce est une roue ou une poulie... D'un point de vue fonctionnel, ta pièce n'a peut être pas besoin que le moyeu dépasse des deux côtés. Si tu modifies ta pièce pour que la face en contact avec le bed soit plane, pas besoin de supports. La pièce ne sera pas symétrique mais ce n'est peut être pas gênant. La face plane peut être du côté qui ne sera pas visible. En fait, il ne faut pas hésiter à concevoir et modéliser les pièces qu'on veut imprimer en 3D d'une façon différente des pièces qu'on fabriquerait par usinage ou fonderie. Chaque procédé de fabrication a ses avantages et ses contraintes, s'acharner à vouloir imprimer en 3D une pièce dessinée pour être fabriqué autrement c'est parfois se compliquer la vie, sans que cela soit utile au final. Autre astuce : l'orientation de la pièce que l'on imprime en 3D ne correspond pas forcément à l'orientation dans laquelle on l'a dessinée. Ici, c'est flagrant, la roue est couchée Mais parfois les utilisateurs se cassent la tête avec des supports difficiles à retirer alors que la pièce pourrait être imprimée plus facilement inclinée ou carrément à l'envers. La solution donnée par @Kachidoki est bien aussi : couper la pièce en deux pour la coller ensuite. Il faudra penser à ajouter aux deux moitiés de pièce des encoches males/femelles pour avoir un bon positionnement pendant le collage. Si tu imprimes en ABS, ce matériau se colle solidement et facilement avec de la colle PVC ou de l'acétone.

Il y a Mouthe mais aussi quelques autres endroits dans le Jura et le Haut-Doubs. Je suis arrivé dans la région en 2004. On avait souvent des températures négatives de nombreux jours de suite et de la neige. C'est beaucoup plus rare aujourd'hui en effet.