Daid

I have no experience with ReplicatorG (only the early versions). So I don't know if those popups are a problem or not. But I found RepG so hard to work with that I created Cura.

The default sequence of loops->perimeter->infill works best for overhang cases, where the perimeter can be "glued" against the loops, before shrinkage of the infill makes the loops a bit smaller. The first layer is printed at a different sequence because it doesn't have overhang. And then printing the perimeter first gives the best results, as the perimeter can cool down then before the rest it attached to it, giving less warping. You can change this sequence because for some types of prints a different sequence is better. If you want watertight cups/vases for example, then you want to start with the infill. But in general you almost never need to touch these settings. As for the bridge settings, the next version will no longer have a bridge material amount setting, as it did not work properly, and affects the whole layer with the bridge in it.

It is in development (actually, I commited it to the Cura printing interface only yesterday) However, the version of printrun that comes with Cura still has this. The older SkeinPyPy versions did not come with a printing interface inside of Cura itself, so PrintRun was always used.

I think an heated bed would make it easier to push off parts, not harder. You can use M190 to cool down and wait for the heated bed. Some kind of wiper would be pretty cool, and I think easier and more reliable then the ABP from Makerbot. However, it would make it hard to shove off thin parts.

Try the latest firmware then (Cura is a bit older), there have been fixes, but I cannot remember any fix that effects X/Y position. But it never hurts to try.

Yep, the RC4 firmware is Ulticontroller compatible. But you can always installer a newer firmware make with the builder: http://daid.eu/~daid/marlin_build/ if you think there is a firmware problem. The only other layer shift possibility that I know off is that you extrude too much plastic in the first layers, which causes the plastic to curl up and stop the head from moving. But I've only seen this happen if the start Z was too low.

Interesting test to push off the printed object. I always assumed it was possible with some types of objects. I currently cannot test it as my tape sticks better to the object then the platform. You could change the Z lift with a small piece of relative code: G1 F4200; set rapid speed for travel move G91 ;Relative mode G0 Z10 ;go up G90 ;Absolute mode G0 X136.9 Y150 ; go to x-y spot, x is chosen to have the head push with the bolt on which the fan is attached G0 Z4 ;move down G1 Y0 F3000 ; push print off with movement speed 3000 mm/min This way you don't need to know the height of your print.

Nope, it always shows all the slices below the current slice. It does show lower slicer darker, so you should be able to see the difference between the currently viewing slice and the rest.

The infill is shown in 3 colors, so show the pieces that are printed in 1 go. Not sure how useful it is

You are exactly right. Cura's project planner will print 1 object completely, and then move to the next. Due to the size of the printer head this will take up a bit more room on the printer bed. All other tools (Slic3r, Skeinforge multiply) print 1 layer of all the objects at a time. Which indeed can cause a failure to have lots of half finished objects. Here is an example of Cura: http://daid.eu/~daid/IMG_20120424 ... .small.jpg each object was printed separately there, shown by the skirt around each object.

Not likely.

This is usually due to belts with too little tension. You could lower the travel speed, but that would just hide the problem. Check if you small and long belts are thight enough, and that all your pulleys are tight enough on the rods.

The part you load first will be printed with the primary extruder (the brown part), the green part will be printed with the secondary extruder. The positioning in RC4 is bugged: https://github.com/daid/Cura/issues/143 You should slice and check if the result is good, because slicing still gives the correct GCode even if the preview of the 3D model is wrong. Note that dual head printing is experimental in Cura, and that you have to setup to heat both extruders yourself, as Cura does not do that yet.

I think the general consensus from the Ultimaker community is that Cura solves most if not all software issues: https://github.com/daid/Cura/wiki But you won't get support from Ultimaker on Cura.

Cura's project planner can do this, which will print 1 object at a time. The next release will include a feature to print all the objects at once, in the same way the multiply feature works. In Cura RC2 or lower you can also use the multiply feature from Skeinforge, however this was removed in RC3 due to a number of reasons.

Yes, the print speed can be limited by the minimal layer time. And if you put the minimal layer time very low, then it will also print at print speed. The travel speed is the speed at which the printer head moves if it's not extruding. So moving from one place to another. (A bridge is something else. Which is a part that is printed in mid air and connected on 2 sides)

Not sure where you got your machine from, but that's not an official bolt. There are 3 known bolts, and your photo does not match any of them. I (and most people with me here) don't care where you got your machine from. But the Chinese ebay copies are much lower in quality then the official machines. Any chance you got your machine off e-bay? These are 3 types of official bolts: V1 V2 V3 I suggest you order an V3 bolt from the shop: https://shop.ultimaker.com/en/parts-and ... ion-3.html Also, your step motors might be underpowered in the case of an e-bay machine.

There are multiple ideas for new electronics. On the google groups someone is working on a designed based on ARM. I've looked into changing the current RAMPS design into something that would work with the BeagleBone. Which should be quite simple, most parts accept the 3.3V that the BeagleBone uses as IO. Only the temperature sensor requires some extra electronics. You could even design a plugin board which replaces the Arduino and accepts the BeagleBone. This is interesting because it adds Ethernet capabilities. However, I think it's the software department that will be the most work, the current firmware is highly engineered to fit on Arduinos. Moving to ARM would require a rewrite. Moving to Linux based ARM (like the BeagleBone) will give even more challenges.

The Z rods extend all the way from the bottom of the machine to the top. So you need to put them in all the way. Else you'll never be able to put part 3B in place ;-) The pictures are pretty clear on that. Just make sure you don't forget to put the platform in. And if you sand down the holes, do so very lightly, because if you have play in these rods it will effect quality of your prints in the end.

Backlash problems, most likely because of lose small belts. The setting that does this is called "Jitter", but you cannot access it from Cura.

Note that you are entering an experimental area then: viewtopic.php?f=6&t=773&start=30 With the latest retraction settings from Florian things are improving. But oozing remains a bit of a problem.

Looking at your photo I say your GCode is fine. As it seems to print the first few layers quite fine. At which temperature are you printing? Is it easy to push the filament trough by hand one the printer is hot? Is your big gear firmly fixed to the bolt? (this was my first, and biggest problem, the gear was turning, but the bolt was not, causing very little plastic to be pushed into the printer) Which software/firmware are you using? (to generate the GCode, and to print that GCode) If you have an plug, then eventually it will plug up completely, without you being able to get any filament trough. But seeing that there is still some PLA comming out of the nozzle, I would say that you don't have a plug.

This is a bug with none ascii characters in filenames. It's been fixed for the next version. Usually it's Russian characters, or characters with accents that cause this. It doesn't have to be in the filename, can also be in the path. (It's actually a bug in the windows python version, and it only happens for windows, so it took me a bit of time to track down)

If we had common mistakes then the boards would be flooded. But just read carefully and you'll do fine. The X min/max switched act wrong in Marlin, so you need to swap those around. (the real question is, is the firmware wrong or the labels?) Other then that, take a good look on where to put the cable guides, taking your frame apart because you put those in wrong is no fun from my experience. And make sure the big wheel is tightly screwed on the hobbed bolt.

The part also will be stronger, but the infill is also better to hold up the "roof" so to say. I found that with thin layers you better have a bit more infill.