UMO / UMO+ Firmware

[Amedee]

So I have pushed 16.05-RC5 on GitHub (and pulled in the builder) in the experimental branch

On the menu:

• (Very) high temps for the hot-end are now accepted
• Some tweaks in the builder UI (I've seen that the CSS is not updated automatically if you have it in cache -- If the 'Warning: experimental branch' message is in black, force a page reload (it should be Amber)
• Bed PID is now editable on the controller (picture in the previous post) -- not sure if editing from the controller is a real benefit, but at least you can view / check the PID.
• Bed PID is now stored in EEPROM (Like the other parameters: with the 'Save' option from the controller or the M500 G-Code)

Enjoy

I'll push all this to the stable branch when i get positive feedback for the auto-fan feature, the other features from the 16.05-RCs should be OK.

[Amedee]

I eventually looked at my server logfiles for the month of May, and I had 276 unique visitors who generated 439 'stable' and 61 'experimental' firmware.

Now probably half of that are people just clicking around to see what happens, and the other half is I guess neotko himself -- but anyway it is nice to see some people are using this

[Neotko]

Past month 5-6 are mine, I bet since its on ultimaker users use it more. It's also in the ultimaker app since they mirror that info.

[antiklesys]

Like for PT100 on UMO

I'll put that on the list for one of the next release...

Still missing on the builder but thanks for the increased temperature range!

[Amedee]

Not forgotten, but I had busy days

[Neotko]

Sorry it's been impossible this weekend to fully test the bed pid on my 3 umo+. I been busy trying yo make a badass IRobertI feeder and now I must keep doing the shop orders. But next weekend I'll be free so I'll test it fully.

[Amedee]

Same here, too much 'real work', so no progress on the hobby stuff...

BTW, re. the PT100, as it seems to have generated confusion, if the only thing you want to do is to replace your thermocouple, you can just replace it by by the E3D adapter and choose PT100 as sensor in the firmware builder. There is no need for anything else as the sensor pins are directly connected to the microprocessor pin.

The change in the builder that antiklesys requested is because for whatever reason he wants to use another pin, which is a valid request, but as such it is not absolutely needed for the PT100.

[antiklesys]

One small note: the amount of PT100 selections at the end (in the builder) is a bit confusing.
The parameter in Marlin changes, but in the tool it's not that obvious.
Any ways to fix that?

[Amedee]

You mean the wording for the 3 different PT100 entries?

pt100's

pt100.png (26.72 KiB) Viewed 19462 times

The labels are what I found in the comments in the firmware -- for most of them I don't have any clue on what they are
We can put whatever we want, I am open to any suggestion if somebody have a better wording.

Alternatively, we can give a hint under the combo box: 'For the E3d adapter you need to select the "pt100 as on UM2 boards"' or something like that.

[antiklesys]

I agree with you, it's hard to understand the difference, BUT by testing it out...there is a difference.
My advice here would be to put the codes next to the names:

So you would have 20 for the UM2 (or PT100 with E3D on UMO), 1047, 1010, 147 and 110 next to the others just to differentiate.

[Amedee]

I am not sure why would the code make things easier as you would have to know the internal Marlin code (which does not mean anything)...

I would assume people adding custom hardware know what they do on the hardware side and don't need to care of the Marlin internal

(But I can definitely add it)

[antiklesys]

Well that's true and false at the same time.
For instance: when following E3D's guide for PT100 installation they mention to set the temperature sensor to 20 in Marlin, so for similar situations it "may" help

[Amedee]

Arf...

I'll complain to Sanjay then...

[antiklesys]

Any chance we can integrate the firmware improvement recently done for the new Prusa?

[Amedee]

Quick answer before I leave for a loooong week-end -- so don't take this as final

Short answer is probably no, I think if we want to go that way it would be easier to restart from latest Marlin and make sure it run on Ultimaker.

They have done quite a lot of cleanup in the new Marlin, and it is not that easy to backport new features in old code.