amedee

What about warming up the core without the fan connected, not too warm to avoid to burn the filament, but long enough to warm up the upper part of the core and soften the part which is stuck...

Check This fix...

Eventually made a video on the subject

Et en faisant tourner la pièce sur elle même, le résultat ne change pas? Ça m'a l'air d'être un problème 'thin wall' -- ton mur fait exactement 1.05, soit 3 traits de 0.35, mais suivant la position et les erreurs d'arrondi, il peut mesurer un poil moins, et zoup, pus de trait central. Si c'est ce problème, réduire très légèrement l'épaisseur de trait/mur dans cura devrait solutionner (genre 0.345 au lui de 0.35 -- parfois 0.001 de différence suffit)

Je suis comme d'hab hors sujet, mais c'est la découverte du jour pour moi ce truc là... Pour les UM2+/3 on a effectivement "round(machine_nozzle_size * 0.875, 2)"... Faut que j'essaie ça! Je plussoie -- j'ai ce paramètre pratiquement toujours décoché, pour ce que j'imprime ça passe pratiquement toujours mieux. C'est la raison pour laquelle je n'ai jamais utilisé Cura 15.xx qui forçait le remplissage avant les murs.

Whatever...

I get that, just saying that if you home on top like I do, then there is a crash risk. As you say, no real danger when you home at the bottom.

Thank you for this feedback. Now the homing offset is not something we made up, it is part of standard Marlin. I think we just need to document it. You can easily revert to the default behaviour by either resetting the firmware as you mention, or just clear the value with 'M206 Z0' (and 'M500' to save it). But it is worth mentioning it as the particular case of end-stop at the top the offset raises the bed, so it will crash in the head!

Et après ça si le PLA colle pas...

Note que le 'home z' c'est un commentaire pas une commande, pas mettre sur une ligne séparée

M0 S30 ; pause 30 sec G0 Z20 ; baisse de 2 cm Si tu mets un G0 X100 Y100 juste après le home Il va centrer la tête

Si tu est en USB dessus, la console de pronterface, ou celle de OctoPrint si tu utilises ça. Sinon si tu fais dans le SD, un ptit gcode G28 Z ; Home ZG0 Z0 ; (ou G0 Z0.1 si on veut se la jouer petit)M0 ; ça devrait faire une pause...

Ben voui... Donc si tu calibres à 0.1 de la buse et que tu ajoutes après 0.1, tu es contre la buse quand même... Si ce serait l'opposé ton 0 serait à 0.2 de la buse. Mais tu n'imprimes pas à 0 non plus... Quand je regarde le GCode généré par Cura la première position n'est pas en 0 mais à la hauteur du premier layer. Note que je n'affirme pas avoir raison, je n'ai pas d'UM2 et j'essaie de comprendre. Je suis en train de porter le code de calibration de l'UM2 sur UMO et cette partie me rend un peu perplexe, sur l'UMO (en mode officiel) je calibre à 0.1 et je ne touche plus rien, alors que le firmware de l'UM2 compense de 0.1. Mais je serais curieux de faire sur une UM2, juste après calibration, un G0 Z0 pour voir où il se positionne...

Oui je l'ai cité ci-dessus aussi On est bien d'accord

La lecture des sources m'avait donné l'impression inverse: la procédure de calibration rajoute l'épaisseur du 'papier' pour vraiment coller la buse au plateau pour Z0 Je n'ai pas trop d'opinion sur la monarchie locale, mais pour ce qui est du plateau Ultimaker est d'avis que le papier de calibration fait 1/10ème, donc la jauge de calibration c'est un très bon plan...

I am old school: if it works don't fix it And I am not sure that one fixes anything, on the opposite: it forces float arithmetic when you just handle integers. To me, that one looks more a shot in the dark than anything else -- as usual I can be wrong, but I can hardly find a use case for that.

Yeah... The problem is that the encoder is unsigned and then suddenly they want to use it as signed, but not all the road... That simple fix works as well @@ -1379,10 +1381,10 @@ static void lcd_action_menu() if ((int32_t)encoderPosition > maxEditValue) \ encoderPosition = maxEditValue; \ if (lcdDrawUpdate) \- lcd_implementation_drawedit(editLabel, _strFunc(((_type)encoderPosition) / scale)); \+ lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition)) / scale)); \ if (LCD_CLICKED) \ { \- *((_type*)editValue) = ((_type)encoderPosition) / scale; \+ *((_type*)editValue) = ((_type)((int32_t)encoderPosition)) / scale; \ lcd_quick_feedback(); \ currentMenu = prevMenu; \ encoderPosition = prevEncoderPosition; \@@ -1395,10 +1397,10 @@ static void lcd_action_menu() if ((int32_t)encoderPosition > maxEditValue) \ encoderPosition = maxEditValue; \ if (lcdDrawUpdate) \- lcd_implementation_drawedit(editLabel, _strFunc(((_type)encoderPosition) / scale)); \+ lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition)) / scale)); \ if (LCD_CLICKED) \ { \- *((_type*)editValue) = ((_type)encoderPosition) / scale; \+ *((_type*)editValue) = ((_type)((int32_t)encoderPosition)) / scale; \ lcd_quick_feedback(); \ currentMenu = prevMenu; \ encoderPosition = prevEncoderPosition; \ I'll commit something wen i have merged my pending stuff... (On the later fix I don't see why he absolutely wants to cast everything to float, that does not make too much sense to me)

I don't have any issue with negative numbers in my build, it all works. I am not saying there are no problems, but I am not going to fix problems I don't have

Le courant je ne sais pas, mais les e-steps sont dans l'EEPROM, donc il n'y a rien a bidouiller, si tu mets le firmware d'origine ça va le faire, il va automatiquement prendre ce que Tinker à sauvé.

@neotko, are you brave enough to beta test my latest firmware? My printer homes at the top, and I would like feedback from somebody homing at the bottom. I guess this is what you should set in the builder: (Be prepared to pull the plug if it goes pear shaped!)

Le e-steps sont sauvés dans l'eeprom, donc si ils sont correct, rien n’empêche de repasser sur le firmware Ultimaker. Moi je suis de l'avis de @darkdvd, il faut essayer avec le firmware officiel pour éliminer ce problème potentiel. (Et je parle d'expérience, il faut toujours se méfier des bidouilleurs de firmware)

Babystepping is about adjusting the Z on the fly while printing -- it has per say nothing to do with bed leveling. (And with the old UMO I have been trained to do hardware babystepping -- manually turning the Z axis 8) )

As usual... But there is no wizardry here, just simple moves. It is more a mechanical test as I wanted to see if the thing was accurate enough to justify such small moves. And it is, or at least kind of as there is some backlash with the z-screw which makes you can't really position with that accuracy. But it still can help to refine...

Fan is crucial on small prints. More flow will help if it goes at the right place (not cooling the hot end!); dual fan setup helps as well, it is difficult to get a nice benchy if you cool it from a single side of the nozzle.

0.01 mm steps for the bed on the UMO: