sj3fk3

They cycle with every reboot (and it keeps the previous one). So you always have now + previous logfiles and it cycles once it exceeds 64Mb.

Hmm, I think the abort somehow got aborted. It would be really nice to see the log files, but I'm guessing they are already rotated away by now. If you see it again, please file a rapport and send us the logfiles. Meanwhile I will see if we can reproduce this.

Was the abort finished and did you press "confirm removal"? Or was there something else still going on?

Hi Jonas, Maybe the change printcore did not work correctly after the error? It has been tested well under normal circumstances (with material parked above the printcore) by us, but I have seen a case where it did not work correctly after the printer was in a errors state. We are currently looking into this case. Can you confirm that the change printcore works with material in the parked position?

We have explained this before in the forum. We knew that 5.8.0 did not have the unload functionality. We wanted to get 5.8.0 out as soon as possible, because MANY users had really big problems with printing PVA and the "park filament" functionality would greatly help those users. We also though that not being able to unload was not that much of a problem because if you just start a print with an other (Ultimaker) filament, the "wrong" material would then unload. I agree we should have been more clear on this when we released the Firmware, that was a mistake. Releasing 5.8.0 was not a mistake, because we did help a lot of customers who wanted to print with PVA. I think we did also misjudged the amount of pro-bundle users that do not print with ultimaker filament. We started working on the unload functionality even before 5.8.0 was released, and we shipped 5.8.1 (with the unload function) within a couple of weeks of 5.8.0. The only thing new between 5.8.1 and 5.8.2 is the much improved NFC reading (you will only notice this if you use Ultimaker filament) and we introduced a Wizard for ER52/54 and ER56 loading errors during a print. So I have no idea why canceling a print would work fine in 5.8.1 and not in 5.8.2. But we would like to look into it. That is why we have asked you to contact support about your issue as it is not something that we see happening when we cancel prints. Regards, Greg.

Dear Roland, it's an english expression "to call somebody names". It's means "when you say unpleasant things or insult people". It has nothing to do with your (or my) real name. And I was not trying to insult you, I was just saying that I think we all should remain professional and respectful to each other in this forum. If you wish for professionalism, lead by example by keeping it professional. Like I said before, I don't think calling developers "hobbyists" helps in any way. There are plenty of them here on the forum to help customers with issues. I think it's rather demotivating if you "call them names". We all work hard to improve the product, of course sometimes we introduce a new bug, or a unhappy flow. And believe me, we really don't like it when that happens. But I do think in general we are improving the product, that is also the feedback that we are getting (and this forum is not the only channel). We aim to update our firmware every 6 weeks, that's the "heartbeat" that we try to maintain. In a couple of months we want to switch too having 2 distinct tracks, one with a heartbeat of (around) 6 weeks and the other with only 2 or 3 updates per year. Customers can than choose, if the want the newest features, or remain on the current more stable/conservative firmware. I will say it again: You are entitled to your opinion and you may even be harsh and say that we are not doing good enough. I will take that feedback and work harder to improve the process and the product. All I ask is to please remain civil. Regards, Greg.

You are entitled to your opinion, my point is: If you start calling people names, I don't think that will help you. Let's try to keep things civil. If you want professionalism, start by acting professional. We are here to help and we like to help. You can help us help by filing bug-reports via support and voice your opinion here in a civil matter. Regards, Greg.

Hi there Roli? While it's clear that you are frustrated, I'm not sure if this tone of voice really helps in any way. I don't think the support people are going to be more willing to help you if you shame them or call them hobbyist. Frankly one could ask himself how professional it is to use those qualifications here in a professional public forum. We are all here to help out community and everybody is doing their best I think. We do indeed test our firmware (for at least 2 whole weeks) before we ship it. We test about 30 different abort flows alone and 200+ flows in total *every* single release. Of course there are always going to be cases that we did not forsee. If we find such a case we usually fix that within 2 weeks (+ 2 more weeks for testing) and then we release the fix within 4 - 6 weeks. That being said: Can you contact support as we would like to know exactly what triggers this behaviour, so we can fix it. Also when I read: "And it's necessary to have to cancel because the use of the Original BreakAway has not worked properly since 2 weeks." I think support might be able to help you there as well, as there might be another way to get what you want. Kind regards, Greg.

