UM2 Warm Up Sequence

[abstract 3]

I have noticed a trend with the new 1113 firmware for Ultimaker 2.

Mine is stored in a garage, and with the winter getting a little colder, often the UM2 warms up the bed from a start of about 7 degrees C. Also with the 1113 firmware the default temp seems to go to 75C for PLA (which works well).

So, the bed has a long warm up time, and may take ten minutes to get to 75C. Meanwhile the extruder has got to 220C in a couple of minutes and is busy peeing PLA out the bottom whilst it waits for the bed to get hot.

However, with the very large difference in warm up time for the bed and the extruder, I am seeing a situation where the extruder drips so much PLA, it seems to have eaten back into the filament without pushing any more.

This can lead to the first print failing to start, since there is a big missing gap of filament above the extruder. I have to manually push the filament to fill up the gap, and then having done that, restart the print and all is well….. Until the next big warm up.

I think the warm up sequence should hold off heating the extruder until the bed is within 10% of its target temperature. Then it would not suffer this long wait and the consequential problem.

 

[IRobertI 521]

Yup, I fully agree with that. What I've done in the mean time is to manually heat the bed before starting the print.

 

[illuminarti 18]

I've also had that issue. The bed should heat first, really - or ideally, we should have some control over the start gcode again, so that we can make the printer work the way we want. :-)

 

[Daid 306]

Already implemented the "wait till bed is near the target before heating the nozzles":

https://github.com/Ultimaker/SecretMarlin/commit/02d64b505a638c7ca73d5f61cf3ea5041f13e5e4

Hope to release an update soon, as I'm also tracing down a rare case of SD-Card errors.

Note, if you want full control of the start and end code, you can switch the GCodeFlavor from UltiGCode to RepRap in the machine settings of Cura. This will give you full control of the start/end code.

 

[illuminarti 18]

What I'd really like is to be able to tweak the start and end codes, but still get firmware retraction, material presets, and extrusion in mm³.

Perhaps you could look at adding an 'opt out' gcode that tells the printer not to do the built-in start and end gcodes?

 

[das_enginer 2]

... I'm also tracing down a rare case of SD-Card errors.

 

Daid, on a similar note, is there any specific size limitation you're aware of on SD cards for best functionality? I know that the UM2 comes with one, but should I lose/damage/etc the stock card, would there be any concern with using a Class 10 SDHC?

 

[gr5 2,265]

I know that the UM2 comes with one, but should I lose/damage/etc the stock card, would there be any concern with using a Class 10 SDHC?

 

Ouch. I don't recommend it. but I don't know the answer.

 

[gr5 2,265]

@abstract:

The UM2 retracts at the end of every print. A lot. Maybe 10mm of the full 3mm wide filament. That's a lot! And extrudes the same amount plus a little extra at the start.

If instead you heat up the bed and nozzle before printing, and then when the nozzle is >= 180C you extrude some manually - not that much just get it back in the head. Then you start your print that major extrusion (10mm?) should get it primed nicely.

Make sure you grab the end of the priming filament and hold it away from the start of your print!

 

[das_enginer 2]

Hi gr5!

 

Ouch. I don't recommend it. but I don't know the answer.

 

Are you concerned with the SDHC part, or the Class 10 part? I could understand the SDHC type posing an issue, but I'm curious if the ability to handle fast read/write speeds also pose an issue.

 

[gr5 2,265]

Both. Daid already had 2 (two!) issues with reading the SD card. The second one hasn't been fixed. Mix in some new brands and ... well... yikes - who knows. You don't want to risk it for any print slower than an hour.

 

[jonnybischof 60]

The class shouldn't be a problem as this is just a "can go that high speed if you need me to" feature. SDHC cards however require the reader (Ulticontroller) to be able to read their format (large address range, maybe bigger block size, I don't know the details). I guess the Arduino can't handle that because it's usually not necessary for this type of hardware platform, but who knows?

 

[Daid 306]

Both. Daid already had 2 (two!) issues with reading the SD card. The second one hasn't been fixed. Mix in some new brands and ... well... yikes - who knows. You don't want to risk it for any print slower than an hour.

 

