Daid

I hope that doesn't mean that you have to be drunk always to read/understand my lengthy FR/complaint/fixit posts :-) Understood it before that, but didn't have time to post before then. Using the grid-rectangular infill type does put the lines on top if each-other, and will be much stronger. So I recommend you use that then. Do you have pictures to support his "wall gap issue"? Because I'm not seeing anything like that.

You already had new electronics right? Did you use the same motor drivers or new ones? The motor driver could be overheating.

Oh, yes, it also depends on the model. And you need to have proper belt tension.

A license fee for free software?Note, I'll be releasing RC4 this weekend to address this issue and another issue which has been plaguing people with some types of ATI video cards. (Like my laptop)

Most likely it's the "first layer thickness" feature that you're not expecting. Cura is printing the first layer thicker then the other layers. This really helps in getting the first layer to stick properly to the tape, without sticking it so well to the tape that you cannot remove it. If your first layer is oozing all over the place, then your start height is a bit to low. You can manually turn the bed a bit down during printing of the first layer to see if it goes better. (just grab the bottom of the Z screw, and turn it, don't worry, you will not damage the machine)

you rather discuss with people not using the machine?

Should be easy to add. I'm in a train and drunk right now, so if you want to make sure I remember, it's best to make an issue on github about it.

Any chance you're using none-ascii values in filenames/paths? Rusian or characters with accents for example.

You can adjust the infill overlap in the expert settings, but you will always have some gaps.

Don't try to fix things in SF. You will go crazy. Anyhow, I'm posting from a train while I'm drunk, so I hope I make sense. But I think I understand your infill problem now Joergen. It suddenly hit me. What's happening is that all sparse infill lines are really bridges, because they are cross hatched. A simple solution would be to use twice as much material on the sparse infill lines, but after spending 1:30 hours in the train this morning investigating if it was possible to adjust SF to do this, I gave up.

1. Oops, I missed that one. I've changed it for the next release. 2. That's odd, it should end up at the center... it does so for me. 3. They caused a lot of problems with dual extrusion. So I disabled them. The project planner can be used to print multiple objects in a different way, but that's not a 100% replacement. And, it can work with standard repraps, as long as you have firmware that accepts GCode with E values.

Both the Marlin firmware and PrintRun do not support the "()" style comments, which is causing your problems. Not sure if you can disable those in netfabb.

SF does not under-extrude infill. The GCode preview of Cura clearly shows that it wants to put down enough material. See this result: http://daid.eu/~daid/IMG_20120429_152851.jpg The red parts (the white parts are no good, because that extruder was blocking up). It's almost a perfect infill, just a slight under-extrusion, which is expected, as my "100mm" test comes out as 97mm, and material was lost due to oozing. As for your "watch repair" compare, SF was designed for the crude early RepRap machines. The fact that it can do what we are doing with it is a wonder on itself. We've adjusted a sledge hammer for car repair, not bad really. "Dynamic line width" goes against every design aspect of SF. It would be quicker and better to make a new slicer then. Note, question is a variation of the "thin walls are not filled properly" question. Yes, it's not right, but changing it is not a simple thing. I still think printing less then 0.4mm lines with a 0.4mm nozzle is a bad idea, because it reduces your X/Y resolution.

The lead bolt, I guess you mean the drive nut? http://wiki.ultimaker.com/Ultimaker_rev ... t_assembly It should be held firmly together by the wooden parts. On my machine it took a bit of force to get everything to fit. The Z drive screw is shorter then the machine, so it's normal that you have a gap there. The axes keep the bed in X/Y place, not the screw. Make sure your Z drive screw is all the way in the coupling, there should be no gap between the start of the thread and the coupling with the motor. Finally, check you electronics, maybe the Z jumpers are wrong, there should be 2 connected and 2 disconnected jumper on the Z motor controller, see: http://wiki.ultimaker.com/images/El1.5.4-PCB.jpg

Parts smaller then the line size are lost. It's impossible to make something 0.36mm thick with 0.4mm lines (0.4mm lines are default) What you could try, is to set the "wall thickness" to 0.6mm, and the nozzle size to 0.3mm instead of the default 0.4. This tricks Cura in putting down 0.3mm lines. However, this is quite hard for a 0.4mm nozzle and the results might not be pretty. As for the cooling problem, in the expert settings there is a setting called "minimal feed rate", set this a bit faster. What is happening is not that the printer stops to wait for cooling, but it slows down. However, it slows down so much that it goes to a crawl. The minimal feedrate is intended to protect against this, however the default of 5mm/s might not be fast enough in your case. You can also adjust the minimal layer time so it spends less time printing each layer and waiting for cooldown. I've added a fix for the error message in the dev version. It happens if you select a layer which doesn't have any GCode in it. I wouldn't recommend trying to hack the GCode generator (Skeinforge), as you will lose your sanity. Final note, printing things like this really pushes the printer to it's limits.

You're welcome. I'll be releasing RC4 soon to fix this. As it's an very annoying bug.

It looked a lot worse before cleanup: http://daid.eu/~daid/IMG_20120514_091428.jpg It doesn't require a new printer. However, I would not attempt it on a machine that you also need for your boss. I could not have done it without the help of Harma from Ultimaker and Jelle from Protospace. Who supplied the parts and helped assemble it. Even then, it's a lot of tweaking before you get the heads on the same level, and a bit of luck. It also requires a new fan shroud design, which isn't made yet. I'm using the stock design, but it's so far away from the nozzles that you don't get proper cooling on small or tall parts. I do think the "double clip" upgrade is very good: http://daid.eu/~daid/IMG_20120514_235612.small.jpg http://daid.eu/~daid/IMG_20120514_235653.small.jpg Which really seem to help in keeping the bowden tube in place. It does making installation a bit harder, but that should be worth it. Paul suggested this upgrade, so credits go to him.

I don't think you could have bent the rods. Is there a chance that it was bent to begin with but you only notice now?

Color mixing is quite difficult. But there was something about it on the RepRap blogs a week ago or so. Photo of my fixed dual head. What did I change? We replaced the top 8A plate with a 8B plate, with 2 clips on it. Then drilled new holes for the thermocouple board. With 2 thermocouple boards there is a little bit of a space problem, so I replaced the top strain relieve with the 2nd thermocouple board. Finally we cut a corner out of the printer head on the left back, and rotated the top/bottom 90 deg, so we could access the lower clips while the printer heads where on the left. Now the fan holder fits on the right side, giving full printer space access again. The good news: Adding a 2nd clip seems to solve the bowden popping problem so far. And I can print dual color again.

I'm using PyOpenGL 3.0.1 with the wxPython glCanvas. As Cura is packaged with everything needed, so versions of stuff used is the same for everyone. As far as I know, this problem seems to be limited to 64bit Win7 machines with ATI 3D cards. My laptop has WinVista and an ATI card, which is having a slightly different issue, where the 3D preview stops updating until you resize the window.

Ah. Understood. I see the need for multi extruder temperature monitoring. However, touching the M104 command almost guarantees that PrintRun or ReplicatorG break. Not sure what the best course of action would be...

I'm using a modified version of the Arduino 1.0 libraries, with a newer GCC version. It's easier to compile the Marlin sources in Arduino 0.23, which is what ErikZalm is still using. Indeed, the only way to read both temperatures is by switching with T0 and T1. But I have an UltiController which shows both temperatures. What lines do you need changed? And for what reason? Because we try to get as much functionality in the mainline as possible.

The cura firmware works in RepG if you enable the "experimental machine" option, and then select "Experimental sprinter/marlin" Note, if Cura didn't work for you, you might ran into this bug: viewtopic.php?f=8&t=855 there is a workaround for it.

I've found the bug. It happens if you never touched the start/end GCode. Quick fix is: -Use "expert->normal mode" -Goto the "start/end gcode" tab -Click the "end.gcode" on the left Done. That's all. This causes the default start/end code to be stored and used properly.

I didn't print it, but I found it a cool looking model for a screenshot ;-) It did however, pave over the center. Not sure why...