I'm afraid nothing really changed in the network part nor the webcam part for 5.8.1 Personally I like to default to printing over cloud even though my printers are 1,5 meters (corona safe) away from me. As printing over cloud is going to have so much more benefits in the feature. Are you using ethernet or wifi? We have found ethernet to be far more reliable in many cases. Also having a mixed network (2.4GHz and 5GHz) with the same SSID can cause issues for S3 and some S5's. n.b. We are in the process of updating the underlying OS of the printer. We hope this will also help in the wifi stability (new drivers and all). We expect this new (6.x) version to go public in before the end of this year.

Please make sure all your spools are aligned to the left. When inserting place them as far left (within each bay) as possible. We are working on improving the NFC reading reliability. For now this workaround should help in most cases.

We (The firmware team) are going to look into this. We have not seen this in our normal test-routines and we do always test all happy and unhappy flows. But we will re-test this specific scenario. Any special information about your setup? What kind of material was it?

Update: I'm very much pretty sure, we will not see this before 2021. But, we are going to go forward on this, so it's not forgotten.

Go check it out 😉

see:

Yes, er998 is a so called uncaught exception, that means something went wrong and the system had no way of "catching" this situation, the trouble with it is: It can be all sorts of things.. In the last couple of months (and in version 5.8) we have already solved a couple of causes for er998, but not all.. So working with support to give us the logfiles greatly helps us finding the root causes.

This is not 5.8 specific we identified this behaviour in previous versions as well and started investigating the root cause. We think we have found the root cause and will address this soon (after we fix "manual unloading" and some other bugs). If you make sure all your spools are aligned to the left of the bay it does work better.

Yes, we are working on that.. Together with upgrading the OS the printer is using, that's why it taking some time. But it does have our attention.

Yes, we are working on 5.8.1 (expect within 2-3 weeks) that will have unload and also contains some bugfixes that did not make 5.8. Yes, we are also going to fix that. Might not be in 5.8.1, but will then be in the release right after that one. That's clear. Thanks for the feedback!

We are also not in the US 😉 Ultimaker is a Dutch company, so I think we are "neighbors" 😉 LOL, I will try, espresso cappuccino?

That position looks right to me. We park the material inside the Bowden-tube a few centimeters up.

That does look like it's in the right position. We have seen issues with TPU (not specifically related to the 5.8.0 firmware), but more due to the flexible nature of the material in combination with the material station. We are going to change some parameters in the material definition that should help with this specific problem, that will be in the next release. For now, maybe try with a prime-blob? p.s. What do you mean with gadgets off? Is that a google translation gone haywire?

The filament will unload when you start a print with different filament. So if you are using UM Filament "the parking" should not really be a problem. The filament park position should be just above where the Bowden tube connects with the Print Core. If you are unsure, can you post a photo here?

LOL.. So true, we are not Philips 😉 Anyway, I will make not of this request, I do see the use, I'll discuss this with the team and with our UX specialist and see if we can do anything with it.

You can indeed downgrade the firmware, but there are other ways to work around the issue that you are encountering. This issue does not exist if you print with Ultimaker Filament by the way, so that could also be a workaround for now. If you don't want or can go that way: We are going to bring the unload functionality in a next release, so you could also downgrade and wait for that version (we will make sure to clearly communicate the unload functionality). It saddens me personally that you are disappointed in Ultimaker, we (the team and I) work very hard to deliver value for our customers and we try to please all our customers. We sometimes have to choose between two evils, as was the case with this functionality. We mainly introduced the "park above printhead" feature to help users in the field as soon as possible with issues they had with PVA brittleness and we also thought it would speed up printing a little (win-win you would think, right?). While I understand that you are disappointed, because in your case (printing with non Ultimaker filament), this parking also adds and inconvenience, I would also like to stress, that this is not the case for all users. p.s. We test our firmware very thoroughly, in fact there is a whole team of testers that test every release. Of course that does not mean that the firmware will be perfect in every aspect and for every use-case. By we aim to improve our product, with every release that we make. The engineers that are developing and testing the firmware are very dedicated to their work and our customers, they (like myself) are also active on the forum. We love to get feedback, even if sometimes the feedback is a little harsh. We embrace it, because we need it to make our product even better. So thank you for your feedback! I hope we will make you a happy Ultimaker customer soon again 🙂

Now I feel silly for not ready the whole thread first. Sorry about that! That actually should work what was the error you got when you aborted the print? And when exactly did you abort? Can you try again? See if you hit the same snag.