Skeinforge Powwow

Unfold,

Oops, I uploaded a version which I did not realize was buggy. The bug fixed version is attached and at:
[members.axion.net]

Enrique

Edited 3 time(s). Last edit at 07/19/2009 03:20PM by Enrique.

Thanks Enrique, that worked!

I have an older version of skeinforge (attached) and the latest version I very much like the new features but the new version fails to correctly slice the attached STL file I'm not sure if it's settings as the object is only 1 filament wall thickness but I've tried to match everything with no success. It works great on most other stuff.

---

Ian
[www.bitsfrombytes.com]

Hi,

I noticed that when I move the last processed STL file to a different location that Skeinforge exits with an error when I try to process a new file that. The error states that SF cant find that moved file. Is this a bug or a feature

Ok I found the problem it is in the "Inset" function if the Extrusion Perimeter Width over Thickness (ratio): is too high default 1.8 then the results were bad I lowered this figure to 1.1 and all is OK. The older version has a figure of 1.8 which I guess was not being used as it generated good output. I think this would only show up in a single filament thickness build

---

Ian
[www.bitsfrombytes.com]

Ian,

Thanks for posting the bug and the old skeinforge version which worked. The bug is now fixed in the new version at:
[members.axion.net]

Unfold,

You wrote:
> ..when I try to process a new file that.

I don't quite know what you mean. Assuming you mean skeinforge will exit if it can't find a moved file, skeinforge has no way of knowing where the new file is, it just goes by the absolute file path. If you open a file which doesn't exist in the file picker, it will say something like:
home/myFile.stl does not exist


Cheers,
Enrique

Hi Enrique,

Yes confusing sorry. Its not a Skeinforge file. Its the previous converted STL. So I press the Skeinforge button in the interface, a filebrowser opens and I select the file abc.stl. Everything converts fine. Next time I open Skeinforge and press the Skeinforge button the filebrowser opens and I can select the file xyz.stl and convert that into Gcode. That doesn't work if I move the file abc.stl before doing another forge. In that case I press the Skeinforge button and get an error in the terminal stating that the file path/abc.stl can't be found...

Hope this is clearer

Hi Enrique, can you give me a little more detail on how the following works?

Below is a section from a skienforge G_Code file.
The first block down to the M103 is a normal thread running at 960mm/min
After the M103 Extruder off I have set a travel speed of 2400mm/min
1)Is the first line after M103 an acceleration, set half way between the 960 and 2400?
2)All the code between M103 and M101 is this to move the head round features of the object(like holes)
Or could the whole block be condensed into a single G1 move to the start of the new thread.
3)After M101 we get the deceleration from the fast move, is this intended or should the deceleration be before the M101 so when the extruder starts it is traveling at the correct speed.

Thanks
Tony

G1 X-2.69 Y10.04 Z1.13 F960.0
G1 X-0.18 Y12.55 Z1.13 F960.0
G1 X-0.07 Y12.59 Z1.13 F960.0
G1 X0.33 Y12.59 Z1.13 F960.0
G1 X0.35 Y12.55 Z1.13 F960.0
G1 X-2.69 Y9.51 Z1.13 F960.0
G1 X-2.75 Y9.4 Z1.13 F960.0
M103
G1 X-3.48 Y4.45 Z1.13 F1680.0
G1 X-3.43 Y4.39 Z1.13 F2400.0
G1 X0.7 Y4.39 Z1.13 F2400.0
G1 X0.76 Y4.32 Z1.13 F2400.0
G1 X0.76 Y-4.8 Z1.13 F2400.0
G1 X0.7 Y-4.86 Z1.13 F2400.0
G1 X-4.07 Y-4.86 Z1.13 F2400.0
G1 X-4.13 Y-4.8 Z1.13 F2400.0
G1 X-4.13 Y-3.5 Z1.13 F2400.0
G1 X-4.2 Y-3.43 Z1.13 F2400.0
G1 X-4.59 Y-3.43 Z1.13 F2400.0
G1 X-4.67 Y-3.49 Z1.13 F2400.0
G1 X-4.68 Y-3.56 Z1.13 F2400.0
G1 X-4.73 Y-3.67 Z1.13 F2400.0
M101
G1 X-7.04 Y-5.98 Z1.13 F1680.0
G1 X-7.09 Y-5.96 Z1.13 F960.0
G1 X-7.09 Y-5.56 Z1.13 F960.0
G1 X-7.04 Y-5.45 Z1.13 F960.0
G1 X-5.26 Y-3.67 Z1.13 F960.0

