Skeinforge contributions

This is a thread about contributing to skeinforge.

The best way is to help the develop the skeinforge manual at:
[www.bitsfrombytes.com]

To get permission to edit the manual, unfold wrote:
> You can create an account on the top right of the wiki pages: log in / create account

Another way to help is to program. Because skeinforge is complicated, most of it is hard to develop for. The part that has the least impact on the rest of skeinforge is the import plugins. For inspiration, developers could look at the import code in cam.py:
[web.media.mit.edu]

You could also help Erik de Bruijn with his 3D-to-5D-Gcode php GPL'd script:
[objects.reprap.org]

Reprappers use his script with skeinforge and over time features will be ported from his script to skeinforge.

Also, if anyone with a fabricator is willing to test new skeinforge settings, please post your willingness in this thread.

Cheers,
Enrique

Edited 2 time(s). Last edit at 09/30/2009 04:55PM by Enrique.

Enrique Wrote:
-------------------------------------------------------
> This is a thread about contributing to
> skeinforge.
>
> The best way is to help the develop the skeinforge
> manual at:
> [www.bitsfrombytes.com]
> Skeinforge
>
> I do not know how to get permission to edit that
> wiki, if someone knows how please post in this
> thread.

You can create an account on the top right of the wiki pages: log in / create account

>
> Another way to help is to program. Because
> skeinforge is complicated, most of it is hard to
> develop for. The part that has the least impact
> on the rest of skeinforge is the import plugins.
> For inspiration, developers could look at the
> import code in cam.py:
> [web.media.mit.edu]
>
> Also, if anyone with a fabricator is willing to
> test new skeinforge settings, please post your
> willingness in this thread.

I am!

>
> Cheers,
> Enrique

Hey Enrique, I've been printing with PLA quite a bit, and am refining my Skeinforge settings. Is there a place where we could dump copies of our Skeinforge preferences, with some simple annotations? (Edit - ah, I see there's a separate thread for that!)

So far PLA has been working quite well, but it does tend to ooze a lot more than ABS; activating Oozebane and Comb help, but also cause small sections of prints to overheat and deform. A fan helps, but I'm still working on it.

And yes, I'm quite willing to test out new settings!

Wade

Edited 2 time(s). Last edit at 09/14/2009 04:51PM by Wade.

Unfold & Wade,

Thanks for the offer to test experimental settings. I should have a couple of new features to test within a couple of months.

Cheers,
E

I'd also be happy to test for you! A backlash system and native 4D/5D firmware compatibility would also be very nice. This anti-backlash greatly improves my print-quality and reliability (prevents congestions in the extruder because it extrudes in an area which is already filled).

For other missing features that I've added myself, you can look here:
[objects.reprap.org]
Actually, right now it does a bit more than is documented. I've made some acceleration code for non-accelerating firmware. It divides up segments of rapid travels into portions (multiple G-code lines) with different speeds so that it accelerates. Right now, about 70% of my objects have mistakes because an axis misses a few steps somewhere. I've replaced stepper drivers, tried all sorts of feedrates (an no, slower is not always better). With acceleration I hope to remove this problem and also create thinner/less strings from head travels.

Right now I'm e-mailing gcode to people that can't run my PHP conversion program properly. So, I guess the features are appreciated.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Hi Erik,

Thanks for writing your 3D-to-5D script and for offering to test new settings. I've added a link to your script from the first post. Over time I'll port features from your script to skeinforge.

Cheers,
Enrique

To all who master the python

Because of the shrinking of the extrudate tension builds up inside objects, but also in the raft. I sometimes get warped objects because the raft snaps loose. I mitigated this to the extent that now it is more rare, but I did that by depositing a fatter raft than before at a higher temperature. But with less material, I think that it should be possible to prevent the raft from detaching.

Right now the foundation layer of the raft is laid down in straight lines.

When it shrinks, the tension builds up along the entire length of the raft.


