cyclone

Dave, do you have a Github or some repository for the latest of this tool?

I use LogMeIn. The free version is good enough for doing standard operations on an Ultimaker. I have a webcam setup with the cam software up and the print spooler software running as well. Frame rate is sluggish but I can see if a print is running fine or has failed. I can log in through my phone or another pc and hit stop at any time. Quite nice. There are probably other remote login softwares that can do the same thing.

You can dynamically rotate by grabbing the green box corners. You can rotate in only one plane by first choosing a view that shows a view square to the plane you want to rotate in, like Top, or Front.

Any word on an update to this ... er update?

I agree with Daid, I've done many overnight prints, with no problems. Over heating will only happen if the temp sensor goes out and I believe the firmware has code in it to shut down if temp ever reads "0." Since it is unlikely that you are printing in a snow bank or freezer the assumption would be that the temp sensor became disconnected. The only thing I'd watch for is if the printer successfully turns off the heater at the end of a print. Which if the code your are generating works once it should generally work. So that said, I have had a runaway heater on my makerbot, (repG UI problem where I typed in 220 for a temp and it kept the "0" that was in the box so it came out 2200) But so the hot end metal part melted out of the insulator and was hanging from the heater and temp sensor wires. Fun times. If it makes you feel better keep a fire extinguisher nearby, pref one for electrical situations. I also agree with the Printrun SendG comment. RepG and Netfabb tend to crap out on long prints, and RepG wont even load really long gcode files.

I think it should be a multiple of min layer height. But that makes it machine specific. Perhaps make it a preset value that can be changed?

In my experience the PLA (or ABS) will stick while hot, and as soon as the temp gets lower than 40 or 50C the PLA will let go. So if you do the oven thing it will only be good for short prints as the glass will cool down then nothing will stick to it anymore. -c

You can use a putty knife, but I like a painter's tool. It generally has a stronger, sharper blade. Also called a 6-in-1 tool: http://www.google.com/search?q=painter's+tool Both are available from most hardware places, Lowes, home depot, Ace. -b

I'm interested in hooking up a thermistor as well I'm just a little vague on the exact "how." According to what I've seen you can hook a thermistor up to the temp2 or temp3 on the board but I don't know which of the three pin to hook the two wires. Either: Signal and Ground or Signal and 5V. I'd hate to blow something up. There also needs to be a change in the firmware to read the heated bed temp. -b

You can reduce the heat by turning down the pots on the x and y stepper drivers. I can't seem to locate the page on the wiki but turning them counter clockwise turns down the voltage, clockwise turns up the voltage. You want them as low as works without skipping steps. -b

The couple of commercial machines I have, use gcode with feedrates in units/min American machines use inches per minute. Not sure why. Probably as Dave says It was always done that way in the past. -b

I've noticed the latest Pronterface's new-ish time estimation algo barfs on Netfabb code. It seems the offending line is: G1 E0.0000 Is anyone aware of how to fix this in Netfabb as it seems to be a useless possibly malformed G1. (It would be nice if Printrun did a little error checking of its input.) I'm sure Printrun expects an XYZ if there is anything. Also It's part of the generated code and not something I can take out of the "Start" section of Machine. i -b

Does this do the calculations based on the extruder hole diameter and is that hardwired to .4mm or can it be adjusted like say changing the min thread thickenss? With people reporting more clogged nozzles I'm thinking I may try to cut some parts to allow for a makergear hot end, and in that case, would probably like to set it up with two heads of differing sizes. Probably have to just switch the wiring back and forth to use one or the other until more support for multiple heads comes in, but I'd love for both sizes to work in Netfabb. -b

Honestly it would probably be easier to try to change the thermistor out for a thermocouple. Do you have a thermocouple with those electronics? Also you might get more info from the Makerbot google group and MB forum. -b

