ddurant

That's not the one you want.. Try https://github.com/ErikZalm/Marlin .

Nope.. For that, you'd either need network hardware on the printer or you'd need it to support usb client so that it could act like a usb drive. Most add-ons that supply an SD card require you to physically move to your PC, copy the files on then move it back. I think I've got the only one that doesn't require that but it's a whole little computer ( http://www.ghielectronics.com/catalog/product/269 ) instead of additional bits on the existing one in the printer.. With a stock Ultimaker, you still need the host program - the stuff that opens up the usb/com port and talks to the printer..

Slow Down. F6600 is 110mm/s.. That's what the gcode is telling the firmware to do so if the machine isn't doing that, it's because the firmware decided not to. Daid's got it right:

Have you tried viewtopic.php?f=9&t=194 ? The latest version is on page 4..

Which marlin did you get?? For SF40+, make sure you set flow rate to the same value as the feed rate. If it refuses to go faster when you up the feed rate (and, of course, the flow rate, which you should make sure is the same as feed rate) the first thing to check would be the Cool module - SF will slow things down so that they take at least the min layer time. If you've got it set to more than 10 or so, try setting it to 10 and see if that lets it go faster. If that's not it, post a few lines from the middle of your gcode file.. Something that starts with a G1.. (edit: and the thing to look for is the F value, which is the feed rate in mm/minute. G1 lines with an E value are doing an extrusion, lines without aren't.. If the F value matches the feed rate you gave * 60, it's probably a firmware issue; if not, it's probably a slicer issue) I see no attachment!

Yep, I 2nd that the host PC, the bit that talks to the machine, doesn't need lots of power.. I've got a little stand-alone controller thing that reads from an SD card and sends gcode to the machine over USB. It's 72mhz with 16mb of RAM and it works just fine (except that I need to finish it!) though it's not running a whole OS..

On the top/left part of the picture where you can see the pullies on both axes, it looks like the belt isn't directly over the rod.. Is that right or does it just look like that because of the angle of the photo?

Is the Limit module in SF enabled? If so, try turning that off..

+1

Ok.. I get it now. A better way forward might be to move up to new firmware and new skeinforge. SF versions 40 and layer support "volumetric 5D" which enables it to figure out the correct flow for you - you just set feed rate and flow rate to the same value and SF will do the math so the extruder puts out just the right amount of plastic. Using that requires a newer firmware, though. That's not too hard to upgrade - if you need help, just ask!

I don't understand.. What was the problem where it was doing 1/2 height? How'd you fix that and, if it's not printing correctly, why do you think it's now fixed?

True. Skeinforge has something called "gcode small" which can greatly reduce the size of the output gcode file. Netfabb doesn't have this.. No promises but I'll see if I can write something that mimics what "gcode small" does so we can shrink down the netfabb output - hopefully it will get small enough that repg won't barf on it. Got Windows? It'll almost certainly be a windows program..

You should be careful mixing SF versions before and at/after 40.. Versions before 40 (and netfabb, for now) should have a "M92 E14" at the top of the gcode file. Versions >= SF40 should have "M92 E865.888" at the top of the file. The deal is that about a year ago, we figured out a better way for the slicer to tell the machine how much material should be extruded. This was great in that it made calibration a LOT easier (started at SF40) but it also was a bitofa incompatible change - gcode generated with SF39- wouldn't work on machines that expected the new way of doing things and gcode generated with SF40+ wouldn't work on machines expecting the old way.. The M92 was added as a way to tell the firmware which method the slicer used. If you're using sprinter/marlin and have the (correct) M92 setting at the top of your gcode files, you should be ok. If you don't have the M92 at the top of the file, the firmware is going to use whatever value was used last or whatever default value is in the source code - might work good, might go totally pear shaped... Unlikely..

Minor correction: s3g has been around since the MakerBot Cupcake. IIRC, it's sortofa binary protocol and was probably added to reduce the bandwidth requirements between the host PC and the bot.

Everybody seems to have a hard time keeping PLA in stock - just keep checking back.. They do have some 1lb unspooled rolls in stock at ultimachine. You can usually pick up spools at hardware stores - home depot and such - for free, if they have them. It's a real pain to spool filament yourself but with just 1lb, it shouldn't be too hard. You could even go without an actual spool, if you want.

At least the bot made an attempt to stay on topic. I don't know if I should be happy or terrified about that...

Check out www.ultimachine.com - they're quite popular and have a good reputation for selling quality stuff at competitive prices.

Anybody else not fond of the fact that the forums here don't let you edit posts? Any good reasons for not asking UM to change it? edit: woot! TY, UM!!

They're pretty helpful. Unlike me - I'm just crabby.. I agree that the not being able to edit posts thing is a drag.

3 spam posts every few days or so makes the whole ultimaker org look like a joke? Really?

You're welcome - glad you find it useful! The 10%, was it off by that much across all thread widths and feed rates or did you notice that some were closer than others? Did you just try one material or did you see it off with different spools? I haven't had much time to print lately.. :(

Hm.. Interesting idea.. Would it be better to have a value for the min possible layer height - 0.0010125mm or something - and have my code adjust to multiples of that or would it be better to have a few values for motor steps and screw pitch and such then figure out the value.. All those 3's lined up make me lean towards the later but I think the former is probably easier, once people come up with the right value for their machine.

Me too! Atlantic Ocean though, not exams, for me..

Er.. Thought I just posted a reply but don't see it.. If it shows up, hopefully this one will won't contradict it.. Crap. Can't believe I missed that.. Makes perfect sense now that you figured it out. Since the math is based on machines using E14, the G1 E values are all going to be considerably bigger than what you'd normally see when printing with sprinter/marlin and their E865 or E926 values.. Far more likely to trip over the default firmware limits and yet another reason why I think the current way of telling the FW how much you want to extrude is just wrong.. (that's a whole different story, though) How so? Just too high feed or width or something? It should, in theory, work for just about any value you feed it, within reason. If you can quantify how it's off and/or speculate on how to improve it, I'd be very interested in hearing about that.. I got it from you! It's what I use when I slice with SF now that I have the new bolt installed. Works great! (ty, btw) If you're seeing that in my program, please grab a newer version. The forums here don't let me edit the OP ( :( ) but you can find it here: viewtopic.php?f=9&t=194&start=30#p882

Have you tried printing or tried host software that's not repg? The repg control panel is a bit flakey at the best of times..