Daid

I haven't got around to print the radar dishes yet (had other stuff to print/do) But I did do another print with support, 50% material this time around. And this made the support strong enough to support higher layers, but weak enough to make it easy to remove. I found it so good, that I've made it the default setting for Cura.

The A4988 are preferred, but the A4983 are easier to get (and cheaper sometimes). The main difference between the A4983 and A4988 is that the A4983 will catch fire if you mistreat it, while the A4988 shuts off.

Awesome. Also, is the graphic window black or gray? Black could indicate that it does some OpenGL stuff, but gray means it doesn't draw anything.

From north america to NL takes about a week, so I would expect the same the other way around.

Not sure how good you are with changing a text file. But the file "preview3d.py" contains the line "OpenGL.ERROR_CHECKING = False" at the top, if you can change that to "OpenGL.ERROR_CHECKING = True" then the dos box might show errors about what's going wrong. (having error checking enabled makes the 3D window a lot slower I noticed)

Do you have DirectX and the correct video card drivers installed?

The Marlin experimental 3 from RepG is fine. But old, but fine. It's best to first get your machine working, and then upgrade to the latest and greatest software (which will improve your prints) The pots (as they are called) on the step drivers might not feel like they have end points, but they surely do. You are turning the right things. And the first one doesn't look set right on the photo. Simply put they are these in a very small form: http://en.wikipedia.org/wiki/Potentiometer Depending on the type they might not feel like they have an end point, but turning them beyond the end makes them lose contact. Turning them back or forward makes them make contact again. They are really simple devices ;-)

When they started the Ultimaker, the A4983 based Pololu was not available yet. (only the A4988 was available) In the amounts they are producing, it might be cheaper to produce yourself instead of buy. (not sure) The Pololu's don't have heatsinks. But they are not really needed. Cheapest I could find near the Netherlands are: http://www.watterott.com/en/Pololu-A498 ... er-Carrier and NL based shop almost doubles the price. (I was looking for these for another project) But if you got broken parts, contact UM support first. Most likely they'll replace the broken parts for free.

I just had to patch 2 lines of code, which I think that fixes it. Give the RC1 a spin to see if it fixed it: https://github.com/downloads/daid/Cura/Cura_RC1.exe

Indeed, contact support. But "Pololu A4983 Stepper Motor Driver Carrier" are drop-in replacements. Depending on where you live sourcing those yourself might be faster.

Cura doesn't contain a nice release package yet. The "Download as zip" button you most likely used contains the development version. So I'm surprised that you got it to start at all, must have required some thinkering. Did you see any exception trace after you loaded the 3D model? And which model did you load? (the development version contains a new STL loader, which is faster, but might contain a bug) The print button doesn't do anything if there is no GCode. EDIT: I created a release canidate for Cura. https://github.com/downloads/daid/Cura/Cura_RC1.exe

The filename you are using to slice contains "odd" characters, that's why it's throwing an error. The characters might not be odd too you, but it looks like the code currently crashes when slicing a filename not containing only ascii characters. I'll have it fixed for Cura 1.0

Maybe even more important, it makes slight variations in nozzle size unimportant. Still, IMHO, the current implementation is still not the best. Because if you change filament now, you need to slice again. The filament diameter could have been a firmware setting, and the E value could have been a volume. But it works, and works very well

Most likely the result of the "cool" settings. What happens is that because the layers are smaller, the printing speed is reduced to make sure the previous layer is cooled down. However, because of this is can go so slow that you get the melted problems. Reducing the temperature also helps. Cura 1.0 will have a setting to ensure a minimal extrusion speed, which solves this issue. (but isn't released yet)

Hihi, I'm no "pro". I had never seen a 3D printer 6 months ago. The "dos window" is what I call the console window ;-) you can capture the text by pressing the right mouse button on the title bar, select "mark" then select the whole window, press the right mouse button on it, and select "copy".

Yeah, the mac version is very buggy. It's also marked as problematic, and gives you a big warning about it. It's actually wxPython for MacOS which is behaving VERY buggy. I worked around a few of the problems. But it also seems the problems are different per user. (Depend on MacOS version?) The countdown has nothing to do with pronterface. That's the M109 countdown, pronterface just shows what the firmware tells him. M220 is just a command you can send. You can send it trough the pronterface command line window on the right, or add custom buttons yourself. "M220 S100" sets the speed to 100%, "M220 S200" sets the speed to 200%.

Well, the machine test, and any other tests which want to connect to the machine after that, try to use auto detection of the serial port. However, the Beta4 can bug up if you have sertain types of other devices or bluetooth devices connected to your computer. (new version will be smarter in this aspect) Try setting the proper serial port in the preferences (this removes the auto detect) Also, the error in the console window would be of interest to me, you can "pause" the window by pressing [ctrl]+[c] while the console window has focus. Print looks awesome btw =) Oh, and the firmware that comes with Cura is just Marlin RC1. I don't think it will improve much over your current Marlin version, unless you use the old marlin from RepG.

