florianfesti / boxes Goto Github PK

Would it make sense to add a callback 4 at the end of the If-clause (y-2*r) < 1E-3 in surroundingWall?

If there is not floor under a wall it currently has e edges which creates a gap between the wall and whatever the box is standing on.

Replacing it with E may still need fixing the Slotted edge to support Edge.startwidth() und .endwidth()

In the online app for this, some boxes have their x, y, and h incorrectly labeled. For example, in the FlexBox 2, the width labeled as X isn't really the width of the resulting box at all, and as such can mess people up when trying to design a box with specific dimensions. To get a wider box, I had to increase the h setting, which is labeled as height but does not actually control the height of the box, but the height of the pattern, which corresponds to the width of the overall box. Maybe make the fields better define what dimension of the box it is for? Or show a diagram?

Make box generator available as Inkscape plugins.

This requires multiple pieces:

• Generating .inx XML files from argparse objects
• Generate menu structure (using the UIGroups)
• Make sure the way cli params are handled is compatible
• Copy generated svg into document passed from Inkscape

It would be cool if the generators could have descriptions (longer than just the one liner in the doc string).

The descriptions could contain information for assembling the generated box, or lists of materials when the thing you build contains more than just the generated walls.

For nicer formatting, a markup language would be good like Markdown (as used by github). Maybe this package would work? -- https://pypi.python.org/pypi/Markups

If projects get more complex, they often get their own homepage somewhere else, e.g., on hackaday.com. Hence, they also should get an (optional) URL that links to more details.

Needs some way to structure them into groups or section.

First of all thanks for this wonderful code. This is extremely helpful!

Just a small thing: I discovered a tiny artifact in a surroundingWall rendering in case one generates a box with two 180° rounded sides, i.e. y=2*radius. Here the straight part between the two 90° round corners gets zero and I expected to end up with a clean 180° flex wall, just twice as long as each single 90° wall, with nothing in between. However, a small distance seems to be generated in between those two round corners.

That screenshot might explain it better:

My quick fix is to test if l-2*r get's zero in boxes.py:surroundingWall by replacing

        for i, l in zip(range(4), (y, x, y, 0)):
            self.flexEdge(c4, h+topwidth+bottomwidth)
            self.cc(callback, i+1, y=bottomwidth)
            if i < 3:
                bottom(l-2*r)

with

        for i, l in zip(range(4), (y, x, y, 0)):
            self.flexEdge(c4, h+topwidth+bottomwidth)
            self.cc(callback, i+1, y=bottomwidth)
            if i < 3 and l-2*r:
                bottom(l-2*r)

But there might be another way to handle this better.

Model to reproduce:

from boxes import Boxes, FingerJointSettings
import math

class Bug(Boxes):
    def __init__(self):
        Boxes.__init__(self)
        self.buildArgParser("x", "y", "h")
        self.argparser.add_argument(
            "--radius",  action="store", type=float, default=41,
            help="Radius of the latch in mm")

    def render(self):
        x, y, h, r = self.x, self.y, self.h, self.radius
        t = self.thickness
        b = self.burn        
        c4 = (r+self.burn)*math.pi*0.5     
        width = 4*c4 + 2*(x-2*r) + 3*t + 2*b
        height = h + 5*t + 10*b        
        self.open(width, height)        
        self.surroundingWall(x,y,r,h)
        self.close()        

if __name__ == '__main__':
    b = Bug()
    b.parseArgs([
        "--x", "150", 
        "--y", "78", 
        "--h", "40",
        "--radius", "39",
        "--output", "bug.svg"])
    b.render()

Two more small remarks:

• wouldn't it make sense to separate the parameter burn from the ctx line_width as some machines ignore non-hairlines, larger than 0.01. For now I just use a self.ctx.set_line_width(0.01) after open()
• in my first ever cut on a laser I found the default 10% stretch for the flex part of a surroundingWall too short. Wouldn't it make sense to also turn this stretch factor into a parameter?

Thanks for sharing your code!

