Daid

My thoughts are: [*:3tordj21]So the MakerGear nozzles fit on the Ultimaker without issue? [*:3tordj21]How much more fine quality would I get from a 0.25mm nozzle compared to the stock (0.4mm?) nozzle? Because I noticed I want to print really small things and some details go missing then. [*:3tordj21]Changing the nozzle scares me. So a quick interchangeable heads sounds like a really good thing! Cannot wait to see the results.

I don't know the cause, but as a solution I suggest using PrintRun. Which is a much simpler interface and hasn't caused any grief for me like RepG did. The only "missing" feature is the ability to life tune the feedrate/flowrate.

The BD679 is located below the extruder fan connection. It's the black thing next to the step motor driver: http://www.reprap.org/mediawiki/images/ ... totype.JPG You could also test if the cable is bad by plugging the fan into the board directly, without using the 2meter cable. And finally you could check the fan by connecting the fan to the "always on" fan connection used to cool the motor drivers.

A netbook would work for sending GCode. But I wouldn't use RepG then. RepG is quite "heavy". Something like PrintRun or SendG is more suitable for weaker machines.

I'm not sure which version is the "Marlin V2" but it's most likely a bit older and doesn't have the software end stops. Which can save you a lot of trouble. The software end stops causes the machine not to go below X/Y0 and not above X/Y205. Which means the GCode has to give commands between X0 and X205. But skeinforge by default (I don't know Netfabb so you'll have to check) generates GCode with 0,0 as center. Which means the new Marlin things 75% of your model is outside of the machine and refuses to print it. The update to the start.gcode is simply changing the G92. My start GCode: M92 E926.5 (the number of extruder steps to take in 1mm of filament)G21 (metric values)G21G21 (all the extra G21 commands are comments - skeinforge eats lines without a gcode)G21G90 (absolute positioning)G21G28 X0 Y0 (move X/Y to min endstops)G28 Z0 (move Z to min endstops)G21G21 ( if your prints start too high, try changing the Z0.0 below )G21 ( to Z1.0 - the number after the Z is the actual, physical )G21 ( height of the nozzle in mm. This can take some messing around )G21 ( with to get just right... )G21G92 X0 Y0 Z0 E0 (reset software position to front/left/z=0.0)G21G1 Z15.0 F400 (move the platform down 15mm)G1 X0 Y0 F3500 (go to the middle of the platform)G92 E0 (zero the extruded length)G21G1 F75 E3 (extrude 15mm of feed stock)G1 F75 E1.5 (reverse feed stock by 1.5mm)G92 E0 (zero the extruded length again)G21M1 (Clean the nozzle then press YES to continue...)G21 This also changes that the begin extrusion is done at the corner, which I like more then in the center of the machine.

It depends on so many factors that it's hard to make a single design guide. For example, if you use support, a raft and a heated printer bed, then almost anything goes. I always try to print without support (done a few with support, but didn't really like the result), I've never used a raft, and I don't have a printed bed. And these are the design guides I use for myself: [*:3c6qbsbe]Try to keep overhang to about 45deg, but sometimes go up to 60deg [*:3c6qbsbe]The first layer can be problematic. Lots of corners make it worse, less corners is better. For example the bucket o' octopi on thingiverse is not a difficult print in the first layer, because it has only 8 real corners in the tentacle tips. But lettered text has lots of 90 deg corners on the first layer. Different printer settings might help here. So it's no a perfect guideline [*:3c6qbsbe]Largest face downwards. Always rotate your model so the largest face is sitting on the bed. This makes topping it over harder. [*:3c6qbsbe]Avoid multiple "towers" to avoid strings. If everything in a layer is interconnected you won't get strings at all. [*:3c6qbsbe]If you configure skeinforge to do "Loops" before "Perimiter" (it's a setting in the infill) then you can get away with about 1mm of 90deg overhang. The ultimaker is a very good machine, and it can print stuff that other machines fail at. So model away! And fix the issues later.

