Daid

Any firewall or virus scanner software running? I think I just found the bug which has been causing a lot of headache for me the last few days. (The object way off the platform problem)

Inner skirt lines are no long put down in the latest RC6, and when using brim they are put down when they are still big enough, always leaving a hole. I did put up an RC6, which also fixes retraction-settings-saving on the UM2 firmware. But there is still a bug in there which causes the slicing to fail because something internally went wrong. Still working on this bug (it's the bug that cause a 500milion position offset. The RC6 detects this case and aborts. Which is slightly less troublesome as it does not try to destroy your printer. But still not what you would want) Neoxm3, was this with RC5? You might have some path bug? What's the full path name of the file?

45mm/s is way too much speed, but older buggy firmware needed this. Usually 25mm/s retraction is what you need. Other then that, I try to supply good defaults in Cura.

Latest RC from http://software.ultimaker.com/Cura_closed_beta/%20should%20print%20the%20raft%20with%20the%20support%20material%20hotend. (Freezes of the RC have been reported with outdated zone-alarm doing funky stuff)

Bitcoin is not a stable currency where you can build on. Only reason some companies accept it is for marketing reasons. Only reason people use it as a currency is because you could buy drugs with them in an untraceable way. Also, it's very unstable (drop of 40% in value in 2 months?)

Ah, ok, I missed the fact that you tried dual-color printing. The dual-extrusion for Makerbot has been reported broken, but nobody figured out how to make it work yet. So Cura can only do single-extrusion for Makerbot right now.

The M0 has some issues on the UM2. Cura 14.03-RC6 has a newer firmware: http://software.ultimaker.com/Cura_closed_beta/ This firmware has a pause function in the Tune menu. Allowing you to manually change the filament. (Not the best solution, as you have to pull out and push in the filament yourself. But workable)

I'm not 100% sure if I understand it correctly. But I do think I know the cause. What the Cura code does is when it need to check if somewhere needs solid infill it looks down X (usually 6) layers, and checks if there is a solid or open space there. If it's open, then it needs solid infill, else sparse infill. In this case, the filled bottom layer causes the higher layer at layer 13 to be "empty".

I can see the same in the Cura GCode viewer. I know where it comes from, however, I haven't solved it yet. I might need to increase my resolution from 1 micron to 0.1 or 0.01 micron. Which is a bit complex. I've started on changing stuff for it. But I haven't reached the end of all problems yet.

The UM2 is already using this estimate (also shown when you select a file), however, in the math something goes wrong while printing. Especially near the end of the print it will suddenly show 6 hours. Haven't found the time to look into it yet.

Good catch Illuminarti! Thanks for the detailed report, that really helps in tracking this down. Fixed it: Old path: http://i.imgur.com/RwHGzpL.png New path: http://i.imgur.com/gkw99Dg.png I missed the reply there. Sorry (busy with tons of stuff, and forum is very busy). Checking it out right now. I do have test machines with fans mounted in X+ and X-, but not in Y- (as that would hit the back of the machine. And it seems something goes wrong there. Note that the code has been changed quite a bit (but still lacks a lot of comments) sinds your comment about it. EDIT: Just tested with the fan on Y- in 14.02-RC5, this works, however, changing the head sizes requires a restart of Cura for some reason...

I see a layer that has a different then 45deg angle infill, I think you mean that? It's most likely an incorrectly detected bridge. Which happens sometimes.

230C and 110%-120% extrusion usually does the trick to get a large amount of the Joris prints water tight.

Cura 14.01 had 2 bigs, where the inner holes on high polygon models sometimes went missing. It also has a long standing bug where the initial layer height was used a bit incorrectly causing the models to be 1 layer higher then they should. So the 198 layers is correct, while the 199 was a bug. The viewing problems is a change to speed up the rendering. I know it can be a bit confusing, but if you scroll down trough the layers the infill will show. The stable download is hold back by an annoying bug. Sometimes the print is way off the platform. But it seems to happen totally random, and I have not found the cause yet...

Never seen this problem happening on an Ultimaker. Maybe you're getting less extrusion then you are expecting? As visible in the layer view, the brim is connected. (The layer-view parses the GCode and calculates extrusion widths from that)

The roadmap is in my inbox. It's private for a couple of good reasons. One of them being that you cannot hold me to it. (Select-able support material has been on it for 6 months already, and has been pushed back a few times) The other is time. Some features are 3 words on the roadmap, but require a lot of words and pictures to explain. I pretty much could fill a full time job by just writing out the roadmap in a way that people outside of Ultimaker would understand it. Nallath, my trusted minion, and colleague, is working trough the whole issue list, closing just about anything to clean it up. If you think something is closed but should not be closed, feel free to open it again and state why. There where 300+ open issues. So this is the quickest way to clean them up. How we are planning to deal with incoming issues on the issue tracker is stated at: https://github.com/daid/Cura/wiki/Issue-policies We're currently working on totally re-doing some major parts of the code. That's why the issue list is cleaned up. This to incorporate all the things we've learned the last 2 years. The code base was still based on the early stuff I made when I started Cura. Due to the added features it started to grow into a mess. This new GUI, with new underlying code, will have much better support for different machines and different user requirements. We have some great ideas for this that I do not want to spoil yet. The new code can be followed on the PinkUnicorn branch. It's currently nowhere near functional, but if you dive into the code you can see things we are doing with scenes, machines, views and tools to structure everything better.

Yes, and, I hope someone will improve the interface. I quickly threw it together. But if something better comes along I have no problem in merging it into the main Cura. That's one of the main reasons why I setup the new printer windows like this, it's easy to hack, and easy to contribute this way.

I've not read trough the whole topic yet. Just wanting to let you know that we will be reading trough this shortly (as you can imagine, we're quite busy) The test however, is awesome. We've ran it on different machines with different results. The worst result we had was only 3mm/s^2, so that's bad...