it seems the corners of fingejoints are rounded, which makes assembly slightly easier. However, the inside corners of slots also have what looks like an attempt at rounding that failed: the lines cross and then a rounding is applied at the opposite quadrant of the cross.
To reproduce: make a closed box (probably applies to all fingerjoints?) http://www.festi.info/boxes.py/ClosedBox?FingerJoint_angle=90.0&FingerJoint_surroundingspaces=2.0&FingerJoint_edge_width=1.0&FingerJoint_finger=2.0&FingerJoint_play=0.0&FingerJoint_space=2.0&FingerJoint_width=1.0&y=100.0&x=100.0&outside=0&outside=1&h=100.0&thickness=3.0&format=svg&debug=0&reference=100&burn=0.1&render=1
download either as svg or ps file and open in coreldraw (other vector software should work too?)
switch to 800 or 1600x zoom and wireframe view.
look at inside corners and wonder how that got there?

I suspect there is a function somewhere that tries to round over corners of edges and fails half the time? The code to make a fingerjoint does not seem to contain such function.

The rounding is very small, so in practice it does not do much, except make the lasercutter stutter a little in each inside corner, which does result in slightly better fitting slots (unintensionally?)

Hi.

• I generated the inx files locally, finding them in ../boxes/inkex/
• I copied boxes.py.AngledBox.inx both in /usr/share/inkscape/extensions/ and
  ~/.config/inkscape/extensions/
• I opened Inkscape 9.1 and seen the exptension
• when I click on it nothing happens.

What am I doing wrong?
I'm using Ubuntu 16.04 and Inkscape 0.9.1

Thanks for the program/software/extenction, it's simply game changing in creating stuff.

Since commit 0ba0c19 "Detect size of drawing and set svg viewport accordingly" (some of?) my cuts are longer (in x-direction) than designed.

My process is: boxes -> VisiCut -> Zing-Laser

On verifying my designs in Inkscape all measurements are as expected, but in VisiCut the x-size of objects tend to be somewhat larger (scaled up).

Here an example of a very simple object (I can provide the source on demand) looks like this in Inkscape

which looks like this in the VisiCut preview (and cuts on the Zing in those extended dimensions)

If I go back to the version of boxes where the canvas dimensions had to be set manually, I get the same result in Inkscape, but the correct size in the VisiCut preview (as well in the Zing output):

Only the x-dimension seems to suffer from this scaling issue. I now stepped back to the version before that commit and the x-scaling issue seem to be gone.

I have to note that this issue might be caused by VisiCut, which is know to have issues in interpreting the design dpi of SVGs and tries to recognize the creator of designs to adjust its interpretation.

t-oster/VisiCut#174
t-oster/VisiCut#347

Not having any idea of the SVG format, I quickly looked at the generated file headers and see for the trunk version

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width=" 80mm" height=" 60mm" viewBox="0 940 70 60" version="1.1">

and for the boxes version with the manual viewport setting

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100mm" height="64mm" viewBox="0 0 100 64" version="1.1">

If I adjust the version generated by boxes trunk to (not knowing what I am doing) to

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="80mm" height="60mm" viewBox="0 940 80 60" version="1.1">

VisiCut seems to interpret the x-scale correctly again.

Thanks for sharing your wonderful work!

Minor:

x and y are not defined in flexbox4:render() and self.c4 is never used.

    def render(self):
        self.radius = self.radius or min(x, y)/2.0
        self.c4 = c4 = math.pi * self.radius * 0.5

Hex hole have a poor ratio of closed wall to ventilation openings and need a lot of cutting time. Slit patterns could be better and could fit outside borders more nicely.

Hey, i have got a box idea, but i dont know how to script that (also i have windows and this doesnt works for me).
The main idea is to make open-box with different heights of front and back walls.
I tried to make simple sketch for this ;)

When I run "http://www.festi.info/boxes.py/IntegratedHingeBox" I get the incorrect line on the box lid shown in the image below.

Here were the settings for the box:

http://www.festi.info/boxes.py/IntegratedHingeBox?FingerJoint_angle=90.0&FingerJoint_surroundingspaces=2.0&FingerJoint_edge_width=2.0&FingerJoint_finger=1.0&FingerJoint_play=0.1&FingerJoint_space=1.0&FingerJoint_width=0.50&ChestHinge_hinge_strength=1.0&ChestHinge_pin_height=2.0&y=100.0&x=100.0&outside=0&outside=1&h=60.0&lidheight=40&thickness=5.31&format=svg&debug=0&reference=100&burn=0.08&render=1