Het forum is eigenlijk engels, maar ik antwoord wel even in het nederlands. Welke variatie gebruik je? Er staan nogal wat mogelijkheden om de firmware te updaten. Het beste is de laatste optie: "Variant: Compile and Upload a Firmware from Source" dan heb je de laatste versie van Erik: https://github.com/ErikZalm/Marlin En die is erg goed. Verder is updaten vanuit RepG niet heel stabiel naar mijn ervaring. De wiki wijst niet naar de versie van Erik, hoe goed de bkubicek versie is weet ik niet precies. De laatste Marlin versies van Erik hebben wel wat features waar je rekening mee moet houden: [*:1o56obfz]Baudrate is 250000. Deze mogelijkheid zit niet standaard in RepG, maar ik raad dan ook PrintRun aan. Die bied een simpelere interface. [*:1o56obfz]"Software end stops" dit heeft invloed op de standaard manier waarop Skeinforge GCode maakt. Hiervoor moet je je start.gcode aanpassen en de "multiply" opties gebruiken (in multiply kun je het midden van je machine instellen op 100,100 in plaats van 0,0)

I don't own netfabb, but from what I understood from other posts is that the netfabb printing to the ultimaker just isn't stable yet. You're better off generating the GCode with Netfabb and print with RegG, Printrun or SendG.

Now that's a sweet ass paint job! I love it.

Indeed. The whole W/T ratio comes from the old "I have no control over the extrusion speed" extruders. If your extrusion speed is fixed, then a W/T setting makes more sense, because if you change your layer thickness then the line width will change at the same speed. But with step extruders like the ultimaker, a line width setting makes much more sense. And it's a very simple change in the code. Because the code already did: "lineWidth = widthOverThicknessRatio * layerThickness" so I just had to remove the multiply by layer thickness. It also explains the calculations shown by ddurant. The way RepG implemented the overrides won't work very well with the PyPy version. But I understand the need for it.

First, dump the "W/T ratio", like I did for Skeinforge_PyPy: viewtopic.php?f=8&t=153 That saves you 1 trouble. I took my 0.2mm profile, adjusted the layers to 0.1mm, and printed. Same temperature, same everything. And it came out great. I've never seen an object get worse from more cooling...

