Daid

Between 14.01 and 14.03 the communication with the backend changed from a hacked up pipes solution to sockets. This potentially means that some extreme firewalls might block Cura from functioning correctly. There is also an output.txt in the Cura installation directory, this file might provide some more insights.

I said, contact me. Not that it's impossible, we just need to make some tweaks to make that a reality. The reason why there is no 64bit windows version is because I have my whole windows toolchain setup as 32bit. And all the python packages I use are pre-compiled for 32bit. I could compile the engine for 64bit. But that won't help as it's the GUI that crashes before the engine. And, now we do not have confusion of people downloading the 64bit version on a 32bit install.

If this is about the engine, then, read up about pipes and stdout/stderr. If this is about something else. Then I do not fully understand what you mean.

Infill is calculated with the front left corner as "center" point. (as that is actually 0,0) So the grid is rotated around that point. If you want the grid lines to match up with exactly the center of the model, you most likely have to select a proper infill% or tweak the machine size a bit. But I cannot tell you exactly the values you will need. As it's a lot of "emergent behaviour" which results in the infill.

Cura uses a single thread to do all it's math. And is CPU/Cache bound. What does this mean? Simple. The cheaper the CPU, the slower Cura is in preparing the model. In general, newer generations CPU, more GHz, and more Cache help in getting it faster. More cores won't do anything. With 1 exception, 2 cores help in making the GUI more responsive, as the GUI runs in a different thread. Note that speed is relative. This laptop seems to have about the same CPU specs as my old WinVista laptop. It's not that slow to prepare, but for big models it can take a while. Still, it's faster then the 10+ minutes we where waiting 1.5 year ago :smile:

Try removing the flto flag from the compiler and linker to see if that helps. It might be an obscure compiler bug (normally the assembler should never throw an error)

If it's good for all reprap-users, then do ErikZalm/Marlin. The Ultimaker/Marlin is a fork for just the configuration changes. Note, "in-house" we just found out that there is a problem with dual-extrusion if you have retraction disabled. Haven't looked into it yet.

Just measured. In the CAD model it's 4.9mm of maximum travel. And I'm measuring about the same on a real limit switch. So I rather put this move-back value at 7mm to be on the safe side.

stk500v2 talks to the bootloader, not the firmware itself.

UM2 uses the same chip. The UM2 hardware started by just putting all the UM1 hardware on a single board. And then replacing the bits that where not needed or could function better (like the temperature measurements)

Limits are created by the amount of memory you have (or Cura can use). Which depends on a lot of factors (including OS, Linux 64bit and MacOS can use more memory). And the object you have causes different memory use. And there is a "hard" limit of about 2km of object size. After this the engine will most likely crash or not function as expected. If you make a printer with this beyond scale, contact me ;-)

(Just got back from vacation in NYC) Ok. First of, this is great. It's great that we've found a cause of something that is really plaguing users. It's also easy to fix. So that's perfect. I have a few other minor firmware changes lined up. So this fits in there perfectly, and was planning to do a maintenance release this week. So that all fits fine in the release schedule. It's also a safe patch, it won't break anything. The only thing I will do extra is measure the actual maximum travel distance of the switch (in CAD and real life). Just to check if 5mm is enough now (Would kinda suck if 5mm would be enough for 95% of the printers) and make sure there is a nice safety margin on it. Getting on that right now. (Moving up till the switch is unpressed is a bit of a difficult thing to do in the code right now)

Pull requests would be great. I'm quick to commit and push, so you can see what I'm working on. And I'm swarmed with work already, so any assist would be great :-)

Barnacules! We love your videos at Ultimaker. Happy to have you around.

Holy shit, that actually worked. (Not that I needed to modify the step files, but it's good to have them all unlocked)

Why is the bridge bad that way? (As for the other bridge comments. Bridges work better at 0.2 layers in my experience. So the proper improvement would be to print bridges at a different layer height. Can most certainly be done, just printing bridges at different layer heights. But does needs some work)

It's normal behaviour that the printer resets if you open the serial port. (This is actually behaviour copied from Arduino) You might get around the problem in linux with: stty clocal -hubcl /dev/ttyACM0 There are stability problems with the USB on some computers. Which is why we opted not to officially support USB printing. However, all the code is in place for it to work, and you can actually do it from Cura if you switch to "RepRap" gcode flavor. If you are more into writing your own code, this is the USB communication implementation of Cura: https://github.com/daid/Cura/blob/SteamEngine/Cura/util/machineCom.py (As you need to do flow-control and stuff, doing straight "cat" to the serial port is not recommended)

100% infill causes that there is no difference between sparse and full infill, which in turn causes problems with detecting bridges.

This is most likely what is screwing with the bridging behavior.

How advanced do you want the renders to be? (you could just take screenshots) The renders on youmagine are made with Povray and some scripting magic.

Prototype 2 of the TITAN did 1.8 print about 1.5 year ago. And then the Z stage jammed and it never worked again. Only just picked it up after FabCon due to lots of people wanted to see it finished. This photo is of Prototype 3, which is 22x22x22 cm instead of the older 20x20x20cm prototype. But I'm using better components now. And I already updated the drawings to 20x20x22 for prototype 4. The prototype 3 has 30% of the external volume of the Makerbot-Mini, but 25% more print volume. The TITAN is by NO means any commercial effort. It's a hobby project. I have no plans to sell it, or to make a kit out of it. As for SLA. I'm not that scared of the resin costs, more scared of the toxicity of the resins. Look up pro SLA printers and you'll see gloves. Always.

Not must, may. Everyone is welcome, with or without Ultimaker. Hell, bring your Makerbot if you want.

God damnit, someone stole my printer name. https://github.com/daid/TITAN Well, my name is all caps. To highlight the awesomeness of the TITAN. Also: http://daid.eu/~daid/IMG_20140523_140107.small.jpg

Yes, that was actually the probing of the SD card which was causing issues. (Mostly on Mac, but also on Windows with certain virus scanners)

Only the text is mashed up. All the other features moved to the Pronterface UI. (select it from the preferences) For the messed up text, I made a quick fix in the latest RC at: http://software.ultimaker.com/Cura_closed_beta/