The build platform constrains it imposing a shear force on the filament (I'm not mechanical engineer, so I could be getting this wrong). The only way to shrink further is to detach at the end, by curling upward until where the stickiness of the platform is bigger than the tension.

We could allow it to stretch a bit, by laying out the filament (as in the picture below, on the right). This could prevent detachment, save material and speed up extrusion of the raft. I have produced 420 grams of rafts already, although I'm saving it for when I can recycle it myself. It's probably over 10% of all material that I consumed (I printed a lot of things on duct tape, without a raft). Other than the waste issue, it would prevent us from having to buy as much filament.



Of course in many cases the raft could have a smaller footprint than it has now.


Now that the amount of people printing increases the ratio of structural vs. sacrificial material should be improved. I hope that someone would like to write a replacement raft system. I'm not sure how difficult it is, but I'm sure that it can be done if you know python (unlike myself, aargh!...)

P.s. Enrique, thanks for adding a note about my script. I'm working on a hosted version for people that don't like installing the PHP cli.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

If you do that the raft will have less strength to resist the layer above contracting.

If your raft isn't stuck well enough to resist its own warping forces, how is it going to keep the object flat?

Sometimes I get the loops at the end lifting if my head is too high but that happens as the raft is laid, rather than when it cools.

A pause at the end of each raft line to give a blob might be a good idea. I saw a video of a machine (IIRC a makerbot) doing that (due to segment pausing I think) and it occured to me that it might be beneficial.

---

[www.hydraraptor.blogspot.com]

My rafts only snap loose when a few layers of the object adds to the force.

nophead> If you do that the raft will have less strength to resist the layer above contracting.

Do you mean that the zigzag pattern reduces the strength? I'm only talking about the foundation layer now. Or the fact that the raft surface is a rectangle regardless of the object's shape?

Another idea for you guys to shoot at:

The raft outset is currently a proportion of the extrusion width. But a very long object would have a lot of warping force along its length, and much less along its width. So actually the outset of the raft could better be a function of the amount of force. As a rule of thumb, this could be the proportional to the dimensions of the object along the respective axes. Small footprint objects hardly need a raft at all. Wide footprints mostly need a wide raft, etc.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

ErikDeBruijn Wrote:
-------------------------------------------------------

Quote

My rafts only snap loose when a few layers of the object adds to the force.

By changing my first layer temperature I can vary between the raft being impossible to remove from the base (which is then destroyed) or not sticking at all. I set it to a compromise in between and it never breaks loose on a build. Large objects break from the raft, rather than the raft from the bed.

The second and third layers are hot so the raft is strongly welded to itself.

The temperature of the first layer of the object depends how strongly it sticks to the raft. Again it is a compromise between being able to remove the raft easily with a blunt penknife and the object breaking off during the build.

I think without a heated chamber and / or bed there is a limit to how big the object can be before it breaks free, unless you consider the base material sacrificial. With ABS it is difficult to make anything more than about 100mm if it more than 5mm high.

Also I find some objects like corner brackets and the X-carriage rip themselves apart if you do manage to hold them down.

Quote

Do you mean that the zigzag pattern reduces the strength? I'm only talking about the foundation layer now. Or the fact that the raft surface is a
rectangle regardless of the object's shape?

The former. The bottom layer of my raft is thicker than the others, so provides a lot of the strength along one axis.

Quote

Another idea for you guys to shoot at:

The raft outset is currently a proportion of the extrusion width. But a very long object would have a lot of warping force along its length, and much less along its width. So actually the outset of the raft could better be a function of the amount of force. As a rule of thumb, this could be the proportional to the dimensions of the object along the respective axes. Small footprint objects hardly need a raft at all. Wide footprints mostly need a wide raft, etc.

Yes I have done that in the past, it works well. I applied this linear function to the length and the width:

def overlap(L):
    return L + 20 + 10.0 * (L - 20) / 80

The coefficients should be plastic dependent as HDPE needs bigger rafts.

---

[www.hydraraptor.blogspot.com]

Interesting discussion, I like the idea of the raft following more the outline of the object. The raft is indeed a huge waste of material, any savings there would help. I have printed around small 60 parts without raft, with the necesarry tuning and good condition of the bed you get nice results. I like the smooth finish of raftless prints. Erik, what do you mean with 'I printed a lot of things on duct tape, without a raft'? On the sticky side?

Yes the professional machines make the raft follow the outline.

I get a good finish on my parts with a raft because I use a very fine, closely spaced, top layer to the raft.

---

[www.hydraraptor.blogspot.com]

Hi Nophead, I am moving to a spares bottom layer/dense top layer too because I found too many lines of the first object layer sinking in between the top layers lines with standard Skeinforge settings.

@unfold: I meant on double sided tape. I've seen duct tape used as well (to my suprise) but I only said that to confuse you all

@nophead: I'll also try a more closely pitched top layer. The first layer of the object will be better. Right now I have trouble removing the top layer of the raft from the object. It's probably because it's at the same temperature as object is extruded at (250+). My nozzle oozes so much and has slow starts and stops that I make the first layers of the object directly, not giving it time to change its temperature after the first supported layer.

B.t.w. I printed 5 very pretty bed corners last evening and today! Very little stringing because of comb + tower features:
[picasaweb.google.com]

Since the settings are pretty good now, I don't want to mess with them too much for a while (don't have the time to do too much experimentation, either).

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Yes they look good. What does tower do for you on a shape like that?

I find the temperature of the first later crucial to being able to remove the raft. I also cool the raft to ambient before doing the object. I don't know how you manage if you do it at 250C onto a warm raft. Is it not welded completely?

---

[www.hydraraptor.blogspot.com]

@nophead:
(As you know) tower makes sure that a few layers of an island are built right after each other instead of many switches between the islands. For this object it is where the horizontal teardrop shaped holes are.
Most of the gain in terms of reduction of stringing is because of the combing feature though. Without it, it used to jump from one place to another crossing the boundary of the object many times. Now it seems a path along the interior and usually takes a short path to a place it cannot reach without crossing the outside boundary.

---

