Quote
dc42
[...]
Also, will the M6 screws self-tap into it as they did for the extrusions supplied by RRP, or do you think I should order it tapped?

Quote
ezwul
Some brilliant work so far guys, but we are not quite there yet! 15-Foot Tall Delta 3D Printer Unveiled by SeeMeCNC

Quote
isonoob
I use Simplify3D... haven't looked back at slic3r since. Speed of slicing is incredible, and no hangups like slic3r has.

Quote
static65
Next issue: slicing large models. Slic3r lets out a little whimper and rolls over dead when I go above a certain size. Looking at various forums it seems like it's run out of memory even though I have 16GB, I guess it's just not grabbing enough of it. Does anybody know of any other decent slicers?

Simplify3D looks the dog's proverbials, but such niceness is never free. Has anyone taken the plunge at $140 yet? If it really is all it claims to be I may be tempted with a favourable exchange rate :D

Skeinforge gets a lot of mentions but I haven't found a version later than 2012 so not sure if development has died on that one.

Currently about to try printing some things sliced with the free version of KISSlicer, but even that hasn't been updated since May 2013. It's not as nice to work with as Slic3r and lacks the level of customisation for speed and other bits and pieces, so I shall see how it comes out.

EDIT: KISSlicer seemed to generate sensible g-code but it didn't heat the hot end up. I copied my start g-code from slic3r so it's got the T1 command. It waited for the bed to warm up as normal but then went straight to trying to print. I switched it off at the power supply.

Comparing the KISSlicer gcode to Slic3r gcode reveals that the latter inserts this straight after my custom gcode, which might be forcing a wait for the head temp?
M109 S190 ; wait for temperature to be reached
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion

And the custom gcode itself, present in both outputs:
G21 ; set units to millimeters
M107
M104 S190 ; set temperature
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M140 S60; Set bed temperature
G1 Z5 F200 ; lift nozzle
G1 X2 Y100 F2000; Go to wait for warm position
M116; Wait for all temperatures
G10 P0 S190 R0 ; Set extruder temperature
T1; Select extruder
M116; Wait for all temperatures

EDIT2: I think I've probably located the issue, I didn't update my start gcode for the new tool numbering, should be G10 P1 S190 R0 not P0. Didn't notice the problem before in Slic3r as it put that M109 S190 in for me. Bit late now, will verify tomorrow after work :)

Quote
dc42
You have it the right way round; but in the homing files supplied by RRP, it's the X axis that is homed twice (once fast and once slow) not the Y axis.

Quote
static65
I thought the Y-axis was the axis on which the bed moves and the X-axis is the one on which the nozzle moves? I'll feel a right fool if it's the other way around.

Quote
static65
Ah but as long as the micro-switch is set correctly would this be a problem? It would home the same way as the Y-axis: fast until triggering the micro-switch, then slow until triggering it again. Would the initial fast homing be too inaccurate and end up in a bed collision? I wouldn't have thought this would be problem given that there is a few mm play before the x-carriage hits the x-arm.

Quote
dc42
I think you mean the X-axis, not the Y-axis. Yes, you could change the homez.g and homeall.g files to do that. But it doesn't give you anything that you can't do with a z-probe - and if you use my firmware fork, it does the slow/fast homing automatically when you use a z-probe.

Quote
static65
Ah but as long as the microswitch is set correctly would this be a problem? It would home the same way as the Y-axis: fast until triggering the microswitch, then slow until triggering it again. Would the initial fast homing be too inaccurate and end up in a bed collision? I wouldn't have thought this would be problem given that there is a few mm play before the x-carriage hits the x-arm.