Different brands shouldn't be a problem, SDHC can be a problem however. I've never managed to track down the problem, but SDHC cards have causes issues, so I do recommend normal SD cards that are up to 4GB of size.

 

[das_enginer 2]

Thanks for the advice and info gr5, JonnyBischof, and David!

 

[abstract 3]

On a related topic of temperature, I had a different problem today - the UM2 failed its startup self check and reported a TEMPERATURE SENSOR error / failure.

My UM2 is stored in a garage, and I turned it on late at night for an overnight print. The bed and head were reading about 5 degrees C when I manually connected with Octoprint. The UM2's internal code failed to startup and told me to contact Ultimaker. Tried restarting several times - machine is dead.

I figured it might be the temperature, so I went out with a hairdryer and warmed everything up a little. After that - the UM2 *did* startup OK and all was well.

So, there is a vulnerability in the startup code - if the UM2 is quite cold (e.g. 5 degrees C) the unit may incorrectly fail to startup.

 

[illuminarti 18]

I think it's intended as a safety feature - albeit, perhaps a too-aggressive one. If the temp sensor is reading implausibly high or low, it shuts down, rather than risking heating without legitimate feedback. Clearly in your case the lower limit is set too high :-)

I would imagine that they can fix that before too long, and release a new firmware.

BTW, I don't know that it is going to be any particular problem, but bear in mind that your printer will probably behave very differently from others, given that ambient air temp - things like layer and bed adhesion may behave a bit differently than printing at room temp. Also, you may find it harder to print at higher speeds - at least without correspondingly higher temps than most other users use: since the melt chamber is very short on a UM2, the filament has to heat very quickly when passing through the chamber: from entering the hot part to being extruded may just be a second or two for fast prints. Starting 15º colder than 'normal' is going to make that that much harder. Just something to be aware of.

 

[abstract 3]

Follow up on Cold temperature startup.

So - every day this week I have had to wake up UM2 with a hair dryer. Normally it's just a question of getting past the startup temp sensor error - once I warm up a few degrees, it boots up and we can begin.

Today, I did the same routine, then went to maintenance and manually set the build plate to warm up. I went away for ten minutes and came back and the build plate was still at 3 degrees C. So it seemed that the warm up process was failing, even though we got past the boot up.

I suppose that perhaps the initial 'warm' with the hair dryer got it to boot but then it cooled again below the threshold and perhaps the same sensor now stops the warm up (but no error message).

I dont experience *any* problems printing in that environment - once the build plate warms, the whole UM2 box gets nice and warm. One benefit is that after printing, the build plate gets so cold the models just pop-off automatically !

Anyway - this startup hassle is somewhat troublesome, and it would be great to see some work done on this.

Thanks !

 

[gr5 2,265]

Interesting. Other's have said that the print head won't turn on until it reaches a temperature above 5C. This has to do with the electronics that report the temp which can't measure temperatures at 0C or colder so it's tough to tell the difference between a failure and temps at or below 0C.

I don't know about the new build plate temp sensor on the UM2 - I don't know what technology it uses but I had assumed it was a different technology that can read lower temperatures. I just don't know. But there may be an arbitrary limit of 5C for that as well.

 

[abstract 3]

Interesting. Other's have said that the print head won't turn on until it reaches a temperature above 5C. This has to do with the electronics that report the temp which can't measure temperatures at 0C or colder so it's tough to tell the difference between a failure and temps at or below 0C.

I don't know about the new build plate temp sensor on the UM2 - I don't know what technology it uses but I had assumed it was a different technology that can read lower temperatures. I just don't know. But there may be an arbitrary limit of 5C for that as well.

 

I guess my suggestion for a fix might be that if the low temp is detected (cold or failed temp probe), the firmware should turn on the heater for 10 seconds, then try again, before failing.

 

[Daid 306]

I guess my suggestion for a fix might be that if the low temp is detected (cold or failed temp probe), the firmware should turn on the heater for 10 seconds, then try again, before failing.

 

And potentially cause fire? Nope. Safety first. Always.

I think the limited could be drop to 2 or 3C, but the current code is not made to handle anything below 0C, and you need a slight safety margin between that and your minimal measurable temperature.

 

[illuminarti 18]