You could try swapping the motor driver boards to see if the problem moves with it. Also, check the current setting of the step driver: http://wiki.ultimaker.com/Electronics_b ... or_drivers it might be set too high causing the driver to overheat all the time.

Now that I have an SD card option, with LCD panel I'm looking into just powering the whole machine from the wall connection. Now, with 1.5.6 electronics, you have the ARD_PWR jumper which powers the Arduino from the 19V wall supply. But I have 1.5.4 electronics, so I would need to fix that myself. And I see two posibilities. I can connect the "Vin" pin to the 19V main supply, which is within the 6-20V supply range for the Arduino. However, Arduino does not recommend to power it above 12V. So I can also connect it to the 12V regulated power used for the fan. But then we have a regulator regulating a regulator, which sounds like a bad idea. Next, when making this VIN connection, we have the "fan powered by USB" problem. And general machine power by USB, which I never really liked. Which I think that can be solved by removing the MOSFET T1 from the Arduino Mega2560 Rev3. As anyone attempted anything like this?

The "manual" of skeinforge can be found at http://fabmetheus.crsndoo.com/wiki/index.php/Skeinforge Not that it will help you much. As every described settings requires you to actually know what the setting is used for before you understand the manual description. If you want Skeinforge, I suggest trying the Alpha4 of SkeinPyPy. Which still allows you to access all Skeinforge settings, but has sane defaults for the Ultimaker. Pronterface/PrintRun allows some for of realtime control, you can still control the temperature. And you can use M220 to control the speed. The PrintRun with SkeinPyPy-Beta4 has a realtime speed control feature. (but no extrusion control) Also, Marlin can work with ReplicatorG, if you configure Marlin right. The Marlin from SkeinPyPy doesn't work with the current version of ReplicatorG. Cura = SkeinPyPy. So I'm wondering what you find buggy about it? It "takes" some control away from you. As designed. But the "base needs more plastic" feature has been requested, and I've been thinking about it. But there are multiple ways that I could do it. For example, you could just make the first layer thicker with more plastic. But you could also remove the first layer completely, and make the 2nd layer double as thick (so you keep the right dimensions). I don't want to be SF and offer all options, so I'm thinking about what the best option would be, and how to configure it in the best way.

Interresting fix for the bowden tube. Looks like it could fix the plugging issue people are having. But, is the tip thermo isolated from the steel part in the bowden tube? Else heat from the brass tube will also heat up the steel part, causing filament to melt above it, causing a plug.

You can see bottom at https://github.com/daid/Cura/wiki But I also pre-heat myself, so I have the temperature setting at 0 in SkeinPyPy.

That case, in ABS, will need a heated build platform or some form of rafting, else it will warp too much to be useable at all. The printed version you see is most likely made with PLA. The estimated print time, for just the case, on my high quality profile, is 3 hours and 30 minutes. Reducing that to 20 minutes is unrealistic. You could go for thicker layers (my quality profile is 0.1mm, which is quite thin, at 0.2mm the case will be fine), a larger nozzle, 0.8mm diameter instead of 0.4mm diameter allows you to print a lot faster. Even so fast that the filament cannot melt quick enough. The real question is then, will you get the quality you need. But getting a machine for prototypes, and to experiment if you could do small production runs shouldn't be too painful in the costs I think. (The time saved for having a prototype to test with in 1 hour instead of 1 week is not to be forgotten)

I printed the top of the radar yesterday, as 2 parts. One tiny part for the column, and 1 top part. I removed some of the smaller details, as they are unprintable at this scale. Which are the parts around the base of the radar, and the top part of the large radar. I also think the arms attached on the radar dishes are not printable at this scale, they also are made up out of a lot of different 3D parts, which is great for animation/modeling, but bad for 3D printing I'll have to boolean them together, but a few parts contain faces that are the wrong way around (boolean operator hates that, it also hates duplicate and open faces) So it's going to be some work to fix them. I might just scale up the arms a bit so they are printable. I'll have to see what works. I'm also out of glue, so I could not glue the parts together yet.

It's the old, backup, failsafe, bad, blob generating firmware which is installed on your machine by default. It's depricated and replaced by Sprinter and Marlin.