upatamby

The magic trick was a factory reset. Since then, manual leveling works again as it should, with the Z offset being stored correctly. Active leveling also works fine now, but only when the frequency is not set to Never. If you perform an active leveling and the frequency is set to Never, or you set it afterwards to Never, then the printcores are invariably too low. So I suspect that @V3DPrinting has set an Active leveling frequency on his printers that is not equal to Never. Is this correct? So I have to choose: either set a periodic active leveling or do manual leveling only. Thanks to @gr5's tip (the quick manual leveling procedure), I choose for manual leveling only. I would like to add to that tip that when using the quick method for setting the back with the calibration card, you should not turn the rear buildplate screw but turn the wheel on the front (contrary to what the display says). Things I have checked: - springs of the print cores: ok (around 1100g) - buildplate height: ok (that check was already in my program) - sensor: "Good" - grease: not needed; print core is stable at its place - Curvy glass plate: test print gives no indication of this. An extra check could be: a bent X- or Y-axis (the thin axes that go through the printhead)

Thanks again for your answer. I love stupid questions, because sometimes they lead to new insights 😉 . In this case the answer is that I do turn the knob on the display for setting the second extruder. The new insight is that this rotation must be stored somewhere and that seems to me to be a task of the firmware (just like storing the data during active leveling). So firmware does play a role in manual leveling. Manually adjusting the buildplate while printing a skirt or the first layer is something I already do (although it should be redundant - why else would you need active leveling?). I always make sure the nozzles are clean. I have always done manual leveling with cold nozzles (default behaviour of the firmware). But after your advise I did manual leveling again but now with warmed up nozzles. A level test print showed that extruder 1 was printing correctly everywhere, but extruder 2 was now slightly too high. You can't fix that during printing by turning the screws up, because then extruder 1 will be too low. So you have to do manual leveling again (although a working active leveling would solve this automatically). Again: if you could adjust the Z-offset manually (via the printer menu) at that moment, that would be a great option. I have now (against my better judgement) tried active leveling again, but extruder 1 was printing too low as usual. I'm sorry, but I don't feel capable of experimenting with sending gcodes. I have to skip that. At the moment, I have no choice but to carry out manual leveling and then test with a test print whether the Z offset is correct. Unfortunately, it is very time-consuming to have to carry out the entire manual leveling procedure again just for an incorrect Z offset. As for the use of the Calibration card, I wonder if you can replace it with an ordinary piece of paper. The thickness of that card seems to me to determine the initial distance from the nozzle to the buildplate. Only if you also do an active leveling (which must work correctly!) then this distance will automatically be adjusted to the correct value. In short, a real solution is still very welcome.

Thanks for the link! I installed firmware version 5.2.17 for my UM3E. Unfortunately it didn't solve the problem. In fact, both extruders were now printing too low. I tried with Active leveling frequency set to Never and also to Manual. I also tried rebooting before each active leveling (this has helped in the past), but nothing worked. Because I didn't feel like spending more time on this, I set the leveling frequency to Never and did the manual leveling again (this was the 'solution' I also used for firmware 5.3.0). But to my unpleasant surprise, this also didn't work properly anymore: extruder 2 was now at the perfect height, but extruder 1 printed too low. If even manual leveling no longer works this really is a problem. Extruder 1 was a 0.4mm extruder and 2 was a 0.25mm extruder. This might have to do with it, but I did not have this problem with firmware version 5.3.0. However, I tried again with both 0.4mm extruder extruders. After manual leveling they printed fine, but after active leveling extruder number 2 was too low again. So firmware version 5.2.17 doesn't solve the problem for me. For now: I will wait for a real solution and, in the meantime, try to forget that there is such a thing as active leveling with this printer. Just a thought: perhaps the Ultimaker firmware programmers could add an option under Calibration to manually adjust the Z-offset (per extruder). I think that would be very usefull as long as the active leveling problem is not solved properly.

I don't think version 5.2.11 does solve the problem. I really would like to get version 5.2.17, but I haven't found a way to get or restore that version. Until then I just quit using active leveling because it causes more trouble than benefit.

The problem is back in 5.3.0. 😡 The right extruder tries to print into the glass plate again after active leveling. It makes no difference whether I set the Active Leveling Frequency to Never or Allways. I have no time for this. I now will try to find out if/how I can downgrade to firmware 5.2.17. All help is welcome.

Great. After 3 years, someone from Team Ultimaker tells me that I should have posted my issue in another place in the Ultimaker community so it would end up with someone else from Team Ultimaker. In other communities it is not uncommon for a moderator to move an incorrectly posted message directly to the right place. Great teamwork, Ultimaker! 😒

I agree, but the developers have other priorities, such as a fancy Marketplace... That's why I've stopped giving free feedback, because it takes a lot of effort and is not very rewarding.

I would like to see this new feature in Cura. Sometimes a high model like this: gets unstable at the upper layers. To solve this I looked in Cura for the option to stabilize walls. Unfortunately this does not exist in Cura, as far as I know, but it does in other slicers. See the video below that perfectly describes why such an option makes sense and how it could be implemented.

