amedee

Oui, on peu revoter de temps en temps... Sinon, je suppose que comme d'habitude cela va se terminer à l'avantage de celui qui a le plus grand 'réseau social'... Comme je commence à arriver au bout des amis de mes amis de mes... c’est pas gagné

Pour ce qui est du gazomètre, c'était un print particulièrement difficile parce qu'il faut faire énormément de rétraction sur des sections assez fines... Ce n'est pas le terrain de prédilection de l'Ultimaker avec son bowden; une imprimante a extrusion directe aurait été plus appropriée. On a fait pas mal d'essais de positionnement de pièces pour limiter les rétractions -- je pourrais faire un 'best off' des prints raté Ça a aussi été l'occasion de tester le nGen de ColorFabb -- le choix du nGen était au départ lié aux couleurs et pas forcément pour ses propriétés (Les nouveaux gris RAL ne sont pas dispo en PLA/PHA) Ça s'imprime plutôt bien et le résultat est beau. L'adhésion sur le plateau est bonne (même sur l'UMO avec du tape bleu) et la plage de température d'utilisation est assez large. Seul bémol, il est plus 'filandreux' que le PLA, il faut un peu jouer avec les paramètres de rétraction, mais sur des pièces comme celles du gazomètre il est difficile de ne pas avoir de 'stringing'

Oui et non... Il y a un système de contrôle via les cookies du navigateur et l'adresse IP de la connexion internet. Donc en fonction de l'un ou de l'autre on peut parfois revoter...

D'une part j'ai un peu décroché avec le changement de site avec lequel je n'ai pas trop d'affinité et d'autre part j'ai des activités assez diversifiées, l'impression 3D fait très souvent partie de la chaîne, mais s'est pour moi essentiellement un moyen, pas un but en soi En général on peu suivre nos aventures sur twitter @Bommeltje

Si vous n'aimez pas le rangement, vous pouvez aussi voter pour le gazomètre de ma fille C'est une réplique à l'échelle du gazomètre de Berlin pour un projet d'aménagement. C'est notre plus gros projet en terme d'impression 3D, il y a pour plus de 250 heures d'impression sur UMO et UMO+ pour les différentes pièces... (Il y a une galerie photo pour ceux que ça intéresse...)

PLA works fine -- no need to mess up with ABS For me changing to the GT2 belts/pulleys and these blocks are the best update I did on my printer in term of quality improvement (to be honest this printer is quite old, and the MXL/wooden blocks were end of life -- nevertheless, results are better than what I get from my newer printer)

As I said, I am using both and I never noticed a difference... Now, having said that, I bought the Full Graphic controller because I did not have a controller on my old printer, and it is definitely cheaper than the original UltiController. Other than that there is no real advantage -- it does not display much more information, it is just bigger. The only thing I was missing on the UltiController was the fan percentage and I added that in my firmware fork. So if your UltiController works better for you I don't really see a compelling reason to use this one...

Again, this hard to believe. I have both, side by side and I do not see any difference... (I am not arguing that yours might be slower, but if it is, there is something wrong with it)

That does not sound right to me. Typically on complex prints it should achieve higher speed than USB printing as the USB transfer rate is not great. You probably have an issue with your controller (or the SD-card)

I said it from the beginning that changing the steps would be a pain for the big values So yes, we could build some acceleration or velocity control, but from my side I'm just fine the way it works...

I can be wrong on this, but afaik on the UMO you cannot control it by software, it is a pot on the drivers... UMO+ has the Ultiboard 2 where it is possible. I'll look to add that on my next builder version....

Yes, it's 1 / 5 respectively when not defined (same as what it is in the commented lines) Probably. But having an UtliController on one machine and this one on the other, I don't feel much difference.

What about browsing the commit log? This changelog ENCODER_PULSES_PER_STEP in the config file. By default one encoder pulse generates one unit step in the values. Difficult to find a good compromise there, if you increase it, you will have to turn a lot to make big changes... Also, ENCODER_STEPS_PER_MENU_ITEM relies on that one, so if you change the first, it will affect the menu browsing as well, so you need to tune both. Personally I wouldn't go there...

You need to implement draw_line() in dogm_lcd_implementation.h. Call was defined by the Ultimaker folks and that's why it is not in the dogm_lcd from Marlin. (You can check my firmware branch for more details)

I still have an unused E3D hotend in my toolbox and still undecided to use it or not, but I was thinking using @jonnybischof design (here) Any other recommendation for the UMO?

@greengecko for now I have update the builder with a simple choice: Marlin or Ultimaker beep. If really needed I can make a more complex choice, but I try to keep the builder as simple as possible for the users. Incidentally I also fixed a bug in Daid's configurable beep -- the loop counter was wrong due to integer arithmetic.

@macua85 I eventually spent some time to look at the encoder thing...

Here is a short video comparing the 'Ultimaker' beep with the 'Marlin' one; The sound quality of the video is not very good, but there is definitely a difference, the 'Marlin' one sounds more like a keyboard click... @greengecko can you confirm this is what you were referring to or is there another beep?

No, it is not that one. AFAIK we don't have LCD_USE_I2C_BUZZER on the UltiController... Interestingly enough, Daid implemented a configurable beep (See this commit), but I see no evidence that these parameters were ever used... The only other evidence I see from a change is this commit where we go from 150 to 5000Hz... Need to experiment a bit with all that... [Edit] Actually this last commit is probably the explanation. The standard Ultimaker builds (and mine) are with the 150Hz -- delay(3) -- beeps while the Robotfuzz one uses 5000Hz -- delayMicroseconds(100). So when people move from the one to the other they get a different beep experience

This is interesting... It is not the first time somebody is 'complaining' about the sound, but I never touched it, this part is exactly the same as the original Ultimaker one and it sounds like it always sounded on my UMOs since I have them I need to check if Daid changed something at some point in time to see if I can make something configurable...

I am not aware of recent changes in the UMO firmware... Latest 'official' firmware is https://github.com/Ultimaker/Marlin You can also try my builder which based on the official one, plus a couple of cosmetic changes.

The updates are always done via USB on the Ultimaker board... For the builder, it would be an easy thing to do, but I first need to spend time in testing my suggested fix...

@neotko -- You just need to #define DISPLAY_FAN either somewhere in the Configuration.h file (does not matter where) or from the make command line in the "DEFINES=" (that's what my builder does)

Just updated my builder, you can now select the 'MAXTEMP' for the hot-end...

Absolutely -- I am still in 'regular drive' as you can see here: For the short belts you need 101T (202mm) and for the motors you need pulleys with 5mm bore (instead of 8mm) So in total you need: 4 303T belts 2 101T belts 10 8mm pulleys 2 5mm pulleys You will need new X-Y blocks because the GT2 belts are 4mm shorter so they will be too short for the original clamp system. And you need to change the pulley ratio in your firmware (same value as for direct drive, this does not change)