Git Product home page Git Product logo

yapp_box's People

Contributors

4q1 avatar aeburriel avatar deflateawning avatar dtorres-sf avatar goramai avatar juchong avatar mrwheel avatar ografe avatar rosenhauer avatar t-paul avatar zyphlar avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

yapp_box's Issues

YAPP_Box - unexpected behaviour with the padding around the PCB

I am learning how to use settings in YAPP_Templatev3.scad, I have include set to YAPPgenerator_v3.scad (downloaded 27 Jan 2024)

I have the following settings:
showSideBySide = true
viewport is set to view from above

I am observing some unexpected behaviour when I change the padding around the PCB
Increasing value of PCB "padding front" increase padding at back and left, but does not increases padding at front ?
Increasing value of PCB "padding back" increases padding at front, but does not increase padding at back ?
Increasing value of PCB "padding right" has correct result.
Increasing value of PCB "padding left" increases padding at right, but does not increase padding at left ?
The unexpected movements of the PCB also causes lid switch cutouts and other related PCB artifacts to move to incorrect positions in the lid

Can you check and see if you can replicate this behaviour?
Are there other settings I need to enable first ?

I think the behaviour lies in YAPPgenerator_v3.scad,
function getPCB_X(pcbName="Main")
lines 4497, 4498 and 4502 all reference 'paddingFront', is this correct?
should line 4497 be 'paddingBack' ?
should line 4498 be 'paddingLeft' ?
should line 4502 be 'paddingRight' ?

Regards

request: add fillets to corners

The box' corners (connections between sides of the cube) are weak structural connections and on top are weakened additionally from the outside fillets (the round corners).
To increase strength of box, please add (optional) fillets to all corners on inside of the box.

feature request: through hole in base, through standoffs, into lid standoffs

Your script is incredible.

I would like to fasten my boxes together by putting a machine screw in from the base, through a board standoff, through the board, and threaded into the matching lid standoff (which can already be programmed to have a hole in it.)

I don't mind threading the the lid standoff with a tap (or heat-setting a metal threaded bushing), so no threads need be programmed.

The base should have some sort of recess for the screw head. A simple cone would be a good start, though that might be problematic for pan head screws (but fixable with some hand work).

I have successfully created both lid and base standoffs with holes in them, but the base hole does not pass all the way through the base. Of course, I can fix this by hand with a drill.

I've tried hacking away at v20 of your library, but I'm not good enough at openscad to get the hole to pass all the way through
the base.

Thanks again for a great script.

boxMounts doesn't work anymore

boxMounts doesn't generate anything now. Tried against version 2024-0-17 and they work but not with the newest version.

Advice about STP exporting/KiCad?

I've been designing a PCB with KiCad and I've been finding it handy to make a footprint out of a proposed YAPP box in order to sanity check it and make sure everything's where I think it is. For a 2d footprint, I've found that adding

projection(cut=true) translate([0,0,-8])

just before the YAPPgenerate(); will give me a 2d drawing I can export to a DXF and import directly into KiCad. Adjust the z value in order to define what z level to make the projection through.

But what if you want to add a 3d model to the footprint? Well, KiCad requires a STEP file and a WRL file for its 3d models and OpenSCAD doesn't support that. The recommendation I've found for turning an OpenSCAD document into STEP/WRL files is to use FreeCad as an intermediary. I've attempted some simple OpenSCAD example documents in FreeCad and they work fine, but I've pretty much had no luck importing an YAPP model into FreeCad. At best I get a dozen or so primitive objects imported and hundreds of lines of DXF import error messages. I've tried both the built-in OpenSCAD importer and the "Alternate" importer that's a plugin (which claims to support more native OpenSCAD directives).

Before I throw more time into trying to get this working, I was wondering if anybody had already found a set of import preferences and plugins that work acceptably for this purpose. Thanks!

Clarify include and function needed for basic operation

Following what's in Git and GitBook it's not mentioned that you need include <YAPP_Box-3.0.1/YAPPgenerator_v3.scad> at the top of the file and YAPPgenerate(); at the bottom. Only by reading the blog post did I infer those details.