Tony,

Without your zipped preferences I can't be sure, but I think the first line after M103 an acceleration, set half way between the 960 and 2400, is because "Use Intermediate Feedrate in Corners" in fillet is selected.

All the code between M103 and M101 is to move the head round features of the object and is because "Activate Comb" in comb is selected.

After M101 the deceleration from the fast move is intended because "Use Intermediate Feedrate in Corners" in fillet is selected.

If 'Use Intermediate Feedrate in Corners' is chosen, the feedrate entering the corner will be the average of the old feedrate and the new feedrate, the default is true. This is to lower the acceleration in corners.

Cheers,
Enrique

Enrique,

I have Activate Comb and 'Use Intermediate Feedrate in Corners' as you said.

In the case above if the first line of code after the M101 was a long segment then it would be printed at a very high speed.

Looking through the file this intermediate feed rate is only associated with M103 and M101 and not with other "corners" in the printed thread. This being the case then the change in speed should only be made after M103 and before M101.

..or is there another reason for this?

Thanks for your help
Tony

Quote

On the X axis, the extrusion starts at -90 mm and ends at 16 mm, for a width of 106 mm
On the Y axis, the extrusion starts at 6 mm and ends at 115 mm, for a depth of 109 mm
On the Z axis, the extrusion starts at 0 mm and ends at 12 mm, for a height of 11 mm

