Daid

It is the price. The lower layers are displayed from information straight from the slicer (they are also loaded before the slicer is finished), the upper 10 layers are displayed from parsing the GCode. There is a huge speed difference between these two display modes. The fill areas are yellow outlined in the lower layers, but that might be a bit harder to spot.

Screenshot? As this sounds like intended behaviour. Only the line infill for the top 10 layers is shown.

Piece of tape on the buzzer does wonders for the volume ;-)

I think I've found the problem for the firmware. Will put a fix out soon, until then use the previous firmware or your prints won't finish.

And RC4 is up: http://software.ultimaker.com/Cura_closed_beta/ I did not change anything on the MacOS version, so the crash that some people are having is most likely still in. I did address most of the other issues.

Someone else also reported problems. I'm looking into it. Some better logging would be useful, Cura on MacOS outputs better logs if you run it in a terminal. Which can be done by right clicking on the app, "show package contents", then goto contents/MacOS and run Cura from there. It should popup a black box that might contain a better error log. I cannot think of anything that I changed that causes UM2 prints to halt... Fixed for next update. Problem is that after a change the models most likely intersect and thus one-at-a-time printing refuses to do anything. Moving 1 object a bit should push everything apart. I've also triggered this when you close the machine settings window now.

http://software.ultimaker.com/Cura_closed_beta/ Grab the 14.02-RC, this no longer has the webcam feature in the print dialog.

14.02 has an updated layer view which will render the model much quicker for the basic outline to see if your model sliced correctly.

The 14.02-RCs no longer do this.

If you are using other slicers, then the "override" will only be on that file, not on all files. It doesn't change the settings in the machine.

1) The buffer is 16 moves. There is nothing I can properly do about this without causing major problems in the code. So, yes, that takes a while sometimes. 2) It does disable the stepper motor. So you could pull out and push in new filament (it can be done, but requires quite some force) But a firmware assisted filament change would be nice. I'll put it on the TODO list of features for the firmware.

With the UM2 board being so much better then the UM-Origonal board, it wouldn't be difficult to expect this somewhere sometime in the future. It reduces part count in our storage facility, and we'll have less failures (no more broken stepper drivers, no more broken electronics fans). It also adds a few extra features like software controlled current settings for the stepper drivers. And, a currently unused, safety circuit that can be used for extra protection. There is also room on it for an analog Z endstop. So more room for tinkering there. But, we're not there yet. It does require some changes in the kit here and there. As to fix this bug in firmware, you would have to add 1 or more extra steps in this state machine: https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/temperature.cpp#L1104

There are internal pull-ups in the AVR chip that can do this, but it requires quite a bit of patching and testing of the temperature code. So it would not require a board modification. But you can add a 100kOhm resistor on the board right now if you want. Shouldn't effect the temperature readout too much and would prevent this problem. (And the next version of the UM-Origonal will most likely have the UM2 electronics with the PT100 circuit. As this also gets rid of the electronics fan and solves a few other issues)

I intended it to work on 10.6, but, I have no way to verify or test it on 10.6 (Because Apple hates developers)

It's a problem that only happens with the thermocouple circuit in the UM-Origonal. (The UM2 has a PT100 circuit which does not have this problem) Another workaround would be to put a 20k resistor pullup on the board, but that might change your temperature readings.

The windows version is actually build on windows right now. (But I have build it on linux before, when I did not work at Ultimaker yet) The problem is more likely related to the inter-process communication changes I made.

It could do that actually. The Z has 640 steps per mm movement. Which is better then the 533+(1/3) that the UM Origonal has. But it has only a 0.16mm X and Y resolution, and a 5mm nozzle or something like that. It also uses a pellet extruder, no retraction, no oozing prevention. They are actually designing the paths to be printed, instead of using a slicer like Cura. It's quite a challenge to work at this scale. But it is slowly getting quite awesome http://3dprintcanalhouse.com/ is the website for it. Ultimaker is only assisting in the project.

Like I said, the RC3 was just for the GCode layer crash problems. The fix for the dual-extrusion is made, but will be in RC4. (As I already pushed the button to build RC3 when the dual extrusion bug was noticed) I've also improved my local build setup, I can now build the Windows, Mac and Linux releases in 3 clicks, and then they get automated uploaded and I just need to verify if they work and move them to the right location on the server. I still want to go to 1 click for all releases. But this already allows me to quickly supply you with new versions to test.

It's a bit of a hardware problem. As the ADC remains floating, and what happens differs from chip to chip in this case. Some chips keep exactly the same value, others drift up or down. Now, I do know a software fix for this hardware problem. What you could do is every X samples, disable the ADC, set the pint as input, and enable the internal pull-up resistor for a fraction of the time. This would pull the floating line towards 5V which will cause a MAXTEMP on the next read. I never got around to actually verify of the hardware can handle this and implement it in the firmware. (The temperature code is quite fragile) It is however, the last remaining bug in the temperature code. It can also only happen during printing, as if the wire is disconnected before printing, another failsafe will trigger. Also, quite often, if the wire gets disconnected, you do get a MIN or MAX temp error due to noise you generate during the disconnect.

Why settle for 3x if you can have 10x today? Me climbing off a print after fixing the endstops for homing om the Kamermaker. Just another day at the office? :-) 2000x2000x3000 build volume.

Never. They can pry the kit out of my cold dead hands. (FYI, I work at Ultimaker)

Disable support, note amount of material. Enable support, note new amount of material, do the math. ?

Only pused the RC3 to addres the rendering issue. Going to look at the other issues on monday. (Right now I'm standing on top of a 1meter height 3D print inside a large 3D printer. Hows that for a normal day at the office?)

While not even close, so far I liked DesignSpark mechanical the most. It's not feature-tree based. But it is free. But the only thing free with a feature tree that I know of that is is FreeCAD, which pretty much sucks. And then there is OpenSCAD, which sort of has a feature tree...

There is indeed a bug in the RC1 to RC3 versions that causes this with dual-extrusion (internally the head-offset of extruder 1 is not properly set to 0,0) Found the bug and fixed it. Good catch! Spiralize is always a bit tricky. As the GCode reader has trouble finding out the layer height. I did not check if the retraction settings are properly saved now. I did make some changes on saving settings, so can you check this? I also uploaded an RC3 which fixes the earlier mentioned problems with the layer view crashing and showing older gcode.