Daid

Official answer is no. (While it's pretty safe to eat from, we cannot guarantee or officially sell it as food-safe. The germ comment is true, as well as that you cannot properly dish-wash it. It also absorbs moister so that doesn't help with the germs)

Maybe it is filling it? did you scroll down to those layers? By default Cura only shows infill for the top viewing layers.

Cura rounds things to the nearest micron. So 0.3999999 would become 0.4 again. The nozzle-size effects the line-widths, printing lines smaller then the nozzle size can be done, but doesn't always give great results.

Configure the proper head-size in the machine settings.

The above effect is because spiralize is a hack. It generates the layers as normal and then modifies every point on the path so the Z is increased. This means that you can have an offset in X/Y on every layer as it does not use the "proper" XY position at the end of the layer.

1) It's best to check if the motor cables are not "pinched" between the electronics cover and the casing of the UM2. The motor cables are the red/green/black/blue wires. Some early machines had the assembly problem where these cables where improper installed and made a tiny short between the cover and the cables, causing random resets. 2) Partially legacy, partially Arduino compatibility.

There is a workaround, as you can load the settings back from gcode (so slicing with quickprint profile, and then loading them back in normal mode will give you the quickprint settings) Quickprint is on the chopping block anyhow with PinkUnicorn.

http://i.imgur.com/dv4fnY5.png Top projection view is there already ;-) I like most other things here, lots of things I didn't think about yet.

Could potentially be a firewall issue? Cura uses local TCP sockets to communicate between the engine and the frontend.

Currently Cura uses the last ending position on the previous layer as start position for the next layer. It would actually only be a few lines of code to randomize this (for a quick solution). A proper solution would actually look at inner corners and put the Z-Scar there. (Maybe even randomizing if it finds different proper corners)

So, I've come to the point where I want to add the toolpath view into the Cura-PinkUnicorn edition. Which is one of the major things missing right now. As I was never really happy with any of the GCode view implementations I made so far, I was wondering. What are you guys looking for in a GCode viewer? Why do you look at it? What's the most important part? What sucks on the current Cura layer-view mode?

Cura calls them insets. And prints them from the inner inset to the outer inset. The outer inset is the outside of the 3D model. The outer skin so to say. The outer-skin of the circle-hole is the inner most circle. As that's the part you visually see.

No it doesn't, it prints the inner hole the other way around.

If it would reset it wouldn't really be lifetime right ;-)

I think they use a First-In-First-Out method. With the distinction that technical questions are answered by different people. The main reason the ticket response time is down is that they expanded a lot. More then doubled in capacity. And those people worked their asses off to get the backlog of tickets solved. Spending weekends or after-office hours to solve more tickets. They deserve more credits then we can give them.

We're working on it. Bit of background information. The delivery of the timing-belts for the UM1 where severely delayed. Problems like this suck, and I've heard things about making sure we have 2 suppliers for each part in the future. It was delayed pretty much up to the point where we considered putting the UM2 belts and pulleys into it. (which would result in a different X/Y steps-per-mm) ("Heard in the hallway" information, no claims can be made on this information. I normally deal with things you cannot touch)

The machine knows which firmware is on there, it's available from the maintenance menu. (We generally ship with the latest available firmware) Cura 14.06 shipped with firmware version 14.06.1. Cura 14.06.1 shipped with firmware version 14.06.2. (Yes, confusing as hell, sorry for that, the only thing changed between Cura 14.06 and 14.06.1 is the UM2 firmware) 14.06.1 firmware adds the life-time-statistics 14.06.2 firmware adds a fix from simon (illuminarti) for improving the start of a print A "sudden reset" can be because of 2 things. 1) A "brownout" (voltage drop). Some early machines had this problem where the motor cables where actually damaged and shorted out. This also caused random resets. 2) A watchdog-timeout. If the firmware crashes it auto-resets, however, before this happens it should "halt" for a few seconds. I cannot think up a way how the latest changes could cause this...

I have a new GUI that I'm working on, which works with higher poly models. But 1GB is really pushing it. Biggest test model I have has 2949120 triangles. And is 150MB. This one loads in the new GUI while it fails in the current release. However, this new GUI doesn't to GCode preview yet. So I do not know yet if it can handle a resulting GCode from a file this big. (The engine shouldn't have a huge problem with 10milion polygons, as long as it doesn't run out of memory. But it might take a while to slice the initial step) Also, if you can "convert" the OBJ to binary-STL by external means, that would really help in loading the file. The OBJ file format take a lot longer to load then binary STL.

You're overcomplicateing things. There are 4 "main" steps. 1) Slice3D model into layers (no idea how to thread this, but it's very fast. It's actually the bit without progress information) 2) For each layer calculate the insets 3) For each layer calculate the top/bottom skins and sparse infill areas 4) Export each layer (calculating material amounts and so on, on the fly) Step 2,3,4 are reporting progress information, and the process bar in Cura divides evenly on the 3 steps. The nice thing is, for each layer in step 2 and 3, you only need information from the previous step. So a layer in step 3 only needs inset information. And a layer in step 2 only needs the sliced information from step 1. What does this mean for multi-threading? You can turn layers into work-packages per step for step 2 and 3. For step 4 this can be done, but it's more complex, as you need to make sure you export the data in the proper order, and right now some information (final head position on the layer, final extruder and extrusion amount) is needed from the previous layer. People have already done tests with making step 2&3 multi-threaded using OpenMP.

I've heard people doing 18 hour slices with Skeinforge. According to my own tests, Cura is faster then any OpenSource slicer out there right now. But that shouldn't stop us from trying to make it faster.

We tested that, no matter the finish, PLA stuck to it like crazy.

Single threaded.

Don't worry, someone is pretty much a fan of having multiple versions side-by-side. I just did add an option to the installer to uninstall all other versions (disabled by default) https://github.com/daid/Cura/commit/a443ba22c8c44fa4733d77f2bcbb0baeb7ea9346

Actually, we recently discovered that can be caused by ESD. Which is kinda hard to prevent. We're looking into adding a transparent protection plate to prevent this in the future.

AHHHHH, ok. That's confusing, as all other values are in mm/s. Going to patch it back, and add more comments to remind myself of this.