Possible skeinforge integration for the area tool?

[Scott]

I've been using gcodetools successfully to create some basic pocketing and milling operations. I like the simplicity of the tool set and am looking to help improve it. As I think you've seen, the Inkscape offset feature, which the area function relies upon quite heavily, suffers from several bugs. Since its not clear when those will be fixed, I have been wondering about the feasibility of making use of parts of skeinforge. Specifically, the Fill plugin:

http://www.bitsfrombytes.com/wiki/index ... forge_Fill

Seems like a promising way to generate area fills in a potentially better way than relying on the the Inkscape offsets.

Since skeinforge is also written in python, and works with svg, the integration might be fairly straightforward. However, I am wondering if anyone has already looked at this and encountered any problems.

Thanks,

Scott

[Nick]

Hi, Scott!

Yes we know that problems with Inkscape's offset. In fact there are two different Inkscape's offsets and both of them have a lot of bugs.
We've tried to make our own offset you can find it in the development thread. But it's really slow and has it's own bugs.

Our offset works better on simple paths.

In fact I've not ever seen Bezier's offset that wont have any bugs. Even Rhinoceros which I think is a really great CAD does not do it well every time. And offset a little bit simplified there.

The main problem is that offset of the Bezier curve is that it's offset is not a Bezier curve. So we can only approximate it. And the main sub problem is clipping. When we've offset the path it can has some self-intersections and clipping is cutting unnecessary parts out. It becomes really difficult taking into account all approximation's and calculation's errors.


Probably the bes way to solve these problems is to offset not the Beziers curve but Gcode-curve made of straight lines and arcs. It will be much easier but will also have some limitations...

Do you know is there any command line interface to Skeinforge which allows using Fill function? I think it would be more correct/polite to use it as an external tool through Inkscape's extensions.

....... heh ... it's kind a lot of worlds I've wrote ....

[Scott]

I'm trying to research how to call into just the fill function some this week. There actual fill code starts from skeinforge_application/skeinforge_plugins/craft_plugins/fill.py, but so far the interface I am using is GUI and the process flow seems fairly tightly integrated with the rest of the skeinforge plugins.

Do you think offsets (or at least an initial offset if we could fill the rest of the pocket with straight lines) could be more reliably generated by setting a path width of the mill diameter and then doing a stroke to path operation?

Thanks,

Scott

[Nick]

Yes filling the path with straight lines should be easy, or at least much easier than proper offset.
I thin I'll try to do it in some weeks.


But there are some thing that I do not know. Are there some "thin places"? or something that has to be thought before realizing all the functions in code.

[Nick]

Here what I've thought out:

We'll need at least tree additional parameters:
1. Spiral or zig-zag trajectory
2. Rotation angle
3. Move from one point to another by going above the material or throught the path outline

Anything else?

[Scott]

Great to hear you think it might work. Since the current area function moves above the material between paths, you could stick with that to start. It seems simpler than routing inside the pocket. You could also keep the angle fixed and fill with parallel lines as a simple start.

It seems we would still need at least one offset for a clean outline, perhaps two if you added a "finishing pass" feature, to allow someone to set a tiny finishing pass. For instance, if a finishing pass was .001 and the the mill was 6mm, the first offset would be at .301 mm and the second would be at .300mm. A finishing pass might also be helpful for depth cutting (hopefully I am not putting too many ideas out there at once).

Tool overlap would also probably still be helpful.

Thanks!

Scott

[Nick]

We should not think of what will be easier to start with. We should think what we would want it to do in complete version. Because dome times a small feature that you want to add to already written code leads to total code rewriting. So it's better to know all possible features before starting to write the code.

Regarding to rotation and moving between, it's not to hard to implement. Rotation is only one parameter and it will appear only once in the code, so it's about one line of code to bring rotation feature .

[Nick]

Hi there!

I've found a time to do some codding.

So there are first results for the area filling:

On the screen shot there are examples of zig-zag and spiral trajectories for different specified angles:

It's only the development version, and it shows possible further improvements of the gcodetools. You can get this version from the bazaar...

[Nick]

Here are some new results...
So clipping was done since the last revision.

The only thing is up to do is to join all the lines together.

[Гость]

Looking good! Hopefully I'll get a chance to check this out from bazaar soon.

Scott