Daid

No, I decided that my implementation was crappy (hacked together) the idea still works, but I need to do it better.

The TEMP_?_PIN are analog numbering. Not digital pin numbers. (It's one of the many screw-ups in Arduino IMHO)

Tried leveling on the heater-block. Same problem, even with a nicely pointy screw. (In the end, the printer was a huge mess with all the modifications I did)

With a Doodle3D WiFi box you can print direct trough WiFi. Other then that, no other solutions have been implemented, yet.

Like I said in the other topic. I attempted this early in the UM2 development. Didn't work very consistently, due to residue on both the head and the bed you will not always get contact, causing the head to push into the bed way too far.

I tried this in early UM2 development. But the connection between the nozzle and the alu bed is not that great. I automated it, and sometimes it won't make a connection at all and press down on the bed hard.

No. I have no idea how long it takes to get numbers in stock and everything ready for full production. (It's currently in beta-testing)

UM PSU is 19 for the UM Origonal. UM2 PSU is 24V. And the HeatedBedUpgradeKit for the Origonal will come with a 24V PSU.

I see goggles. Goggles with lasers are good. Make sure you have them, use them. (Which is why I'm not a fan of lasers in open machines)

Cool stuff I hope my code wasn't to horrible to work with

Updated the windows version: http://software.ultimaker.com/Cura_closed_beta/ Will do the linux/mac version as soon as I get to the office.

Ah, blarp, forgot to push the firmware. BRB

For those with this problem and not wanting to venture into firmware building themselves. I've uploaded an RC5 with this firmware fix: http://software.ultimaker.com/Cura_closed_beta/ If nothing is wrong I will make this an official release tomorrow (I really need to do this maintenance release, also to fix the quality bug)

I think that machine uses a different process.

And cheap filament uses dyes that breaks down in UV light. (I know Ultimaker and Faberdashery filament do not have this problem. And I would expect most other quality stuff also does not have this problem)

I do not think any of the 3th party nozzles currently fit on the UM2. You want an UM-Origonal for that. Still, for things "tooth" sized, I wouldn't try FDM. The Form1 or B9 would much better suit your goal. We have a B9 at the office, but we're currently not that impressed by it. But we haven't played with it a lot. However, for tiny prints, it does a lot better then an Ultimaker. (I've done lots of tiny prints on my personal Ultimaker. I kinda know what it can do and do not in that area)

Could also be that your machine has backlash, be sure to check that first, with backlash in the machine you'll never going to get accurate results. (I find a 0.5mm difference a lot for 5mm holes, hard to think that that just shrinkage)

It's a bit hard to describe in words what I do there. Some images could do wonders there. But the basic steps are: - Rotate the polygons so the infill direction is on the X axis. - Calculate how many infill rows there will be (min/max X position) - For each line in the polygons, calculate the crossings with the X rows, and store that crossing. - Now that we have line crossings for each row, you can do "even-odd" to get the infill lines (after sorting the crossings on Y position) - Finally rotate the result back by the inverse rotation you used in step 1

python.exe

Indeed, 72 is proper for the UM2. But saying that 72 is the UM2 is wrong. So the comment in the configuration.h (// 72 = Ultiboard v2.0) is correct.

Your new proposed algorithm doesn't change the build volume. What normally should happen is that the bed is moved towards the endstop at high speed. Due to this high speed, it cannot stop fast enough when hitting the endstop and thus moves a bit passed it. This is why there is the HOME_RETRACT_MM. It moves back this distance, and then moves into the endstop again at lower speed. Getting the exact position where the endstop is triggered. The problem that we are facing is that on some machines, the bed is so well assembled and calibrated, that it drops down beyond the end-switch point. And then it currently only travels up 3mm, which is not always enough. If it travels up 7mm (as I just configured for the new firmware) and then move slowly into the endstop, we'll find the proper switch point again, consistently. No build volume is lost, as the build volume is measured from the switching point.

Best place to report them in a way that garantees that I see them is: https://github.com/Ultimaker/Ultimaker2Marlin/issues

It's using a local TCP socket to communicate between the front and backend. This socket is local only and cannot access or be accessed from the internet. (There are more ways to communicate between front and backend. But this was the most cross platform compatible way) The older 14.01 release used temp-files, which caused slowdowns on slow harddisks, as well as a lot of harddrive trashing.

How many polygons is your model?

Interesting. Never thought of it that way. I'll let this one sink in for a while.