Daid

Oozing, nozzle height differences. But making sure none of the nozzles clogs up is also important. Hotends are strange things, you think you are almost there with an almost perfectly working nozzle, change one minor thing, and suddenly, it no longer works.

Deze aanpassingen zitten nu in de Ultimaker2Marlin versie: https://github.com/Ultimaker/Ultimaker2Marlin Dus, als je je eigen firmware compiled kun je nu de MAX6675 gebaseerde temperatuur meting gebruiken.

And on low temperature, the stringing shouldn't be that bad at all.

Which version of Cura? (Cura never really writes anything to disk, unless you ask for it, as of 13.06, so there much be something strange going on)

No it won't. As it still needs the information about what is a sub-object. And as dual-material prints "touch" it's not properly possible to separate that on load. STL is fine right now for single material prints. But it won't keep up with the complexity that we want in the future.

Does this also happen on a square tower? If not. Then it's most likely the firmware which cannot keep up with the high amount of GCode commands. For a Delta printer the firmware needs to do quite a bit more processing and this could result in micro pauses.

I've done PLA+PVA. But ABS+Ninjaflex could be beyond Cura's complexity right now. Due to ninjaflex requiring a pretty low printing speed. (unless you print both very slow)

It's one of those legacy things in Cura right now. While it's just speed for the UM2, it's speed and temperature for the rest. And due to how the translations of Cura work, making this depended on the printer type is one of the things that would make it complex to handle this properly.

This. As I understood, the picture of this in the manual is really unclear. These things are bronze. And look like this:

http://software.ultimaker.com/FirmwareSource/ That's the firmware straight from github.

I don't think you'll be having any swapping with 16GB of physical ram. So it's a mystery right now what's actually causing it. Might be very hard to pin down.

Well, in that light. What's happening is that a new "backend" for the shop was made, as the old backend was giving a lot of problems for customer support. Putting a lot of workload on them. Now, something (I know of no details) went wrong with deploying this new backed. Which is causing the above issues right now. However, the end goal is exactly as you actually want, improved customer service. It's just that it's a bumpy road right now. (We had our x-mas gathering yesterday evening. And we stayed a bit longer at our R&D office after that with a few people. However, when we left, we spotted Sander still at the main office at 21:00. So I think he was still working on the situation)

Yes. But, computer scientists decided that it's better to use X/Y for the screen and Z for "inwards" the screen for 3D drawing space. Which is why we have different variations now.

I actually ask for an instant kill, not a nice shutdown. But swapping could be causing slowdowns. However, that means he would be low on physical memory, which would be... odd.

That does not tell me much, or actually anything. As there are 2 different problems described in this topic.

I understood that CW does that. However, actually doing this is a bit more complex then it sounds. My code currently calculates a number of "insets" these are the lines that you call perimeters. These are calculated with an offset from the outer model boundary. So there is an offset at 0.2mm and one at 0.6mm (for 2 lines). With the example of a plate with 4 holes, that means both the 0.2 and the 0.6mm offset have 5 "lines" in them. However, at this point, I do not have the relationship between those two sets of lines. So I do not know which of the 0.2mm inset belongs to the 0.6mm inset. To make the problem even more complex. It's not guaranteed that what was 5 "lines" at the 0.2mm is still 5 "lines" at 0.6mm offset. It could be that lines touched each-other and where merged into a single line. So suddenly there are 5 lines at 0.2 and only 1 at 0.6mm. So you have a complex relationship there. Now, for print quality reasons, you always want to print the outer walls from the inside to the outside (this helps with overhands as well as outer skin quality) So the problem is: * Finding the relationships. * The relations ships are not 1 to 1. But [n] to [n]. * With that relationship you want to print them inside out.

That... sounds more like a bug from my side.

This laptop is indeed running on an SSD. My old laptop is running on a 5400RPM disk. But, Cura isn't doing much disk access, as it tries to keep everything in memory. Only log files and final gcode files when you press save are stored on disk.

That's a shame. But thanks for trying. Maybe slowing down the first layer even more will help? (As CW is definitely printing the first layer a lot slower then Cura) I don't think I'll be changing this anytime soon. The required changes for it in the engine are complex, as it's a complex problem. Explained it to a fellow software engineer and my intern, and they both agreed with the complexity for a problem as a whole. But it's hard to explain in text without a whiteboard to draw things on. So I rather see some other setting that can be adjusted to prevent your issue. As I do hope we can work around the problem that you're having.

The Cura developers to it's users that get the whole software for free even tough they did not pay a single cent for it: Don't be an asshole. Thank you. And yes, some people have good suggestions. And some people have awful suggestions. Guess what, I get to decide which is which! Which is fun! For me, not for you. Sorry. Lots of great suggestions have been implemented already. Nope. It's designed, tested and build on Ultimakers. Because, that's what I have, at home and at the office. That's what started Cura. And that's what pays for my food&home. Any other printer support is just extra. It's me being a nice person, and Ultimaker being a nice company. The readme used to say "Cura is developed on and for Ultimaker 3D printers, but can be used on other printers as well" Now, you can print just fine with Cura on a printrbot, but you need to make some adjustments to settings that you are unwilling to adjust. And because of that you think that I need to make very complex changes to my code that does not add a huge amount of value and does not actually solve your main problem just hides it a bit more. (Same for my suggested setting change, but you can do that without me needing to add a lot of complex code)

Yes, yes, and yes. So that's most likely not what's triggering it. (i5 2.6Ghz, 8GB ram on this laptop). Also not seeing this extreme effect on my slow 6 year old Vista laptop. I'm also wondering why that is. But it's good to know that that can happen, and that I should handle it better. Got a few more reports that people who slightly experienced this issue have less problems with the RC2 or RC3, but that it does not solve it 100%.

Yes. And we can also setup a community plugin repository. So not everything has to be in the mainline, but if you want more advanced tools in Cura you can just install those.

~20 reviews versus ~150 reviews isn't that great from a statistical standpoint according to the computer scientist at the office.

There was, but it does not help on tubes. In case of an L shape, it will put the seam in the inside corner instead of somewhere on the outside corners.

The RC2/RC3 changes a few things in regards with this and should increase performance in this case according to a few testers results: http://software.ultimaker.com/Cura_closed_beta/