Daid

(It stands for "FeedRate" which is a bit silly actually)

I think it's great for users that know the ins and outs of the software and know perfectly what they are doing. I also think the current ordering of settings is better. Because now they are ordered in how often you would need them, and how far you are in "tweaking" when you need them. Design wise your idea makes perfect sense. And I think KISSlicer, Slic3r and NetFabb are doing this. It's also what makes those pieces of software harder to use then Cura. I am thinking about how to better implement profile selections with material selections. But this is quite critical to get right, get it wrong and you confuse people even more (see Skeinforges profile selection)

Support material still needs some more work. I know it. The 13.06 version generates support that is usually a bit easier to remove as it has a "top" gap. But it doesn't have a sidewards gap as the old support, causing it to attach to the sides sometimes. I don't think the lack of support is directly related to being a hook shape. But I've also noticed that sometimes there is no support where there should be.

Yes, because nobody knew exactly what the packing density did. And the flow can easy be tweaked on the UltiController, and because flow in % was easier to implement, I opted to implement a flow adjustment. (This was also requested many times for the old version )

Note that I've been working hard to fix the OpenGL related issues with some testers. The results so far are very good. 3 of the 4 problems are fixed. And I have just send out a test version for the last issue.

One thing you could do is turning the big wheel by hand a bit before continuing. It's a bit hacky, but it works. You could also modify the plugin to cool down and heat up. But you would still have some oozing. (And, it's not due to gravity, as it also happens if you have your printer upside-down)

How did you install it? Used the deb package or the sources from github?

Well, if the first-run worked then python is working. I suspect an error at the OpenGL side of things.

If it's every 5 seconds, then it's the SD card detection feature which can be disabled in the preferences. If it's when the slicing is starting, then it's the virus scan issue. I'm working on both issues and will most likely upload a test version at the end of this day.

Ah, that's a sizing issue. The button is hidden behind the 3D window. You can resize the side-bar and the button will show. Something I will look at. I'll check on the Mac I have today. Most likely it is a bug somewhere. I've been changing a few things on starting the slicer to work around the problem that Lars has. I've changed the way the SD card detection works so it will no longer block the GUI (still need to test this). And I've been looking at the OpenGL backwards compatibility issue that someone showed to me on the UltiEvening (and was reported before, but now I understand what is happening) It's the "glCreateShader" popup.

In the installation directory there should be an output.txt, could you post the contents? (I do not have Windows8, but I have had reports that Cura works on Windows8. So this might be surface related)

Peggy, the "missing plugin tab" is most likely caused by unable to find any plugins. Could be a macOS issue. I'll have a look at it. Lars, now that I know the cause, I can simulate the same behavior, and fix Cura for it. Kaspersky might fix it, but you'll never know when, if, and if another scanner might cause the same problems. Edis, there is a plugin that can do this. 12much: Joris is missing for now but will return. Support materials need a bit more work, but the first layer is cross-hatched, so it sticks better to the bed. The rest of the layers are only in a single direction.

Nope, missed it because it fell off the previous page. What I'm seeing is a "delay" due to starting a process. As it happens between when the button turns gray and the progress-bar shows. The only thing happening there is starting a process. There could be a virus-scanner causing slowdowns here. But I have some ideas on how to fix this.

Lars, tried disabling the SD card auto detection as suggested?

I'm working on a compatibility mode! I tried to get it in the release but it's not working properly yet :( I do not have direct access to a "bad" machine all the time, so it's a bit tricky to test this. The compatibility mode actually works, but the detection of features fails causing the compatibility mode to fail to activate. (If you feel like hacking around, in "Cura/gui/util/opengl.py" there is a function called "hasShaders", if you change that to "return False" instead of the more complex test it might just work for you) EDIT: "Older machines" is not really the issue here, I have a very old laptop that supports the new code fine. But it's machines without proper GFX driver support that are causing issues now. I'm on it, and I hope to have a fix out soon. There is also a problem with some slowdowns caused by the SD card auto-detection that slipped under my radar.

Oh, and 13.06.2 is live on http://software.ultimaker.com/ !

Mmmm, the auto-detect SD card. Yes. That could be troublesome, it needs to do some checks on if a card is inserted, maybe this is causing huge lockups on some types of card-readers?

We did a change-over at Ultimaker. No noticeable change in print quality.

Just because Lars has a problem and other people don't, that doesn't mean that the problem isn't there. (Just as the "context invalid problem" that was plaguing some users) But it makes it a lot harder to trace the problem down.

UM 100micron used to be unique. Now everyone is starting to do 100micron. So we are switching our high quality setting to 60microns. There might be some places that still show the UM as 100micron, but we are updating most of those to 60 when we spot them. We can also do 20 micron, but that's really just advertisement, as going from 40 to 20 micron doesn't yield real visible quality improvement.

This is actually a bug inside of Cura. The new cura beta http://software.ultimaker.com/Cura_closed_beta/ solved this.

http://reprap.org/wiki/Ultimaker's_v1.5.7_PCB

The problem with adding a workaround is that the workaround stops finding a proper solution. I do have made some tweaks for the release out today which could help.

I also run test on a HP Pavilion dv2 from 2007. Which has windows Vista, a bootup time of 3 minutes, 2GB of ram, a 1.6Ghz AMD MV-40 CPU and a ATI X1270 mobility GPU. Which is pretty much lot grade to crap these days. And it runs the beta fine unless I load high poly models. And the slicing doesn't cause any noticeable slowdown. As it should, as the slicing is run as lowest priority on your system. The only thing that might be causing a slowdown is the fact that the 3D window gets re-drawn during slicing to update the progress bar. If this is the cause, then you have something that is causing the 3D drawing to be really slow. Maybe no 3D drivers installed, or something else hogging the GPU. Why am I not adding a setting for it? Two reasons. First because if I would add settings for everything that people ask settings for we would be at Skeinforge again at this point. Second, because I still think that this is the best idea. Any performance issues can be solved, and I have already made a few adjustments in respect to this. (As the GCode loader was a much bigger performance offender then the slicer)

The Z nut should be able to move in the X/Y direction a bit, this is to prevent Z wobble. (The Z axis is not perfectly straight, and thus wobbles a bit, the play in X/Y makes sure this doesn't translate to the bed)