I don't know why it would complain about ascii stl files. OpenSCAD generates ascii STL files by default and I've sliced those... but... yes, SF41 is bugged... (*#%@#$@ myself) I wouldn't recommend copying over your settings. I changed the "width over thickness (ratio)" into a "line thickness" (so you no longer need to change the ratio when you change layer thickness). This might cause problems if you copy profiles over. Other then that the code is the same. 2 hours to 7 minutes... now that's a speedup! I haven't changed any real code things in SF45. I only start it with PyPy, modified the line width, and added the slowdown on the first 3 layers patch. PyPy is so much faster because it has a JustInTime compiler. It's quite technical, and a real challenge to get working reliably. So it's no wonder that normal Python doesn't go that route. Also, it gives a higher "startup" cost in time. But with the number crunching that skeinforge is doing you don't notice this. And I get this error with the Tie Advance: Which happens when an object is not fully manifold. Maybe you had the "meshtype" set to unproven in the other version. That has a chance to remove the error. But if the resulting GCode looks ok then there is no real issue.I also see a I'll have a look into those. But there are only a few errors in lots of layers, so I guess it will print fine.To compare the code to official SF45, make sure you have the settings the same. A raft could add a lot of gcode for example, and my SF has a lot of things disabled by default, where they are enabled on official SF. My export from SF45_pypy is also 5MB.

You must be dreaming then, because SF45 is the latest. (and in my version you get SF41 and SF45)

Ignore this, seems to be related to the version of Marlin I had. I updated to the ErikZalm/Marlin/Marlin_v1 branch. And now the feedrate seems to work better.

But to use it you don't need a linux install. Only to generate a new version you would need linux (or cygwin might work). The release, downloadable at: https://github.com/daid/Skeinforge_PyPy/downloads is ready to run. Extract it and run one of the batch files and you're off. No shell scripts, no other installs, just the zip and you're good to go.

I wanted to print something really small, with as much detail as possible. So I tuned down the temperature as much as possible, and set the feedrate to 10mm/sec. But if I print now with Marlin it doesn't go slow, it goes faster then GCode with 60mm/sec. Any idea what's causing this? (I'm using a slightly older version of Marlin)

Doesn't sound stupid.Just a few pieces of information: [*:29ocv47f]build.sh builds the package for Windows.[*:29ocv47f]build_patches.sh generates the patches/XX files from the target/SFXX skeinforge files (so it does the reverse of build.sh) [*:29ocv47f]Both scripts are run from linux. [*:29ocv47f]The package is for Windows. Yes I build a Windows package in linux (I'm kinda crazy). If you want to run for MAC you're on your own right now. The patches work, but you'll have to add python and pypy yourself.

Slice time in Python for Roy.stl with SF41: 4:47 Slice time in PyPy for Roy.stl with SF41: 1:55 Slice time in PyPy for Roy.stl with SF45: 1:20 At least twice at fast for this file. It will get better if you slice larger files. (and can get worse if you slice really small files, I've seen Python taking 15 seconds and PyPy 20 seconds) But best of all, I made a working package this time! (took extra time to verify it) https://github.com/daid/Skeinforge_PyPy/downloads It also contains printrun. So, you don't even need to download the RepG from Ultimaker with this package. If you have the USB driver installed, and the firmware updated (2 things I should add I guess)

This is more of a RepG problem then a Marlin problem really. Or more of problem with people just changing defaults. The communication baudrate has been changed a few times now. It used to be 57600, but Marlin already moved to 115200. But there are also 230400 versions, and I think the latest uses 250000. In your ReplicatorG install directory there is a /machines/ folder, in there there is an ultimaker.xml file. Open it in a text editor to change the baudrate (it says "57600" somewhere) Or give PrintRun a go: http://reprap.org/wiki/Printrun which allows you to set the baudrate when connecting. (I noticed I have to press "connect" and then "reset" for it to work)

http://groups.google.com/group/ultimake ... oM&lnk=ol& This might help you a bit. Maybe interresting information: I investigated the option of building a PrintrBot from scratch for a friend. Which would save about 150$ half of which is saved from printing the parts yourself. But added the complexity of ordering parts from all over the place. I don't have the ability to build my own hotend, which costs 75$, but I do not know how much that costs in raw materials. But the PrintrBot is a much simpler machine then the Ultimaker. In the end we decided it's not worth it and he will just buy a full kit. Saving a lot of hassle. If your time is worth something, then ordering a kit is most likely cheaper. But if you go around and build from scratch. The most important parts would be the timing belts, pullies and shafts. Getting those would get you started with building the XYZ frame. Seeing you can machine the hotend I guess you shouldn't worry about that to much. Just go step by step. Maybe you could even note down a BoM while you build, so we finally get a full good BoM.

Guess that's why they are looking for people to work in support roles. Most likely they are overwhelmed with orders and questions right now. With the holidays around the corner.

Ah, yes. Guess I know what's going wrong there. I forgot to push some changes to git, and those failed to make it in the alpha. I'm using "os.system" but it's much better to use "subprocess.call" which handles parameters better (solving the spaces and file not found problem) If you want to fix it, the problem is in SF41/skeinforce_application/skeinforge.py Replace: os.system(pypyExe + " '" + fileName + "'") with subprocess.call([pypyExe, fileName]) And add an "import subprocess" at the imports somewhere at the top. I've also adapted the changes to SF45 (so both SF41 and SF45 will be packaged in the next version). Added a patch to let the first layer slowdown work for the first 3 (configurable) layers, speeding up each layer. Adding some preliminary support for Linux&MacOS. Added "Tiny GCode" export option, which saves a bit more GCode space while sacrificing compability (still works fine on Ultimaker firmware) And I'm working on adding Printrun as GUI to print (and to run SF from). And adding a firmware update feature in Printrun. So you'll have a complete package. I've removed the ALPHA1 download, as it's clearly broken. I'll see if I can package a new one tomorrow (disadvantage of forgetting to push your changes into git)

FYI: Virtualbox does a pretty nice job with serial ports to a virtual machine. I use a real serial port from a WinXP VM in Linux every day at work.

Because it was printing ok before, I almost has to be mechanical or electrical. It could still be interference on the endstops. If you are confortable with trying you could disconnect both the X/Y endstops, and the lower Z endstop. Remove the X/Y homing code, and see if it still jumps layers. (You still want the top Z endstop to get the start height correct) I'm also seeing 1st or 2nd generation electronics. I'm not sure if there are any known problems with it. But I guess you are on the stock 5D firmware with RepG 25? And you're using 0.4mm layers? I've been printing at 0.2mm layers and that looks much better, the layers also stick to each other better then.

If it is a vibration problem then it might be solved by rotating the model 45deg. Because then the belts are always moving. But I don't think it's a vibration problem, because I'm not seeing waves. Maybe this picture helps in showing the effect: http://daid.eu/~daid/IMG_20111214_164139.jpeg It's the same red bunny, shot from the top (I wish I had a better camera). You can see the perimeter around the infill. It's printed from bottom to top with a small nudge in the middle. After the nudge it's 0.1mm to the right and no longer connects to the infill.