Ideally in the What You Need section of the Book and the How to program your Project Box section of the Readme these details will be added so that a newbie can copy-paste and get basic output in OpenSCAD before continuing, sort of a Hello World to ensure that things are installed correctly.

Indeed the instructions talk about putting YAPP in the libraries folder, but then the blog post tells you to include the file with a relative path, which can confuse people who aren't experts.

Thanks for this great library!

YAPP_Demo programs @rosenhauer

@rosenhauer,

Is it an idea to name all programs that test/demo a specific function off the YAPPgenerator the name "YAPP_Demo_<array_name>.scad" and also reflect this in the comment block at the beginning of the program.

All not needed array's should be removed from the YAPP_Demo_program so it is clear what is needed to (only) create (in this case) boxMounts.

All these YAPP_Demo programs should then be part of the repo.

Something like:

//-----------------------------------------------------------------------
// Yet Another Parameterized Projectbox generator
//
//  This is the YAPP_Demo_boxMounts program for testing and
//  demonstrate the use of the boxMounts array.
//
//  Needs YAPPgenerator Version 3.0
//
//-----------------------------------------------------------------------

Why?

To give users a simple example for using the (getting more and more complex) YAPPgenerator.

p(5) (standoffPinDiameter) of pcbStands is not used

configList[5] is used only here in v3.0.1:

theStandoffPinDiameter = getParamWithDefault(configList[5],standoffPinDiameter);

but theStandoffPinDiameter is not used. I guess some instances of standoffPinDiameter should be replaced with theStandoffPinDiameter.

using own variables not possible?

I have come to enjoy YAPP. Now I would like to use own variables for configuration to simplify layout changes; instead of this:


pcbStands = [
                [ 7.5, pcbWidth- 3, standoffHeight, 2, 11, yappBaseOnly, yappPin] , 
                [ pcbLength-7.5, 3, standoffHeight, 2, 11, yappBaseOnly, yappPin] ,

I want to write this

sx=7.5;
sy=3;
pcbStands = [
                [ sx, pcbWidth- sy, standoffHeight, 2, 11, yappBaseOnly, yappPin] , 
                [ pcbLength-sx, sy, standoffHeight, 2, 11, yappBaseOnly, yappPin] ,

you get the idea.
But at compile time the values of own variables are unknown for computing pcbStands. Same for other YAPP declarations.
Please advise how to proceed

Feature request: inner walls

It would be nice to have the ability to add arbitrary inner walls e.g. for routing cables and separating high/low voltage PCBs.

Reusable cutouts

I'm looking for a solution to reuse my custom cutout. I need this to position the holes for the electronic connectors that are bolted on. This code generates such a cutout, however I don't know how to place it in the template.

//  Parameters:
//   Required:
//    p(0) = connector opening diameter
//    p(1) = horizontal distance between two screw openings
//    p(3) = wall thickness 
//   Optional:
//    p(4) =  count of screw openings arround connector <4>
module connector_w_screws( hole_dm, screw_dist, screw_dm, wall_thickness , screws_cnt = 4) {
    wall_thickness = wall_thickness + .01;
	translate([-(2*screw_dm + screw_dist)/2,-(2*screw_dm + screw_dist)/2,-wall_thickness  / 2 ])
    {
        difference() {
            plate_l = screw_dm + screw_dist ;
            cube( [plate_l,  plate_l, wall_thickness  ]);   // base plate   
            
            translate( [plate_l/2, plate_l/2, -0.01] )                 
            cylinder( d = hole_dm, h = wall_thickness  + 0.02); // connector opening
           
            trans_screw = [
                [screw_dm/2, screw_dm/2, -.01], 
                [screw_dm/2 + screw_dist, screw_dm/2 + screw_dist, -.01], 
                [screw_dm/2 + screw_dist, screw_dm/2, -0.01], 
                [screw_dm/2, screw_dm/2 + screw_dist, -0.01]
            ];
            // screws openings:
            for (i=[0:screws_cnt-1])
            {
                translate(trans_screw[i] )
                cylinder( d = screw_dm, h = wall_thickness  + .02);
            }         
        }
    }
}
connector_w_screws( 24, 26, 4, 1.8);

Inner radius of connector standoffs/sockets isn't union'd

When using the connectors feature, some slicers like Prusa or AnkerMake will run "split to objects/parts" to separate out parts for printing, but the radius'd rings inside the connectors will drop to the bed instead of staying merged with the bottom of the case.

Theoretically exporting them all as one mesh would help with this, though I'm not deep into YAPP enough to know the details. I just know this is the only feature I encounter this issue with. Cura and MatterControl don't seem to have this problem either.

Thank you

No Issue but a big public THANK YOU Willem for this project. It's super helpful, saves tremendous amount of time and works like a charm :)

Request: re-organize the repo so that version are tracked at historical commits, and are available as releases

The proper way to use a Git repository is to only have a single version of the project in the repo at one time. Versions should be tracked by tagging them using GitHub Releases.

If you want to continue to support historical versions (e.g., you have v1.9.0, but you want to release a small improvement called v1.9.1), you should use branches for each of those lineages (e.g., a v1.9 branch, which tracks all patch releases forwards). This is how projects like OSGeo's projects (e.g., QGIS) work, and is rather standard.

Let me know if you'd like any more guidance getting this setup!

are standoffHeight calculations correct for pin hole lengths?

In v1.6, the default for standoffHeight is 3.0 mm. For a board I've got, I needed to change that to 4.0 mm. I found that the case does not fit together snugly after that. The pin hole legs are touching the PCB surface, but there is still a gap of (eyeballing) about 1 mm before the snap-fit tabs can engage. Without the PCB inside, the case does close perfectly. It also closed perfectly in an earlier iteration that used the default standoffHeight.

I'm doing some experiments now to see if faking the PCB thickness by an extra 1 mm will work around this.

I wanted to track this down and send you a PR, but the calculations look a bit complicated. I thought maybe you could find the problem much faster than I could (or would be able to confidently tell me that I'm wrong).

Assertion '(ridgeHeight >= (wallThickness * 1.8))' failed

[ERROR: Assertion '(ridgeHeight >= (wallThickness * 1.8))' failed: "ridgeHeight < 1.8 times wallThickness: no SnapJoins possible" in file ../../OpenSCAD/libraries/YAPPgenerator_v3.scad, line 1041]

Please change 1.8 to 1.3 ... (or make it a constant so user can adjust for his printer)

Maybe you can move "Helper Functions" (like shapes, masks, Ridge Extension) to the end of the YAPPgenerator and base functions (like cutouts, pcbStands snapJoins) to the beginning..

Change pin height

Issue

Jonatan Liljedahl says:

Is there any way to change the pin height? I want to mount some parts almost flush to the lid, for example a display. But changing the standoff height makes the pin go through the lid.

image

Generation fails and I don't understand why

Hi,

The following code gets an error when I render it:
ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron.
What do I do wrong ?
Thanks.

include <../YAPPgenerator_v3.scad>

printBaseShell        = true;
printLidShell         = true;
printSwitchExtenders  = true;
showSideBySide=true;

baseWallHeight      = 25; 
lidWallHeight       = 10;

paddingBack        = 40;

pcbLength           = 91; // Front to back
pcbWidth            = 50; // Side to side
pcbThickness        = 1.5;

standoffHeight = 3;
standoffDiameter = 5;
standoffPinDiameter  = 2;
standoffHoleSlack=0;


pcbStands = [
   [5, 5, yappBaseOnly, yappHole ],
   [5, pcbWidth - 5, yappBaseOnly, yappHole],
   [62, 5,yappBaseOnly, yappHole],
   [62, pcbWidth - 5, 2, yappBaseOnly, yappHole],
];

cutoutsFront =  
[
    [3,pcbThickness,0,0,3,yappCircle, yappCoordPCB],
    [40,pcbThickness,0,0,3,yappCircle, yappCoordPCB],
];

cutoutsLeft =  
[
    [34, pcbThickness, 10, 10, 0, yappRectangle, yappCoordPCB],
    [8, 8, 0, 0, 3, yappCircle, yappCoordBoxInside ],
    [28, 8, 0, 0, 3, yappCircle, yappCoordBoxInside ]
];

areation = 10;

cutoutsBack =  
[
    [15, baseWallHeight - 15, 20, 3, 0, yappRectangle, yappCoordBoxInside],

];

cutoutsLid = [
    [22,42,0,0,4,yappCircle, yappCoordPCB],
];

snapJoins   =   
[
    [10, 5, yappLeft, yappRight, yappSymmetric]
   ,[10, 5, yappFront, yappBack, yappSymmetric]
];



//showPCB = true;

YAPPgenerate();

BUG: pcbStands only on base, never on lid?

@rosenhauer

yappGenerator Version="v3.0.3 (2024-03-21)";

It seems impossible to have a pcbStand on both sides if yoy also use optional params. Base is OK, lid is not. There is a small circle noted on the lid but that does not extend to de PCB.
pcbStands = [ [5, 5, yappDefault, yappDefault, 6 + 1.25, 4.1, 9, yappBoth, yappFrontLeft, yappBackRight, yappCoordPCB] ];
standoff

With only the parameters the length of the stand on the lid does not comply with the height of the connectors (which are correct)
pcbStands = [ [5, 5, yappFrontLeft, yappBackRight] ];

Future request

It would be nice if

  • buttonSlack = 0.4;

can be set in the box-program.

How can you set up multiple PCBs at different heights in the same case?

I have a project that has a main PCB ("Logic board" with ESP32 and other circuits and connectors) and a display.

The "Logic board" would be mounted on the base and the Display would be mounted on the cover so the mount points for the "Logic" board' would need to be for example 6mm from the base and the display would need to be 3.5mm from the cover. Ideally the display would actually be flush with the inside of the cover below an opening on the cover to be able to see/touch it.

Feature request: test CI/CD workflow for this project

When making upgrades, it would be helpful to be able to confirm that a list of example/sample test files still compile successfully and correctly (or at least very similarly to how they did before).

I'm not sure exactly what the solution looks like, but a GitHub Workflow with many test files for this project could be very helpful as it continues to grow, to continue that the project is working in each branch/PR before it's merged.

Does anyone involved in this project know of any other OpenSCAD library/library-like projects that have this sort of testing workflow setup? Otherwise, it can't imagine it would be that hard to setup ourselves.

Function logic correction

With a roundRadius of 1.0, the inside of my lid was solid rather than hollowed out. I found that a slight correction to the logic of a function solved the issue.

around line 4876 ... made less than or equal
function getMinRad(p1, wall) = (p1<=wall) ? 1 : p1 - wall;

The function probably needs a greater amount of logic where p1==wall.

BTW: really nice work done on a great library

Enhancement request: threaded inserts support

I would like to have those things as on the image, which can be used for threaded inserts or just as screw hole. On the lid and/or on the base.
I want to mount box on a bicycle, so I need some reinforcement.
image

imagesPlane has no effect

I tried with various svg files to put a logo on a box. There are no errors or warnings but it looks like it is simply ignored.
imagesPlane =
[
[ 10, 10, 180, -2, yappLid, "Logo_neu.svg", 0.2 ]
];
May be we should include a simple example with a working svg file.

BUG: showPCB = true but PCB not at the right height!

@rosenhauer

I'm currently working on a box for a project I'm working on.

YAPPgenerator: Version="v3.0.3 (2024-03-21)";
But with showPCB = true the PCB is not displayed at the correct height.

  • showPCB = true;
  • standoffHeight = 4.0;
  • connectors = [ [5, 5, 4, 2.5, 6 + 1.25, 4.1, 9, yappDefault, yappAllCorners, yappCoordPCB] ];

P1Reader2Eth_scad.txt

As a consequence the switch-tubes are also incorrect (to long)!

Screenshot 2024-03-22 at 08 39 42

Also - future request:

I would like the Cap of the push-buttons to be a bit higher so they fall a bit deeper in the lid. With tolerances during printing sometimes the Cap is completely above the lid. No problem for a yappCircle cap but if it had a (f.i.) yappRectangle shape it can turn and then you can not push it anymore.

push-button

Variable scope?

I'm working on a new box for the Colorlight 5A-75B board (please see udif@b03609a).

While designing the box, I wrote something like:

include <./library/YAPPgenerator_v13.scad>
...
pcbLength         = 143.64; // i(5.6496);
pcbWidth          = 91.69; // i(3.6);
...
holeX = (pcbLength - 135.26) / 2;
holeY1 = (pcbWidth - 81.28) / 2;
holeY2 = (pcbWidth - 60.33) / 2;
pcbStands = [
                 [            holeX, pcbWidth - holeY2, yappBoth, yappPin]         // back-left
               , [            holeX,            holeY2, yappBoth, yappPin] // back-right
               , [pcbLength - holeX, pcbWidth - holeY1, yappBoth, yappPin]         // back-left
               , [pcbLength - holeX,            holeY1, yappBoth, yappPin] // back-right
             ];

This brings tons of errors like Ignoring unknown variable 'holeX', Ignoring unknown variable 'holeY1', Ignoring unknown variable 'holeY2' pointing to the pcbStands lines above.
It also brings a bunch of undefined operation (number - undefined) but if we understand that somehow holeX , holeY1, holeY2 are somehow underfined at that point, then this secondary warning is understandable.
As this leads to non-working standoffs, I found a workaround, by assigning the 5 constants above the YAPP code:

pcbLength=0;
pcbWidth=0;
holeX=0;
holeY1=0;
holeY2=0;

include <./library/YAPPgenerator_v13.scad>
...
pcbLength         = 143.64; // i(5.6496);
pcbWidth          = 91.69; // i(3.6);
...
holeX = (pcbLength - 135.26) / 2;
holeY1 = (pcbWidth - 81.28) / 2;
holeY2 = (pcbWidth - 60.33) / 2;
pcbStands = [
                 [            holeX, pcbWidth - holeY2, yappBoth, yappPin]         // back-left
               , [            holeX,            holeY2, yappBoth, yappPin] // back-right
               , [pcbLength - holeX, pcbWidth - holeY1, yappBoth, yappPin]         // back-left
               , [pcbLength - holeX,            holeY1, yappBoth, yappPin] // back-right
             ];

The code now works, but I don't understand why was this necessary.

In addition, several new warnings on YAPPgenerator_v13 itself (I'm not giving line numbers, because my fork added a few lines for the rotated cutout code):

function getMinRad(p1, wall) = (p1<=wall) ? 1 : p1-wall;

(4 times undefined operation (number <= undefined) and 4 times undefined operation (number - undefined)) which I totally don't understand why.

                translate([shellLength-15, -15, 0])
                  linear_extrude(1) 
                    mirror(1,0,0)
                      %text("LEFT"
                            , font="Liberation Mono:style=bold"
                            , size=8
                            , direction="ltr"
                            , halign="left"
                            , valign="bottom");

I get Too many unnamed arguments supplied and Unable to convert mirror(1) parameter to a vec3 or vec2 of numbers on the mirror(1,1,0) line.

Request: in `pcbStands`, add option to have pins on the top instead of the bottom

Currently, you configure which sides (base/lid) have pins and holes with these options:

//    n(a) = { <yappBoth> | yappLidOnly | yappBaseOnly }
//    n(b) = { <yappPin>, yappHole } // Baseplate support treatment

yappBoth puts the pins on the bottom, and the regular connectors on the top.

Option 1 (preferred):

I'm proposing that the section could instead be setup like this:

//    n(a) = { <yappBasePin> | yappBaseHole | yappBaseNoStand } // bottom/base support config
//    n(b) = { <yappLidHole> | yappLidPin | yappLidNoStand } // lid support config

This option allows easier configuration of the shape of the PCB stands on each side. The downside is that it's possible to configure it so that there are pins on both sides (which would prevent it from closing). It's easy to avoid doing that though.

Option 2:

Alternatively, I'm proposing that the line could be changed to:

//    n(a) = { <yappBothPinsFromBottom> | yappBothPinsFromTop | yappLidOnly | yappBaseOnly }
//    n(b) would stay roughly the same, I think

This change would prevent the user from creating pins on both the top and the bottom, but it feels way less intuitive to me.

Add option for standard DIN Rail mount

Hi,
there are many cases where PCB will be put into rack or electric cabinet, so will be very useful to have an option to enable/disable a standard DIN Rain mount on the base.

Any possibility to add in a future release?

Many thanks.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.