But is it really a fire risk? If you only override the safety when initially starting to heat, and only for a few seconds... just long enough to see whether the heater starts to report a reasonable temp increase. Once it has started to heat, it should never go back to below mintemp. And equally, a few seconds of heating shouldn't suddenly cause the temperature to hit 200º either. But it seems that there's a small window in which the firmware could be a bit more intelligent. Perhaps have it as an optional feature that users can enable if it applies. Or even add a confirmation dialog via Ulticontroller, that asks the user to confirm that they're operating in a cold environment, if the heater-probe code gets triggered.

Worth thinking about, as it seems like several people have been running into this lately.

And potentially cause fire? Nope. Safety first. Always.

I think the limited could be drop to 2 or 3C, but the current code is not made to handle anything below 0C, and you need a slight safety margin between that and your minimal measurable temperature.

[jonnybischof 60]

As long as you can prove that your actions can't trigger a fire, then imho you can do something like proposed above. (Emphasis: That is my opinion, I'm no expert on safety standards and regulations, though I'm frequently working with stuff like that I can't answer to all the details without checking back first...)

If you calculate (and/or measure) your maximum heating power and some approximation of the thermal resistance / thermal capacitance, then you can predict pretty accurately how long it would take for the heater to reach a temperature that may cause any risks. Put in a large enough safety margin and you should still get a few seconds where you can safely turn on the heater without knowing anything about it's temperature beforehand.

But in the end, it's up to the manufacturer to decide about how safe he wants to be and whether to make any compromise or not. You definetly don't wanna have to take responsibility if some customer burns his house down (for whatever reason), so you definetly have to be sure about what you're doing and what all the possible consequences may be.

I don't see any problems with the "heat for some seconds without knowing the temperature first" idea, but I didn't take much time and consider every possible effect this may have.

 

[Daid 306]

Worth thinking about, as it seems like several people have been running into this lately.

 

No, not worth it. I will not temporary disable safety systems. Not worth the risk and complexity.

 

[gr5 2,265]

I disagree with Daid. There has to be a simple and safe way to do this. For example a menu special menu option called "winter mode: heat everything for 10 seconds and then leave all thermostat temps at 30C".

Maybe bernhard will add this feature to Cura. I don't think he reads these forums so you would have to post over in ultimaker google groups. Or you can write it yourself, abstract.

 

[illuminarti 18]

Yes, I concede that it might not be worth implementing - or at least a high priority - if only a few people benefit from it. But talk of 'disabling safety systems' as if it's an obviously bad idea, is just arm-waving. This gives the impression that there's some self-contained, engineered feedback system that you'd be trying to defeat. There isn't. All there is is a heater, and a thermometer, and the firmware that tries to make sense of the readings from the latter, and control the output of the the former. The way in which that is done is fairly arbitrary, and there's no reason that it can't be designed to be more intelligent. It already looks for a reasonable temperature rise to occur during the start of heating, and cancels out if it doesn't see it. As well as shutting down if the temp suddenly goes too high, or too low. But there's no particular reason that it has to be unsafe to allow the user to make the call that the reason that the thermometer reads 0º at startup is because it's damned cold in here. Absolutely, if the temp suddenly goes to zero during print, you'd want to shut down, because that's clearly a fault. And if a user overrides the start up temp, and it still doesn't rise within a few seconds of the heater turning on, then thats a problem that the firmware can react to (and, indeed, already does). Indeed, it's arguably a more considered approach than simply saying a low value must be bogus, while any reading of 5º or more can be trusted.

 

[gr5 2,265]

I think Daid's point is that if you add a 10 second timer and you have a tiny bug in the code you might defeat the existing safety features. What if there is a subtle bug that occasionally resets the 10 second timer - often enough to cause it to melt. What if the timer gets set to negative -4000 seconds so that it doesn't time out for an hour. These kinds of bugs aren't normally tested for because to test for it you have to purposely disconnect the thermocouple wire. That is the potential danger here.

Anyway I still disagree with Daid - if the code was not in the normal set of operations but if instead you had a special menu item that blocked all interrupts (or stopped returning from the loop or however it works) for 10 seconds (ignored USB also) and just turned on the heaters for those 10 seconds. Then you wouldn't have to worry about introducing a new bug that circumvents safety. The code would be self contained and not normally used (not used from any gcode for example).