Daid

And if you are unsure, post some photos, this really helps in getting the best assistance from everyone here. As a picture usually explains better what is happening then words.

Location from where the pixel map is generate is always the corner of the outer box of the object, this causes the "pixels" to align differently on the model. Simply put, it's an aliasing problem.

What if you save the GCode from Cura (right mouse button on the print button) and print that from repetier? Could be 2 different issues. Could be that the GCode from Cura is too verbose (too many commands for the printer to keep up with) or that there is a problem with the USB connection code from Cura (as it's not seeing a whole lot of use in our office, as we print with SD)

Cura version?

Which version of Cura? USB or SD printing?

Can you post some photos of your hotend from different angles? It's not normal that it plugs like this. Maybe something is wrong somewhere (and we're quite good at spotting that these days)

You only need to replace the 7812, as that component will heat up to much (you need to replace it with a switching regulating one) everything else works fine on 24V

https://github.com/Ultimaker/CuraEngine/commit/e1a11d07414ce0d5687dc014e1ee9c8328f3f97a#diff-7888f314216c9766280f546d5058697fR625

Not anytime soon.

It is a bit of a mess right now. I know. Sorry. I'll be updating this code soon. As we'll get a few more variations of UM Original machines: - UM Original Kit - UM Original Kit + Self-build heated bed (which are more common then I expected) - UM Original Kit + Heated-bed-upgrade-kit - UM Original Kit with heated bed in a single kit (Not released, in the planning, no ETA, but will use the UM2 electronics board) So for the 4th machine I also need to supply a different firmware. So even more configuration options, which I'm not 100% happy about. But that 4th machine really needs to happen, I'm all for that machine.

Which OS are you running on? Cura should save a preferences.ini somewhere, depending on the OS.

13.04 was the last version that used the old and slow Skeinforge engine. This was a feature in this engine, which never really worked properly (as said, it just used the same outline twice, so it really only worked for mechanical stuff) With the introduction of my new CuraEngine (codename Steamengine) a lot of features went missing. Some are making it back right now. But with the new engine we got a 100x (on average) improvement in preparation speed, and much greater control on anything. As the skeinforge engine code was a huge mess. Note that I'm only combining multiple sparse infill layers into a single layer. This had little to no effect on the outside skin quality in my tests, while combining the top/bottom infill has a lot of effect on the overall quality, and actually didn't save a whole lot of time. Now, this sparse infill layerer combining feature is only prepared for the next code-name release. Which is called PinkUnicorn. Project PinkUnicorn is a whole UI overhaul. The UI code from Cura 14.07 is still based on the UI code of Cura 12.06, it has grown into a mess, and cannot support the advanced and complex features I want to build. I have a lot of plans for the PinkUnicorn, but they won't make it all in the first release. (Stuff like select-able support material, one object with sections of that use different settings)

People have been using the outer-shell speed with great success at the office. You only need to make sure that you do not get a too sudden speed change. 150mm/s normal printing to 20mm/s outer skin gives a sudden change in nozzle pressure which isn't good for the surface quality. So I think the best results are if you have the infill higher, the inner walls normal, and the outer walls a bit slower. You'll get the biggest pressure difference going from outer-walls to infill. But the infill has less effect on your overall quality.

My mistake. It is 14.07 not 14.06 (kinda lot of stuff going on in my head)

You mean... like this? https://github.com/Ultimaker/CuraEngine/commit/21494ffc6c334385d1ee8f5cd37d3418b44d3459

There is a whole bunch of techincal reasons for this. But the main thing boils down to "originally the developer that made the SD card support thought the longer filenames where impossible." I proved him wrong, but, starting files trough USB from the SD card still needs the short names, which is why Octoprint displays the short names.

We've bleed quite some more on the UM2 prototypes. Which where CNC cut, but did not have a chamfer. So they where razor sharp, and we got quite a few cuts from those.

Best I can do right now. Can provide better photos tomorrow.

Double blind testing time! https://drive.google.com/file/d/0B-eCyPuNafw6c2Y4UkFzY3RuV2loYlpvY1RSdlBiVWxyWXhr/edit?usp=sharing Here are 4 prints. If there is a quality difference, tell me which is 14.03 and which is 14.06. I'm not telling how many are printed on 14.03 and 14.06. (Also asking around at the office, will post the results of that tomorrow)

I'm running tests to see if I can re-produce this on a printer here right now. I'm doing multiple prints to prevent possible "one off" problems. And switching the firmware between prints, but not between every print. (to prevent 1,2,1,2,1,2 patterns) I've not reset any settings, to make sure both firmwares run at the same configuration. Our printer room is quite hot (30C minimal) due to the weather today. So this might effect the result in some way.

What Cura does, is kinda like this: So it takes the object. Looks from the top. However, it does this at a lower resolution. In the last picture, if there is enough purple, support is added there. Some smoothing is done on the final support. And the resolution at which this is done is actually higher then what I show here, but I hope it helps in understanding what is happening.

If I tell you I'm working on adding "setting overrides" on sequential printing. Would that make you happier? Note that some suggestions sound easy, until you try to figure out what kind of GUI makes sense for that.

There have been some changes, moving bridges from "per layer" to "per area". Properly detecting a bridge still fails on some cases. There is a github issue which has some ideas on how to improve it. The problem with the "add comment" or "change speed/flow" is that when I get to the part of exporting the GCode, I no longer have the information associated with if it's a bridge or not. All the infill lines (bridges/tops/bottoms/sparse) are thrown on a single pool to be printed.

The first year of Cura development was done for 70% on Linux, 30% on Windows. I only had minor bugs between those two OSes. I do not want to start a Mac vs Windows fight. And I rather not list all the strange problems I've encountered on the Mac version so far. (I still think the strangest is the random crashes when you had 2 different versions on your computer side-by-side. With the only fix, removing them both, and install only 1. I might have fixed that right now, as I haven't seen reports about this lately. But could be that the Mac users are no longer installing side-by-side versions) Anyhow, in part of my "todo" list on the Pink Unicorn development is totally redoing the Mac build from scratch. Updating all libraries to latest versions. This means dropping MacOS 10.6 support. But I hope this fixes some of these strange problems that I'm having.

The support is generated with a projected bitmap. Which causes these kinds of artifacts.