While the library supports "bed bolts" (slots for nuts and screws holding walls together at joints) the generators don't.

        self.open(50, 50)
        x = y = 10
        r = 0
        h = 46
        sep = 20 # 12
        self.surroundingWall(x,y,r,h,
            left=edges.CompoundEdge(self,["D","e"], [h-sep,sep]),
            right=edges.CompoundEdge(self,["e","d"], [sep,h-sep]))
        self.close()

renders

The left edge is not what I expected. The right edge looks fine.

Hello, as you see it generated with font errors on any templates. Can you fix it? Thank you!

For this issue I could not even find a good title as it is a bit weird.

Consider the following script that works as expected.

    def render(self):
        self.open()
        self.rectangularWall(10, 10)
        self.ctx.save()
        self.moveTo(5,5)
        self.ctx.rectangle(0, 0, 3, 3)
        self.ctx.fill()
        self.ctx.restore()
        self.close()

Now if you change the moveTo line to

self.moveTo(5.1,5)
or
self.moveTo(5,5.1)

it still works. But changing it to

self.moveTo(5.1,5.1)
fails.

While the SVG for the "working" variants generate a header like this

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width=" 20mm" height=" 30mm" viewBox="0 970 20 30" version="1.1">

the header of this last failing one looks like this

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width=" 20mm" height="1010mm" viewBox="0 -10 20 1010 version="1.1">

to be able to keep the lids closed.

Many generators only have very generic descriptions - only repeating the name as a sentence. Descriptions should stay short but add information to the generator name.

Generator should have a longer description than may include assembling instructions or limitations that is shown on the generator page (in contrast to the "description" that shows up in the generator list).

Could you tag a version when you reach a 'stable' point?

Right now pulling from master results in alternating working and broken releases. Tagging would make successful working milestones easier to track.

Thanks!

Sides of the lid may need shortening if the radius of the hinge is bigger that the height of the side wall of the lid. This is currently not done but the radius on the lid is limited to the height instead of matching the box.

Many new features have not made it in the API docs yet. Especially the new edge types

As HTML checkboxes only submit data on being checked there is no way to overwrite the default with False.

Hi can anybody explain how to get the Extensions workingf in Inkscape? I searched everywhere and also followed the Explenation from misiekkk but i cant get it working... has someone screenshots on how to make it?

Thanks for every help

Finish the boxes.py logo. A isometric box with finger joints created with black magic on top of regular Boxes.py code.

Create a treasure chest with hinges or adjust Box2 to render them for the treaure chest lid when 'v' top edge is selected.

When I go to the extensions in Inkscape it shows the menu items but it does not show the actual functions (dropdown shows as empty)

As i often rework produced paths to include inner cuts in my boxes sides, the extra optimisation of having rounded corners to make perfect corner cuts is bugging me more than it helps, and specially the ones in the finger inner corners ::

Would it be possible to have this feature been optional ?

Can you update script on http://www.festi.info/boxes.py/index.html ?
I'd like to try dove tail joints ;)

Those generic names like Box1, 2, 3, 4... are not very helpful. Those generators deserve more descriptive names.

Do not use fixed pattern make change spacing to fully fill out the area.

even if other parts are drawn intermediately.

It's still unclear if thit can be done with cairo. Further examination is needed. May be draw on separate groups or canvases during callbacks.

Dear Florian,

I finally received a laser and could start testing the models I constructed before using your fine lib. Everything works out as expected. However, one model uses fingerHolesAt in a callback to "install" a separating wall in a box. While the walls them self well-fit (a little tight thus) with the burn parameter I set, the holes generated using the fingerHolesAt macro are too small to insert the corresponding fingers.

As seen in the screenshot I tried to measure the holes and the fingers and came to the following result:

a) burn=0.06, thickness=3

• holes generated using fingerHolesAt: 2.88mm x 2.88mm
• pin distance (generated using edges["F"]): 2.94mm
• pin thickness(generated using edges["F"]): 3.06mm

