UMO / UMO+ Firmware

[drayson]

Right

enquecommand add a GCode command in the execution queue -- so you can only add GCode.

lcd_card_stop() is not GCode, it is a call to a function.

The C language is very powerful, but it allows you to do almost anything without too much checking with very unexpected results

Aaahhh.... thank you - that explains why nothing happened when pushing the button
I have no clue about C language but try to learn but currently most of the things I do are based on trial and error... with a little help from my friends (here)

So the call should look like this instead - isnt?

ifdef STOPBUTTON
void stpbttn() {
if (!stpbttnEnqueued) {
stpbttnEnqueued = true;
lcd_card_stop();
st_synchronize();
}
}
#endif

[Amedee]

Thanks to drayson, found an issue with Marlin's 'enqueuecommand' routine which silently drops commands when the buffer is full.

A side effect of that was that it could disable filament detection is the first detection event occurred when the command buffer was full.
It would not happen in latest Marlin as the buffer management is different, but this is not something we can easily backport in UltimakerMarlin.

Anyway, I posted a quick fix/workaround for the filament detection and it is working very well with my low-tech sensor.



It is available in the experimental branch on github (and the experimental builder), I'll push all the 'experimental' features in 'stable' soon as all these 'new' features have been tested now.

[drayson]

Amedee, youre THE man !!

Thank you!

[Neotko]

Amedee I got an 'maybe' interesting idea.

Since we on umo/umo+ we don't have that sexy ultimaker gcode flavour to have material profiles I thought that this might just so.

Heat differential:
A heat differential with hotend and bed and fan values.

For example if you set fan to -255 then on the print no matter what the fan value it's it will stay off. If you set a +20 for hotend it will add 20 to the heat target of the gcodes. This way we could reuse a pla print to print carbon. We could also, for users like me that have 3 machines with different pt100s that one its 15+ more than the others and other that it's -10. With this I could just set a differential for the machines and just launch the same gcodes without having to wait for the bed to warm up (I ise to just change the temp and when it starts to heat the nozzle I change on the ultictro the target temp). But if the files has different temps at diferent layers then I need to reprocess it for each machine.

[Amedee]

Makes sense -- Octoprint does have these deltas for the hotend and nozzle.

Deltas are interesting because you often change temperature during print (at least I am almost always printing the first layer hotter on my old UMO to get better adhesion on the blue tape), and you don't want to wait make corrections each time.

It is not too difficult to implement because you just need to consider it when there is temp change.

Just need to think about a nice way to present it on the controller...

In term of possibilities, what do we need?

Fan:

1. Fan override: Set a fixed value for the print -- This is what I would use
2. Fan delta: do we need this? I yes, how do we want to enter the data: as a delta (e.g: 'x' would mean always add 'x' to the actual value), or as a ratio (e.g. y% would mean always do y% of the actual value -- default would be 100%)

Bed/Nozzle temperatures:

1. Temp override: Set a fixed value for the print -- do we need this?
2. Temp delta (more useful): enter temp value as a delta (e.g: 'x°C' would mean always add 'x°C' to the actual value) -- percentage would probably be more correct, but it is not the natural way of looking at it, so I would stick to deltaT.

[Neotko]

Yay you like the idea!

Ok umm...

For Fan I like the % idea. But I would like to be able to go 200% too just to be more future proof but indeed with just 0-100% adjustment that would work perfect.

For bed/nozzle indeed a % isn't the natural way, for that we need hard numbers, so a X amount to add/subtract to the m104 could work indeed.

How to show it on the controller, I think Prepare menu seems like a good area.

Could be on
Main / Prepare / Gcode Temp Tweak

And then Gcode Temp Tweak
- Reset Gcode Tweak
- Fan % modifier
- Bed ºC Modifier
- Hotend1 ºC Modifier

Something like that?

[Amedee]

In needs to be in the Control Menu (Or the root menu) because Prepare is no more available once the print is started

[Neotko]

True I thought that way you only adjust it before print? Set ranges, print file. But you are totally right, outside makes more sense to adjust temps and then you can adjust onthefly and leave the machine alone. Nicee

[Neotko]

@Amedeeeeeeeeeeee Could we have true pid bed? I wan't more quality! I don't have bading problem, but hey, it can't hurt !

[Amedee]

As I just said...

[Amedee]

It's available, untested. Let me know how it goes.

I took over the PID from the UM2 as it is the same board and sensor, so it should be good. You can always do an auto-tune to see if we get the same values
At this point in time you cannot change it from the controller and you cannot save it in EEPROM. It would not be very difficult to do it, but is is quite some code, so if nobody needs it after all...

[Neotko]

I'll test a tall cube at 70mm/s 0.2 layer with and without. Thanks!!

[Dim3nsioneer]

Seriously? You guys printed with bang bang mode for the bed all the time?

[Amedee]

Bang bang is not that bad. I am always printing with Octoprint, so I see the temperature graph for each print and I can assure you it is really flat.

(But I appreciate you might have a different experience)

[LePaul]

I might dive into your firmware for my UMO

Question...and this has been a pet peeve of mine on my UMO. I despise how the nozzle reaches temp, homes (mashing the filament coming out since it is at temp), does the pre extrude then moves into position to print. Does your skip that?

I'm weary of a messy nozzle from the get go!