UMO / UMO+ Firmware

[Neotko]

Been testing today the bed pid and indeed the default works great so far.

Also I been doing some pla vs heat tests and I muat say that the um2+ sensor it's quite weird. My thermal camera tells me that it's off by 13C (taking the nozzle out and measuring over a thin layer of pla that I stuck inside. But my other um2 (with umo+ pt100) it's only off by 2C. So... finally found the problem of my change in quality on that um2+ hotend. I suppose I just got a bad one.

Any chances in the future for a temperature override with a +/- system? It's already a pain in the ass with the umo hotend that needs 10/15C less and with this um2+ +10/15C

I found that the best way for me to measure the correct temp it's the one that gives constant and uniform shiny toplayers.

Also the proff that there's differences between the um2 sensors for me it's that after adjusting the temps I get perfectly equally shiny top layers. And I can do the heavy retracttions that I need while simulating a 0.33 nozzle print (0.32 it's posible but not for this level of retracttions).

[Amedee]

It is still on the roadmap, but I'm very busy these days -- Quite a lot on the professional side and RC car racing in the week-end that does not leave me too much time

[Neotko]

Thanks amedee! No hurry indeed.

First think on that roadmap should be 'enjoy the summer'.

[Dim3nsioneer]

There is no summer north of you... rather: Winter is coming...

[Neotko]

Well after some weeks of 37C and constant sun it will be nice

[antiklesys]

One more addition I think would be nice on the website builder:
allow to download the builded firmware not only as .hex, but also as raw customized files to be opened in the Arduino IDE.

[Amedee]

This is something I cannot do because I am not customizing anything

I took another approach than the other builders: all the options are passed at compile time on the command line.
By doing this I don't have to touch any source file when I generate a firmware.

The builder is mainly for people who do not want to compile themselves, and I think that for the ones compiling, it is not to hard to set the parameters in the config files...

What is more annoying I think is that you cannot save your selections -- When you want to get a new version of the firmware, you have to remember what you selected last time (I use my builder for my printers and I can't remember what I select for each of them ). But I haven't come to a simple solution yet (I still want to keep that thing as easy as possible in term of maintenance...)

[antiklesys]

This is something I cannot do because I am not customizing anything

I took another approach than the other builders: all the options are passed at compile time on the command line.
By doing this I don't have to touch any source file when I generate a firmware.

I see, thanks for the clarification.
Would it be possible to add the output of the options passed via the command line in the output window of the builder then?
I understand your points and my request sounding strange, but I'm doing a lot of tests with these things and it would be good to have this insight also for debugging purposes.

[Amedee]

I fully understand your point.
I am a bit reluctant to disclose the command line as I don't want to give people bad ideas...
(I am doing everything I can to sanitize input, but people can be very creative when it come to hacking)
The code is public anyway, so I guess if someone really wants to get me he can do it, but I don't want to make it to easy...

Which OS are you using?
I do have a shell script I am using to generate firmware outside the builder (like you say for development and debugging before committing in git), but that won't work on Windows (or maybe in a posix shell...)

[antiklesys]

I'm using Windows.

[Amedee]

Too bad...
I'll see what we can do.

(It's my last work day before the summer break and I'll be away for a couple of weeks, but I'll be more active when I come back )

[antiklesys]

Thanks, and enjoy your break!

[LePaul]

A couple WEEKS? Wow! Enjoy!

[Amedee]

A couple is just 2
(On the European scale, this is a very short break )

[LePaul]

One question....I noticed that the default acceleration setting for the UMO is 4000. I was seeing some banding and GR5 suggested lowering it to 2000 or lower (he also suggested printing much slower)

Any reason why the default is 4000? I can't recall what the old default was with the UM firmware