b) burn=0.16 (way to large to make a fit!), thickness=3

• holes generated using fingerHolesAt: 2.68mm x 2.68mm
• pin distance (generated using edges["F"]): 2.68mm
• pin thickness(generated using edges["F"]): 3.31mm

So at burn=0.16 the distance between the fingers and the size of the hole agree (but of course this would not fit in any case as that burn value is to high), but not at burn=0.06 the size of the whole and the finger distance do not agree. The finger distance works for those fingers with the kerf of my laser as expected, but not the tighter fingerHolesAt generated hole.

Any idea?

Hey, i ve got wried edges while using http://www.festi.info/boxes.py/index.html
My plywood cutting service doesnt like it 😢

from generators/init.py

Build script writes "unknown sub command". A little more information could help. Why not print out sys.argv along.

Most of the software I've seen for working with laser cutters doesn't support SVG or PS...

Would really appreciate if you could implement DXF or PDF as an output option as theres no good path to go from SVG to DXF that I've been able to find.

While we have a parameter in the flex settings it is often not used. May be the flex edge should use is directly. But this would require an opposing edge that does the same thing.

Hey! This library looks interesting. I am trying to find software that can generate the walls for a box with a complicated shape. The "box" is actually a heart shaped path (see image, which includes my own box notches). Do you think your software would work for this? I have seen other tools not work because of the type of corner marked with a green arrow. I wrote my own "notcher" library in JS but it is not as robust as I had hoped.

With the latest commit I receive

boxes/init.py", line 24, in
from boxes import svgutil
ImportError: cannot import name 'svgutil'

Florian, could you please commit that svgutil.py?

Thanks,
Marko

to be used in the UI. Images should all have the same - still to be determined - size and style.

See Boxes.open()

• .bedBoltSettings
• .hexHolesSettings

Sorry, me again.

It seems that FlexEdges are not fully entered within their length. A little hard to see in the screenshot below as one does not see exactly the start and end of the two FlexEdges. However, the holes are here fully centred within the intermediate edge, but the distance to the left flex is larger than that to the right flex.

I took a look at edges.py:FlexEdge:call and saw that you already compute a leftover and use it for centering. Took me a moment to understand that you also need to compensate for the fact that the first line/cut is starting on the calculated pos, but the left line is positioned still one dist from the calculated end of the flexedge segment (this is easier to show than to express in words;).

Anyhow, the fix is to replace

pos = i*dist + leftover/2.0

by

pos = i*dist + leftover/2.0 + dist/2.0

I really like your idea, but would want to use it for milling. Is there any reason this would be difficult? I'm considering implementing this myself if not.

This might be just a stupid user misunderstanding of the specs. However, I expected that one of the two variants (FingerJointEdge or FingerJointEdgeCounterPart) would go to the outer side of the wall and the other towards the inner side. Here is my example code:

        self.open(55, 60)
        x = y = 10
        r = 0
        h = 46
        sep = 20        

        s = edges.FingerJointSettings(self.thickness, space=2, finger=2, surroundingspaces=0, relative=True)
        #p = edges.FingerJointEdgeCounterPart(self, s)
        p = edges.FingerJointEdge(self, s)
        p.char = "p"

        self.addPart(p)
        self.surroundingWall(x,y,r,h,
            left=edges.CompoundEdge(self,["e","p"], [2*h/3.0,h/3.0]),
            right=edges.CompoundEdge(self,["p","e"], [h/3.0,2*h/3.0]),
        )
        self.close()

The one variant looks like this

and the other like this.

Both turn to the outside of the straight wall. Is this intended?

Extend the existing finger joint edge or create a new one that is form-locking. Make the finger stick out two thinknesses and have a notch on both sides. Render a comb like piece like 3 thicknesses in width that can be slid through the space between those slots to lock the part with the fingers in place.

Have a variant that can go on each side of an edge of a box securing both walls.

Hello,

When I generated a box, I have some issues with the corner
Can you fix the error of corner of a square like picture 1

The corner is 2 point but not 1 point as normal, like this

Thank you!

Changing the angled box height parameter does not seem to affect the svg output.