electroremy

Merci @fran6p L'avantage d'une poulie crantée c'est l'absence de glissement, donc on contrôle précisément le débit. Un système lisse fonctionne par adhérence et il y a forcément un glissement même faible... de plus le glissement dépend du type de filament. Un système lisse peut être intéressant en complément pour aider ... il reste à synchroniser les deux, pas simple ... A bientôt

Quand j'ai utilisé pour la première fois le filament Polycast Polymaker, pour réaliser un moule selon la technique de cire perdue, j'ai rencontré un problème similaire. Le profil pour ce filament très particulier n'existe pas dans Prusa Slicer. J'en avais donc créé un, en suivant les préconisations du fabriquant (températures, vitesses, rétraction) Mon impression c'est arrêté lorsque le modèle (une figurine de chouette) se séparait en deux parties au niveau de ses oreilles au dessus de la tête. La rétraction était trop importante, la poulie dentée de mon extrudeur avait "bouffé" le filament qui n'était plus entrainé. (NB : sur la MK2s Original, il n'y a qu'une poulie dentée, le filament est pressé dessus avec le roulement à bille de l'extruder idler, l'effort se règle avec deux ressorts monté sur deux vis) J'ai dû abaisser la rétraction pour réussir l'impression. Mais j'ai eu beaucoup de stringing sur ma pièce. Les imprimantes récentes ont des extrudeurs avec une meilleure prise, typiquement avec deux poulies dentées au lieu d'une, et ces poulies ont peut être un diamètre plus grand et/ou un crantage plus efficace... cependant, les imprimantes récentes ont aussi des débits plus élevés, ce qui fait qu'au final les efforts sur le filament restent importants. De plus les imprimantes avec système multicouleurs font passer les filaments dans des tubes PTFE assez long, cela engendre encore plus d'efforts, sans parler du fait que le multicouleur imposent des chargements/déchargement. Il y a certainement une limite aux efforts qu'on peut imposer à un filament sans l'endommager, cette limite étant différente selon les matériaux C'est des problèmes "de riche" Nous voulons avoir le beurre, l'argent du beurre et la crémière ... Si on veut toujours plus débit, avec en plus du multicouleur, et que ça fonctionne pour tous les matériaux, il faudra peut être une 2e motorisation qui entraine le filament en amont de l'extrudeur pour limiter les efforts au niveau de ce dernier. Idéalement un système sans poulies crantée (par exemple, deux roues revêtues de caoutchouc). Ou alors il faut utiliser un système multibuse qui évite les chargements/déchargement à chaque changement de buse, avec en plus un système qui limite le oozing quand la buse est rangée pour éviter les rétractions trop importantes.

Je l'ignore. Remarque importante : après trempage l'odeur disparait assez vite, et les pièces ne sont plus poisseuses ; c'est plutôt le durcissement résiduel qui est long J'ai bien peur qu'une ventilation risque de ne pas changer grand chose. Une ventilation fonctionne très bien pour sécher du linge humide, car la circulation de l'air évite que de l'air humide et plus frais(*) stagne autour du linge et ralentisse le séchage. Mais cela fonctionne car la quantité d'eau dans l'air est importante - dans un logement, l'hygrométrie relative normale "de confort" se situe entre 50% et 65% - et le linge humide contient beaucoup d'eau. (*) pourquoi "plus frais" ? L'évaporation de l'eau à température ambiante consomme de la chaleur, l'air se refroidit. Et plus l'air est froid, moins il peut contenir d'eau pour une valeur identique d'humidité relative. Le linge qui sèche a deux effets sur l'air autour de lui : il augmente son humidité relative et diminue sa température ce qui augmente encore plus vite l'humidité relative. Mais dans notre exemple, la pièce en PVB en cours de séchage est très loin de saturer d'alcool l'air autour d'elle. Le PVB n'est pas une éponge, l'IPA s'évapore très vite, ensuite il ne reste que de faibles quantités résiduelles dedans. La température peut avoir une influence... mais attention le PVB ne résiste pas à la chaleur . On peut toujours essayer de placer les pièces dans un séchoir de filament à 50°C, mais s'il faut le faire fonctionner plusieurs jours, la consommation d'énergie est loin d'être négligeable. Un séchage par chauffage trop violent pourrait endommager la pièce, en créant des tensions entre les surfaces externes et le cœur de la pièce. @pjtlivjy aurais-tu un avis éclairé sur la question ?

Nous sommes le 11 janvier, donc 19 jours après le lissage des deux pièces imprimées en spiral vase Elles sont devenues un peu plus rigides, mais pas autant qu'avant le lissage Le séchage est donc assez long Dommage, j'aurais dû penser à bricoler un système pour mesurer la rigidité et l'utiliser chaque jour, car ça reste une observation au pifomètre

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.