From "Download's for daid's Skeinforge_PyPy - Github" I'm not the one dreaming. So settings are incompatible between pypy_SF45 and regular SF45. That's a mild annoyance but only in that it makes comparing them a little harder. Yeah there is like one hole. (reg SF45 complains about that hole as well) The "euclidean is 0" errors are the ones unique to pypy SF45. I got 6 during Fill. I need to go ever the settings to figure out why there was such a discrepency in the gcode filesizes. They sliced the same # of layers. but the pypy version was 1/4 the size of the regular and yet the (highly in accurate) time estimate from printrun said the much large gcode file would complete 2 hours sooner. Obviously different. I suppose the proof is in the print. I'll print them both and see what's what. But seriously good work. SF wasn't useful as I'm printing big stuff and taking hours to slice is just crazy. This let's me go back to some of the nice features SF has that Netfabb hasn't thought about adding. (*Ahem* Cool,Comb,Fill %,Fill Pattern...) -b

So there is still some quirk with sf41, it complains about an ASCII STL. I thought SF always supported ASCII STLs am I wrong? Anyway I don't really use 41 so I then looked at sf45. The speed difference is shocking to say the least. I copied the default settings from pypySF into a clean .skeinforge folder trying to get the same output from both but still something came out wrong. Anyway: I used the Tie Advanced front from thingiverse. SF45 - 2 hours 55 minutes 1 second pypy SF45 - 7 minutes 20 seconds For some reason, the pypy code is only 5 meg while the standard sf45 is 19 meg. Also pypysf45 barfed a few times that stand SF45 didn't. A few "this should never happen" Looking at the gcode in printrun they look similar, the first layer is different and printrun slows down to a crawl trying to view the standard SF45 code. So something very different apparently. Interestingly the time estimate is about 2 hours longer on the pypy gcode. Which I think is weird. I can post the errors but it would probably be best if you ran it yourself. Great work though, very promising. I'm interested is this speedup just from pypy or have you made some low level changes to how SF runs? If it is mostly pypy then do the Python coders know their stuff is crappy slow? -b

No, at one point the batch of fans they got had the connectors wired backwards. So I first started the UM a few times with the fan wired backwards. It didn't spin and probably didn't hurt it as there is likely a diode to prevent such backwards wiring mishaps. But upon flipping the wires and it makes this noise doesn't fill me with warm fuzzies, nor does it convince me that I did *not* accidentally fry the fan motor. -b

Now *that* is a cool story...bro. -b

Mine does the same thing. (Possibly) It make a lot of vibration when I first start up, but after the bearing or whatever heats up from spinning for 4 or 5 minutes it quiets down. I need to get a new one. This is exactly the same sound a processor fan makes before it dies... And it's done this since day one. Might be related to the wires being backwards for the voltage when I got it, but I doubt it. It's just a cheap blower fan. -b

SF51? I've been asleep at the wheel again... Weren't we just on 44? -b

That is a big Ultimaker. I don't even have a laser that could cut that. Looks like room for two extruders? Are you increasing the size of the x-y rods? I see a couple of holes there hard to tell which ones you are going to use. What's the printable area? Have you worked it out? Looks like 800x800x1000 ish (Unless my software scaled the DXF wrong) I'd suggest one of those extruders having a 1mm head on it. -b

I'm glad to see this get made, I tried to get PyPy working on my system (for use with SF) and had no luck. I made the couple of changes but then it complained about the syntax of my ASCII STL, so I made a binary one and it complains that there is an unknown character. I know the Bin one works on the regular SF so I'll just wait for the updated version. Thanks for doing this, it might get be back using SF again. :-) -b

Spoke too soon. It also doesn't like directory names with spaces in them. Went to skein a file and it complained about where I had the SF41_pypy sitting. I had to move the sf41_pypy folder to the root, and then it didn't like the space in the filename were the STL file was sitting. Moved the STL to the SF41_PYPY folder and it complained that : Traceback (most recent call last): File "app_main.py", line 51, in run_toplevel IOError: [Errno 22] Invalid argument: "'C:/SF41_pypy/Tie_Advanced_X1_Back.STL'" And I've no idea why it doesn't like that. -b

The batch file uses forward slashes "/" instead of the Microsoft sanctified backslash "\" SF41.BAT exits with a "python: can't open file '/python.exe': [Errno 2] No such file or directory" Since (on my XP system) it sees that first python/python.exe as: python /python.exe python (installed in my path) complains that it can't find the file /python.exe. change to \ and it seems to work fine. -b

I've noticed on my UM that the screws holding the X and Y motors slip and the belt(s) loosen. Just enough to make it lose steps. Might put a finger on the belts coming from the motors just to make sure they are still tight. -b