Daid

It's hard coded at 60 right now. But if you hack Cura/util/sliceEngine.py this is where the actual engine gets called. Search for 'supportAngle' there you'll find the hard coded 60.

With a raft enabled skirt gets disabled.

The SF infill routine worked quite different from the current routine, as it also added a partially extra perimeter line as part of the infill. This causes a whole different bonding with the sides then the new infill routine. If you would use -35% on the new infill it would not bond with the side walls at all. (you can actually do this, but it does not make sense) Once again, I see no issue here, except for comparing 2 vastly different methods. The "diagonal overlap" from illu might be an issue if you have a 0.4mm horizontal shell, but I do not think it will effect the actual print in reality. Extrusion has a way of taking the path of the least resistance.

You're asking for a 100% overlapping infill with the wall, that's what you are getting if you account for the fact that the wall is 0.4mm in width. Exactly as designed.

Odd, there is code in place to account for this "switched around fan" setup. Because, my home printer has this. I'll do some tests to be sure. See Cura/util/objectScene.py, it has "leftToRight" and "topToBottom" variables that it uses to see if it needs to go in one direction or the other depending on the head size. I do think 10mm is too little, a normal Ultimaker has ~18mm between the nozzle tip and the end of the head in the shortest direction.

Yes, few other people noticed it is missing. Big mistake on my side. At the same time the MacOS package broke, and I wanted to fix that first. Building a .5 package for linux right now to solve this.

As far as I know the .5 version fixes the "Cura error" problem. It can be downloaded from http://software.ultimaker.com/ The root cause seems to be some conflict in a system update I applied from Apple and a library I used to package Cura, causing the final "Cura error" if you ran it on a different system.

There is an "Extrude" and "retract" button in the "Jog" tab of the USB printing interface ;-)

Yes. Retraction. Print this one: http://www.thingiverse.com/thing:34942 At "full machine scale" with retraction enabled. That's how I've managed to kill every "all metal" hotend so far. (works with the stock hotend)

There is a .5 version now. Yes, I know, lots of version in a small time. But the Mac I used to build it "changed" because Apple software update ran, which caused issues unknown to me...

I would also lower the temperature a bit more, 200C might help in this case.

Show me this "this should be in the box and you have X time to check it or we won't help you" card, because that's what calinb is suggesting.

That's no real issue. It happens on a communication error, but this error gets corrected. (I should filter out those messages) Ah, yes, the reload is missing. Need to think on what the best way to add this is, with multiple models and stuff. The support with raft is giving a problem, as the support material does not have a raft. Should work fine with a brim, except that the support is printed on top of the brim if the brim extends far enough.

Not sure why this starts to pop up now all of a sudden with the new version. But I'm working on a fix. This one might solve it: http://software.ultimaker.com/Cura_closed_beta/Cura-13.06.4-Cura_Error_Mac_Test1-MacOS.dmg

Daid, That web page (which I've never seen before) is nine pages long when printed! I'll call it obfuscation! I'll wager there is simply no way that 90% plus of Ultimaking Ltd. customers are going to parse though all that crap, even if they manage to find the page. Those are quite usual standard terms that you agree on before placing an order. I think you have to tick a box that you agree to these terms. But it only took me 2 minutes to find the page and the replacement bits part with the 2 weeks. Putting a card with "look we are not certain if your box is complete, could you check it yourself?" doesn't give you the best confidence in our product right? From a marketing stand point only an idiot or an engineer would do this.

From the shop terms: https://shop.ultimaker.com/terms 7.4. Missing parts should be mentioned in writing or by e-mail to ULTIMAKER within fourteen (14) days after the delivering date. And I don't think we actually do an exact 14 days, I would not be surprised if someone finds out a piece is missing within a month or two then we also replace it. But as Sander says, the line needs to be drawn somewhere. I think his kit is lacking all electronics, not just the Arduino. These: https://shop.ultimaker.com/en/parts-and-upgrades/electronics-v1-5-7.html

Thankfully Apple and MacOS are super helpful here (NOT!). What can be happening, and I have no idea why, is that previous versions of Cura are still on your Mac system and those are causing problems. People have reported solving this issue by removing previous installs. I have NO clue why that works, and how Apple managed to make a OS so fucked up that different installations of an application mess each-other up. (Between Windows, Linux and MacOS. MacOS is the most hostile enviroment I ever programmed on. It really feels like random shit goes wrong on random machines for random reasons) I've build 13.06.4 the same way as all the previous 13.06.X versions, so why the new version would suddenly crash, I have no clue...

How thick are those layers?

Try the .4 version I just uploaded, and you'll most likely need to configure the proper serial port in the preferences for a Prusa (depending on the electronics used)

Oh, I just tried, you can just double click it, this opens a terminal window :-)

What happens if you try to run this executable in a terminal?

Could you check the following for me. Goto the Cura application in Finder. There click on the Cura app and do "open package contents", then in there goto Contents and then Resources. There click on the CuraEngine and do "show info", could you tell me what it tells at "file type"?

Ah, yes, fixing that now!

Yes, the 13.06.2 release is broken on Linux. The git version seems to work for people. A new version will be released soon.

Ah, look, there is the issue. The auto-detection-serial code assumes that you have an USB-serial device. Apparently Melzi electronics is using a different driver. However, I knew this would happen. There is no real issue here, except that you manually need to configure the proper serial port in the preferences, then the auto-detection checks for that serial port instead of finding an USB-Serial device. (Note, I have a plan to improve none-Ultimaker support. But I have to do that mostly in my free time. There are a lot of RepRap variations, and the first one I will look at will be the PrintrBot, as I can easy access one)