Regards,

Erik de Bruijn
[Ultimaker.com] - [blog.erikdebruijn.nl]

Enrique, a feature request ... (I'm still trying to figure out python but getting pass "define the structure with white spaces" is not that easy)

One of the nophead's movies on youtube show a nifty feature that I implement by adding the g-code manually to the file and I recon it would be easy for you to add to raft making... Thing is, before you start "drawing" the raft, you pause (with heater on, extruder on) for a "X" seconds 2cm from where the raft will start so you create a "bulge" of plastic there that will nicely stick to the print bed, and then start printing raft from there. That will in fact make the first base line 2cm longer with a "bulge" on the beginning of the line...

b.

would this be something that someone could get from skeinforge statistics? - read the output and create a raft size and test it? Sorry I really like how versitile skeinforge is. To the authors credit everything you ever would need is generated, created and sliced. If you want a different raft you can recode the scripts, or just view the statistics output file. I like the weave effect of teh raft. sorry. had to comment...

Hey Enrique,

Is there a way to pass to skeinforge a different settings directory path from the command-line?

I've been gradually piecing together some code to construct "calibration unit tests", to explore how different combinations of skeinforge settings affect simple model print results. I tweaked my own local skeinforge install to search for and use "./.skeinforge" if it's found (see [github.com]), but I'd much rather specify arguments on the command-line for Makefile execution so the contents don't reside in a hidden dot-skeinforge subdirectory.

Thanks!

Andrew.

Aside: The change is to ./fabmetheus_utilities/settings.py

My particular fix doesn't work exactly as I'd hoped/expected - it creates ./.skeinforge if it doesn't find it instead of falling through to ~/.skeinforge - but it's useful to me.

A.

Hi Enrique...

I'm new to the reprap community, but I already loved Skeinforge... what a great solid tool! Congrats! And I would love to help on improve it. I have being working on my first reprap, a Techzone Huxley. It's being a ride to get it off the ground, but finally I got it running. And off course skeinforge was the only tool that actually worked without making the hot end pop out of the PTFE tube (repsnapper does that all the time... I gave up on it).

But I runned into some trouble, for example, the Z speed being too fast. I managed to alter the limit.py plugin and know the Z limit is actually working. Before my change I couldn't find any Z speed change in the generated GCode, so I'm assuming it was broken. Is that right or am I missing something?

I'm also working on some changes to the Oozebane to better work with the oversized Wades Gear, specially when Z changes.

I would really like to submit this patches for your approval so, this way skeinforge would better support the techzone huxley users, like myself. So here we go with some questions:

1. How can I submit a patch?
2. is there a central svn/git/mercurial/etc repository that you have for the trunk code? (so I can submit a patch to the latest available, minimizing the trouble to apply the patches for you)

thanks a lot in advance... and again, congrats and thanks for the amazing tool!!!

-H

I understand that Oozebane is not used with stepper motor extruders like the Wade. For those, you use the retract, restart and retract speed parameters in the Dimensions tool.

I haven't seen a problem with my Mendel z-axis with SF 40 g-code so I assume that the limit on the z is working. I have it set to 1.

@hradec

I suggest you take a look at this post. In it Enrique states he is moving discussion to his blog and gives a number of links there.

Maybe you should follow those links if you want to get involved in the software. I don't know if he monitors these posts any more.

AgeingHippy: Enrique may want to update the docs then. Last time I looked (I think it was SF40, but not sure) it pointed to an out-of-date post on reprap.org as the main point of contact.

I porter the actual version of skinforge to Python 3.2, if someone is interested.

Is there a versioning system where we can create a branch ?

1. I read skeinforge optionally depends on psyco, which is outdated, and does not run on 64 bits. It has a successor named pypy. Can this probably be ported?
2. Skeinforge eats masses of memory, in my case 2GB. Is this necessary or could it be tuned somehow?

I would probably like to contribute if I knew where to find sources etc.

There's also Python wrappers for OpenCL and CUDA. I don't see why each layer of a model couldn't be a separate thread. Bringing power to bear on computing better toolpaths would be useful, too.

PyPy doesn't seem to work with TK (looks like they are working on that)

I've made a patch that makes SF faster (up to 40% as far as I've seen):
[groups.google.com]
There are 2 changes, one is pretty safe to apply and speeds up most if not all of the steps.
The other fixes some slow splits/string replaces in checking which steps are done. Which was implemented in a slow way.

soleld Wrote:
-------------------------------------------------------
> 1. I read skeinforge optionally depends on psyco,
> which is outdated, and does not run on 64 bits. It
> has a successor named pypy. Can this probably be
> ported?
> 2. Skeinforge eats masses of memory, in my case
> 2GB. Is this necessary or could it be tuned
> somehow?
>
> I would probably like to contribute if I knew
> where to find sources etc.

One feature that would help immensely would be an option to 'scale' the outside perimeter only. Right now people are adjusting the perimeter width over height to accomplish this, this works but leaves a gap between the outside and inside perimeter.