Photos? The Repetier view says little. Due to the shading there, a tiny difference can look huge. There is a slight rounding in Cura. To microns (0.001mm). But that's most likely not causing this. Cura also optimizes the path a bit by removing some points of the path that are almost in a straight line. Which could be causing it in this cause, due to the small curve you see. More specifically, this code: https://github.com/Ultimaker/CuraEngine/blob/master/polygonOptimizer.cpp#L25 I'm checking it out right now.

We're still waiting for our Replicator. Currently the latest beta has the biggest chance to produce working GCode that Makerware can convert to X3G http://software.ultimaker.com/Cura_closed_beta/ However, due to it totally depending on user feedback and other people figuring out how to get it to work properly. I hope to properly produce X3G files once we have a Replicator. Note that Makerbot is the closest "open" machine you could get. They have been everything but helpful in providing support for other software then their own.

There are some limited parametric features in designspark. But for gears/pulleys I wouldn't use it (I would use OpenSCAD) As it's clearly not intended for generated stuff like that. I always tell people that every tool has it's own use. Never try to find a single thing that fits all.

http://daid.eu/~daid/VID_20140301_222022.3gp One of the "smaller" projects I'm working on. A 2440x1220mm (working area) CNC milling machine. We wired up the motors last Saturday, and I'm very happy.

It's actually 2 images and a simple text file. But then again, you refuse to look at it, so no point in telling you. And most people have been telling me they like the auto-slicing now, even if they complained at the start. For the printing window, I did not think there is a 1 size fits all, which is why I made the plugin system for it. I also made it as easy as possible to change it. I know my current options are not the best. But I also know that someone will come around and make improvements. (After all, that's how I got started. Instead of complaining, I did shit about it)

The printer dialog is editable with plugins now. So instead of bitching about it, you can fix it yourself. The printer window is a pain in the ass because everyone wants different things from it. If you want to make it look like repetier, go ahead, you can do that. But instead of even looking at it, and reading the fact that the printer dialogs are made from plugins (as mentioned on the changes) you are bitching like a true RepRapper. The "radar like" controls are from Pronterface. And the old interface did not work perfect before, it had tons of problems for a lot of uses. The new interface is not perfect, but can be customized. The old worked for you, but you are a RepRapper, you are special. And RepRappers have a tendency to see themselves as the center of the universe. News flash, you're a vocal minority. Cura has been build on ignoring and doing exactly the opposite of what RepRappers say. If you would be complaining that you want to do some things from printdialog plugins that you cannot do then I would listen. Instead you are just complaining that things have changed. Yes, I change things. I break things. I try new stuff sometimes. The GCode view improvements add some awesome debug features for myself. They are also a huge FPS boost. It also shows before the slicing is finished, allowing you to spot missing layer problems real quick. But instead you ignore all that and focus on your special case. The % loading of the layer view is loading the GCode. It's parsing the GCode, it can only do that from beginning till end. But once it has loaded it will generate the view from your currently viewing layer downwards, exactly as you are "suggesting". The GCode viewer is actually a difficult dance between a few different processes and data from GCode loading and send directly from the engine. The "quick" loading outer GCode is new, and that confused you. Tip, try something new for 2 weeks before complaining. Everyone was bitching about the auto-slicing. But that died in 2 weeks. Change takes time.

https://xkcd.com/1172/