Daid

In the beginning a bit, yes. Some moister could be in there, and some materials need to settle. Bit it shouldn't smoke for long. Also, I had a bit of smoke at 250C, but at 230C I have nothing, even almost no smell with PLA.

Photos would really help in this case? Maybe you have the wooden parts the wrong way around?

I still need to fix a few issues and add a few features. I hope to get a beta out pretty soon. EDIT: https://github.com/daid/SkeinPyPy/downloads Beta uploaded there. It's far from a finished product, but it should be usable.

3D printing is almost the same as CNC routing. You need a so called "slicer" to go from an 3d model to GCode. But that's supplied as free software (or payed NetFabb) If Solidworks can export as STL then you are ready to go. If it cannot export as STL... I cannot imagine it cannot export as STL.

Another in the "because it's always been that way" list, I suspect.. :( Because... it works, is my guess. The code is complex enough without fixed point math. In general, floating point is good enough for what we do.

Servos with the same strength as step motors cost an arm and a leg. Also, a server doesn't "count" the number of steps, a server has a feedback of it's position, normally a pot meter. Which also causes it to have a limited move range in most cases. Only commonly available servos that I know of are those used in model airplanes/cars. And those are not suitable at all.

You don't need to change anything but the layer height. That's the idea why I changed the ratio into an absolute. You can change the amount of solid layers, at 0.2mm layers I didn't have problems with 3 solid layers, at 0.1mm layers I needed a few more. But indeed, that's the only change you need to make. 0.3mm layers are not really recommended IMHO. I had lots of problems with 0.3mm layers not sticking to eachother. While 0.2mm layers could be printed almost as fast and created a much better result. Your dimension settings might be slightly off if the lines are not width enough, or the M92 Exxx value is wrong for your machine. This requires some calibration. I hope to provide a wizard for later in the SkeinPyPy development to guide you trough the steps needed to calibrate the M92 E value.

Not sure why they would want sprinter, which isn't... as good as Marlin. But no problem. It does require a lot to setup, you would need a server that allows you to run compilers from within php. Which is not something most hosting providers will like I'm running it on my own machine. It's quite a difficult setup (compiled my own avr compiler, made some adjustments in Arduino headers), so if you can tell me which IRC server and channel I'll just jump in there and help out. The actual php script is only 1000 lines of code or so. And it's not pretty but it works.

I wouldn't do that if I where you. The relative E value will cause floating point errors to build up, causing errors in the extrusion amount, and thus creating a less pretty print. Not sure I buy that.. With relative extrusion values, each thread basically becomes an atomic operation. You might get a little FP weirdness between what the gcode asks for and what the firmware actually sees but I don't see any reason it's build up over the course of the whole file. Or am I (again) missing something? In floating point values: 1.5 + 1.5 is not always 3. But sometimes 2.99999999999999999 Also, depending on how the firmware is implemented, it could see "E5.3", and translate that to 74.2 steps (with 14 steps per E unit), and does rounded down, 74 steps. So you could get rounding errors with each move. This doesn't have to be true. But the floating point rounding errors are guaranteed.

"Perimeter width" has been renamed to "edge width". So that explains why you don't see the setting. It's in the Carve plugin. But I'm working on a whole new User Interface. "Edge width" is actually gone here. There is "wall thickness" now, this combined with the nozzle size (0.4mm) it calculates the amount of lines to lay down and how thick those need to be. Which will look a bit like this. Which will make it even more usable Each option has a popup with explanation what the option does once you have the cursor on it. It also contains validation which will warn you if you enter something "stupid". As you see it also allows you to slice multiple models at the same time.

I just noticed I might sounded a bit harsh, was not the intention. It is confusing, but ErikZalm is maintaining a stable up to date version in his v1 branch (which is the default branch you see)

I wouldn't do that if I where you. The relative E value will cause floating point errors to build up, causing errors in the extrusion amount, and thus creating a less pretty print.You can do this in 2 steps with Skeinforge (and thus SkeinPyPy Alpha4), if you use the "layers from" and "layers to" options in the "carve" plugin. First slice layer 0 to Y with 100% infill, then slice layer Y to max with 30% infill, and put those 2 gcode files together. You would have to remove the start code of the 2nd GCode file, and reset the E value (G92 E0) at the start of the 2nd GCode file. You could also print it as two prints, not sure how strong it will be, but I printed this: In 2 steps, without removing the black platform from the printer. I adjusted the start code to start 7mm higher. (after homing, move up 7mm, reset the Z value with G92 Z0)

The Marlin Experimentals from the Ultimaker RepG are a bit old already. Marlin moved quite fast, using the "Build-Me-Marlin" tool gives a newer version which fixes a few issues. You would need to set some configuration options right, like the baudrate and disabling software endstops.

Wrong! where did you find that link? Because you should point to the ErikZalm version, that's the latest and most stable version.https://github.com/ErikZalm/Marlin

http://printrbot.com/2012/02/22/norcal- ... ntrbot-hq/ They might be selling PrintrBots, but that's an Ultimaker in the center of the room! :mrgreen:

Now it does It does generate a shitload of warnings in the Sanguino sources.

The printing from NetFabb is broken right now. But the slicer (Model->GCode) is a piece of wonder (as far as I understand, I don't have NetFabb). And even printing from RepG is not the best way, printing from PrintRun is even more stable. RepG itself doesn't do any slicing, it uses Skeinforge to do that. So you got a bunch of different steps (modeling -> slicing -> printing) and all those steps have different software options. With advantages and disadvantages.

The Mac OSx version is not that user friendly yet, as you'll need to install Python and PySerial yourself. As I don't have a Mac, and don't have any experience with it, it's kinda hard for me to tell you what to do. But bbum got it working. He made a slight different packed version: https://github.com/bbum/SkeinPyPy/downloads with a startup script.

In my oppinion? Don't use RepG at all. There are quite a few software options, RepG being one of them. But you should be using the RepG from http://software.ultimaker.com/ on the ultimaker. See: http://wiki.ultimaker.com/Software_setup_guide which offers 3 options (one of those made by me, so I'm not the right person telling what to use )

Note, if the instructions are incomplete, you can update them and help the next people

Did you order filament with your kit? This can make all the difference. Also, order numbers are most likely sorted by of placing the order. But actually shipping might be sorted by payment confirmation date.

The "AMD Athlon XP2800" is a "Socket A-based CPU" so it's lacking SSE2 instructions. It's also a 10 year old CPU. It is possible to get PyPy running on a machine with SSE2, but they don't provide precompiled packages for it. And it requires a very heavy machine to compile it, and some special tricks. If you just want to use the presets, the Alpha4 falls back to normal python if it cannot find pypy. So if you rename the pypy folder and slice then you won't get the speed benefit, but it will still work. EDIT: https://bugs.pypy.org/issue1068 There will be a better error message, instead of a crash for the next PyPy version. Atleast your effort will help other users!

If the head doesn't move during print, and you upgraded to Marlin, it's most likely a problem caused by the "software endstops". I'm not sure if NetFabb uses 100,100 or 0,0 as center of the machine, but if it uses 0,0 then this option needs to be disabled.

They are shipping as fast as they can. They have plans to keep stock so they can ship when payment is received, but building up stock takes time. And if orders are coming in faster and faster, it's almost impossible to build up stock against that. (Ordering 100s of extra parts is not something you can pay for as a small startup) If you follow the google groups and the forum, you'll notice that there have been multiple people with electronics problems. This is most likely the cause of the current delays. And when your electronics supplier fucks up, especially PCB manufacturing, then you have lots of problems. Because the Ultimaker team is running small batches, they are not important for the manufacturer. And PCB plants run tight schedules, so getting an extra job in there is tough. We've had delays of 3 months where I work, just because the manufacturer skipped 1 step in production. And our products are a hell lot more expensive then the Ultimaker PCB. So you getting mad over a few weeks is just silly.

6 years. SSE2 was introduced in 2001 with the Pentium 4. CPUs without SSE2 are: [*:2wz8cbn9]AMD CPUs prior to Athlon 64, including all Socket A-based CPUs [*:2wz8cbn9]Intel CPUs prior to Pentium 4 [*:2wz8cbn9]VIA C3 From that list, only the C3 is the only thing I still have (in a box somewhere). So it might not be an SSE2 problem. I'm also running winXP myself. So don't think that's causing it. Maybe it's an out of memory problem? I got 4GB of ram in my machine. And skeinforge can use up a lot of memory.