This output is nice but, this object (quite simple so I'm not sure why) took over 1h to process and output us unusable as object is printed outside rapman's print bed. Is there a way to enter "print bed limits" so the skeinforge can immediately notify that object is out of range (or even better, move the object to the center of the print bed automatically - just like it is doing it with Z axes)

Use Meshlab first to centre the object around the origin then run through skienforge this will correct the problem

---

Ian
[www.bitsfrombytes.com]

Hi Ian,

I usually do that (use AOI to center it and export as GTS) but sometimes I let skeinforge take the STL directly (like I did just now)... and the current bfb firmware does not check if the target coordinate is "out of bound" so that's not a good combination ...

Don't know what I changed in Skeinforge but an object that extruded perfectly well before has its inner holes now at least 1-1,5 mm smaller (2x one extrusion width it appears). The outside perimeter has still the correct size, weird. Anyone knows what setting this might be?

ps Enrique, the file picker proplem is solved with the latest version. I get this warning and the file picker opens in the root directory: Could not get the old directory in preferences, so an unselective file picker will be used. Nice.

Edited 1 time(s). Last edit at 07/29/2009 10:13AM by unfold.

After 12 hours, the skeinforge (latest version) did not manage to process the gts file. Felt weird so I used old version (from July 14th) to parse the same gts file and it finished in under 10 minutes (using exactly the same config as the one that is still running over 12 hours)

Here is the gts file attached - maybe one can use it to find the bug.

edit: attached the config too

Edited 1 time(s). Last edit at 07/30/2009 02:53AM by arhimed.

Hi Enrique,

> bug fixed version is at:

The version I just got from there also add E value to G1. I was googling for a while without success, what is the E value in the G1 command?

The version solves the slow issue (it now takes under 15min to process the same gts file) but I managed to "dig my head into the bed" 2 times in a row (was just looking the other way - no idea how it happens), third time I was looking at it print and it was all ok, so the possible reasons for now are
- Tony's firmware got confused by the E values
- I mess up something as I just mounted new PP print bed

Anyhowm would like to know what E values are supposed to do

arhimed,

the E value in the G1 is the in progress skeinforge support of Adrian's extruder distance, as described at:
[blog.reprap.org]

and in Erik de Bruijn's conversion script page at:
[objects.reprap.org]

The E value can be removed by setting the "Extrusion Distance Format Choice" to "Do Not Add Extrusion Distance". This setting is in inset.py in the very latest version, later than the slow bug fix version, at:
[members.axion.net]

Cheers,
Enrique

@ Archimed
Yes, I had more head crashing too lately. Looks like the model starts below 0 from time to time.

@ Enrique
Any idea if my smaller inner perimeter problem could be caused by Skeinforge? I downloaded the latest version and deleted the .Skeinforge directory. Redid all my settings and the problem is still there. The outer perimeters have the correct size (< .2 mm off) but the inner perimeters of holes and openings in the horizontal plain are 1-1.5 mm off. The same object used to print ok. I can try to find an old Gcode file and see if it maybe is my machine. Or is there a setting to correct this behavior? I was pointed to stretch but cant figure that one out.

Thanks!

When I printed my first set of Darwin parts the holes were quite a bit undersized. When I printed the second set, from the same g-code, they were bigger. I have no idea why. Same machine, same settings, same nozzle, ABS from same supplier. Pretty much the only thing that changed was the heater design.

---

[www.hydraraptor.blogspot.com]

... maybe it's a mechanical problem, if the extruder/mounting isn't rigid enough or you have free play and/or elasticity in the feed.

Especially for small circles even with CNC-mills you can receive smaller and distorted eggy or squared shapes because of the play and elasticity in the surrounding mechanics ...

Viktor

Enrique, clear, E is distance so firmware do not have to calculate it on it's own and can set the extruder speed in relation to the distance that need to be extruded, neat

Will test the latest version in a bit. One question that is probably asked many times but, any chance you add some versioning string into skeinforge (would be cool to have version of each module too, but version of the package would help enough)

unfold, the stretch should help with general problem of undersized inside "openings" due to outside/inside path length on curved edge - but with regards to smaller "small" holes - I tried to increase the extruder speed and got great results. (the 8mm hole goes from 4mm to 7.8mm using PP with different extrusion speed)

The latest skeinforge is attached, in subversion and at:
[members.axion.net]

Preface.py has been added. Preface converts the svg slices into gcode extrusion layers, and optionally adds initial gcode commands. It basically does part of what inset.py used to do.

By popular demand, there is now a date string in version.txt in skeinforge_utilities in skeinforge_tools. The version date string is added in the content of the gcode output.


Allan Ecker aka The Masked Retriever, Bogdan Kecman aka arhimed, Marius and Tony,

Thanks for writing skeinforge explanations and manuals and tutorials. The list of links to your work is reprinted below and at:
[dev.www.reprap.org]


ErikDeBruijn,

Thanks for the help with Adrian's 5d extrusion distance, as described at:
[blog.reprap.org]

and in your conversion script page at:
[objects.reprap.org]

The extrusion distance format choice is now in preface. Because the E value causes problems with some firmware, the default is now off ("Do Not Add Extrusion Distance").


Frank Davies,

Thanks for posting your shell file (t.sh) to send the gcode file directly to the USB serial port, at:
[dev.forums.reprap.org]

It is now copied into the frank_davies folder in the fabricate folder in the misceelaneous folder in skeinforge.


Vik,

Thanks for testing out the new home.py tool and the new maximum z speed feature in speed.py.

Cheers,
Enrique



Below is a list of tutorials which mention skeinforge. If you make a tutorial or explanation, please link to it from this page with a description.

* Allan Ecker aka The Masked Retriever's "Skeinforge Quicktip: Cool": [blog.thingiverse.com]

* Allan Ecker aka The Masked Retriever's "Skeinforge Quicktip: Fill": [blog.thingiverse.com]

* Allan Ecker aka The Masked Retriever's "Skeinforge Quicktip: The Raft, Part 1": [blog.thingiverse.com]

* Allan Ecker aka The Masked Retriever's "Skeinforge Quicktip: The Raft, Part II": [blog.thingiverse.com]

* Allan Ecker aka The Masked Retriever's "Skeinforge Quick Tip; Tweaking the Speed Knob": [blog.thingiverse.com]

* Bogdan Kecman's Skeinforge Manual: [www.bitsfrombytes.com]

* Marius Kintel's explanation of setting the important skeinforge parameters, extrusion width and layer thickness.

* Tony's fixes for potential printer problems: [rapmanv3.blogspot.com]

* Tony's gcode reference: [rapmanv3.blogspot.com]

* Tony's list of skeinforge settings: [rapmanv3.blogspot.com]

Hi Enrique,

Nice update! Thanks for referencing those tutorials.
On the BfB wiki there is a page that is based on tonys post about solving print problems but we are expanding this with new info. Might be useful to link to the wiki page.

I'm having trouble with the support material.

While printing the support material the extruder stepper goes into higher gear doubling its speed and skipping a lot. The screen on my BfB RapMan reads an extrusion rate of 44.6mm/s. The rest extrudes at 18.8mm/s which is what I normally use. In Gcode m108 switches between 400.0 and 864.0.
So I figured that it must be a setting in Skeinforge. Support Flowrate over Operating Flowrate sounds like the setting that more then doubles my extruder speed but I have a value of 0.9. So that should be SLOWER correct?
Is this a bug or is my thinking incorrect?

Enrique Wrote:
-------------------------------------------------------
> * Bogdan Kecman's Skeinforge Manual:
> [www.bitsfrombytes.com]
>

Thanks for the reference but it is a wiki page I started and laid out some general look (listed all modules of the skeinforge) and added some explanation about few plugins only. The manual is a wiki so joint effort from many ppl (especially unfold and Dave White). I hope more will join the effort to make that a good skeinforge reference with pictures showing how different values of same parameter impact the print process / printed object.

bogdan

We now have two commercial directives’ of RepRap that are starting to generate substantial feedback to our tool chains post extruder is up and running phase.

Since its open source and we have no control over their community of users, how do we keep them involved in RepRap or provide efficient links between knowledge/cooperation?

freds Wrote:
-------------------------------------------------------
> Since its open source and we have no control over
> their community of users, how do we keep them
> involved in RepRap or provide efficient links
> between knowledge/cooperation?

IMHO interlinking the knowledge bases solves the problem of cooperation.

Now, on the "generate g-code" part it is much easier as we mostly use the same G-Code with small modifications (this one ignores these M codes, that one implements these codes this or that way and the one over there have this set of codes extra to allow you to ....) .. so all in all - skeinforge is the tool we all look at / turn to when generating G-code is the job at hand. Not sure if EMC based reprap falls into this category or they use some "different codes"...

On the electronics side things are bit different as there are few different hw dev directions out there.. the original RR where arduino/sanguino/"some atmel based proto board with serial or usb port protoboard" is controled from PC via serial/usb port where PC directly drive all the hw on the RR. There is EMC based that skips the atmel part and drive steppers directly from parallel port(s), and there is RapMan that has motherboard (based on PIC32MX440F256H) that makes the RapMan "stand alone printer" (no PC necessary). There's also a platform Nophead is using that is TI MSP430 based IIRC but he did not wrote lot about it so I cannot comment. Would like to see it dough as that's my favourite uC family . I do not want to "vote" for what is the best solution, I personally do not like arduino platform for many personal reasons... but in any way cooperation on this field here is not that easy. What is good is that all projects are open source (not sure about Nophead's firmware/electronics, but RR is full open source, the RapMan's motherboard should have schematic published soon IIRC and also the firmware is refactored and prepared to go open source as soon as BFB agrees on the licence model).

The mechanics part is shared between all, there is bunch of different extruder models (just check Nophead's blog) done by many different ppl, the basic cartesian robot is also documented pretty good. There are different "do it your self" fast'n'dirty schematics for the cartesian robot, there are few solutions like the Bits From Bytes one that are very well documented (you can get full 3d model of the finished robot on the Bits From Bytes website)... The new design is already on many blogs with different renderings in blender and aoi ...

The printing itself seams to be the most problematic part. Finding "proper temperatures" for different materials is fairly complex... I spent weeks in order to get RapMan to make usable model out of PP ... now, I do mostly PP objects ... spent days trying to get same results with HDPE without success.

Anyhow ... this is now going waaaaaaaay off topic ... skeinforge .. well, the more manuals out there - the better ... the good thing about [www.bitsfrombytes.com] one is that it is WIKI ... anyone can create account (you do not have to purchase RapMan in order to make account on that wiki) and anyone can then contribute to that manual.

Ah I guess I was asking about the linkage/cooperation hoping someone would step up to plate.

I haven't used Skeinforge yet as I got diverted off my personal advancement coaching some local kids that have access to a laser cutter (sort of makerbot) and a CNC mill so we will be moving onto this phase shortly.

Though you are right as long as it is Wiki we can simply generate the links for the cross flow.

freds Wrote:
-------------------------------------------------------
> Though you are right as long as it is Wiki we can
> simply generate the links for the cross flow.

That is the whole point. [www.bitsfrombytes.com] is a wiki page where anyone can contribute ... the hard part was organising the hosting, setting up the wiki, and all that was done by BFB's Iain and Ian .. now we just need, all together, to put some data in

Unfold and I started also putting some pictures on how different options in skeinforge affect the printout, I bet many others can join with their experience ..

Hi Enrique,

Just a small note: Some files appear to be missing in svn; at least home.py and preface.py.

Cheers,

---

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]