The prime blob is enabled by default. I find the prime blob very useful because it reduces the chance that the filament will start extruding too slowly. The change I'm asking for seems extremely simple to me: just don't let the build plate rise before the print head has taken some distance. It surprises me that this simple change isn't realized, and it keeps me from bothering to report several other small bugs (the priorities apparently lie elsewhere).

Same issue here. Thanks @leliep for your instructions. Those made it quite easy to fix it myself. I didn't put the wires back around the connectors (as in the 2nd picture of leliep) because that made the wires very tight.

Same problem here. "Reset Cura Connect" solves it, but only for a while. This is how it looks in Cura And this in Cura connect: I also noticed that sometimes the printer asks me twice to confirm that I have removed my print.

So it's clearly a bug in Cura. Thanks navigator for this work around.

Today I tried to add a new material in Cura (via Preferences, Configure Cura, Materials). I duplicated the Generic CPE and then started to change some settings: Display Name: PETG Brand: BrandXYZ Material Type: PETG (doesn't exist in Cura) and then, as soon as I leave the last field field, the material has gone, without any warning or message. Another material (ABS) is then selected. At first I didn't notice that this happened so I entered several other values, but I was altering the wrong material! Unfortunately there is no Cancel-button on this form so I wasn't really happy. So please UM/Cura-team, - add a Cancel-button to this form - support unknown materials OR give a clear warning before throwing away my entered data OR make the Material Type-box a selection box. Thanks!

Thanks to peggyb I looked a bit further and then I noticed another preference setting: Zoom toward mouse direction. That is almost exactly what I wanted. There is only one (smaller) annoyance: the zooming goes in big steps. I would prefer a smoother zoom-behaviour. But that might also be a problem with my Logitech mouse.

Thanks for the tip. But selecting an object is not always what you want, because as soon as you select an object you also select an action like move, scale or rotate, and then you could accidentilly make unintended changes. So I still hope for an implementation of my request.

Hi, I have a request for Cura. When zooming in or out, the zoom function always uses the center of the screen as the origin-point. Many other (design-)programs use the current mouse-cursor as the origin while zooming. That makes it much easier to go quickly to a specific point without having to switch between zooming and dragging all the time. You just point with the cursor to a point and zoom in to that point, just by using the scrollwheel. Inspecting another detail would also become very easy: zoom out, point to the other detail and zoom in. Thanks!

Thanks @cjs for your detailed answer. Yes, I did print with the prime blob disabled. PLA works fine, but PVA doesn't. Even with the prime blob enabled the extrusion of the PVA sometimes starts too late. This usually happens when I have the PVA loaded but not used for a while. In such cases, before starting a new print with PVA, I move the PVA manually until it starts to extrude (you could call it a manual prime blob). As an extra assurance I also keep the normal prime blob enabled. If necessary I use tweezers to rescue my print from being hit by the PVA-blob. It's not ideal, but I'll deal with it. It's better then an unsuccessful print. I'm not confident to change the firmware code (at least not in the near future). And besides, that would be a task for the Ultimaker team.

@Brulti, @gr5, @ghostkeeper, @ahoeben As you are using 'my' thread to arrange meeting I hope that meeting will be about the prime blob. Good luck to all of you, I expect a great solution.

That's exactly why I like to use that prime-blob. @Daid Is it really that difficult to change the firmware so that after the prime blob is extruded the print head and print bed do not start moving together, but have the print bed wait a second (until the print head has moved away) before it starts raising? This would solve the whole problem.

I'm using hairspray now for a while. This is an excellent solution for the PLA-prints, but it's not enough for the PVA-blob. I think the primary problem is the movement of the printbed that causes a collision between blob and printhead. That should be solved in the firmware and/or slicing software. All other solutions are just work arounds.

See:

I tried using glue but that didn't work. Perhaps PVA slurry will work (I didn't try that). But just grabbing the blob with a pair of tweezers seems an easier work around. I think the main cause of the problem is that the print bed is raised before the print head has fully moved aside. The collision between the blob and the print head should not happen. Of course there are several work arounds, including not printing a prime blob at all, but I would prefer a software change so that this collision doesn't happen anymore. Is this possible?

Cura version is 3.1.0. Printer is Ultimaker 3 Extended with firmware 4.1.4.20171204

Hi, I'm new to 3d-printing so I prefer using the standard settings of Cura. Every print starts with a prime blob. I guess that's ok. But as soon as the prime blob is ready the print bed starts raising at the same time that the print head starts moving. That causes the print head (to be more precise: the bottom of the front fan) to hit the top of the prime blob. If the prime blob is PLA then it just flattens a bit but it stays on its place. But if it is PVA then the prime blob often falls down and sticks to the print head. The print head then drags the blob onto the center of print bed, ruining the rest of the print. Request: Isn't it possible to alter the Cura-software (or is it the firmware?) so that the print bed waits a second before starting to raise after the print head has started to move to avoid this collision?