Age | Commit message (Collapse) | Author |
|
The CAD model of the full assembly might be useful to be included in
other projects or CAD files.
|
|
Most users will not own the default printer and thus cannot work with
the built gcode files with the default slicer configuration.
It might be easier for those users to manually slice the STL instead of
modifying the soundbox source code.
|
|
|
|
|
|
Providing a structural overview inside the README should help developers
new to the repository to get familiar with it.
|
|
This document will be quite long. Thus the report document class is more
suitable.
|
|
This draft should give an overview of the planned sections which is
useful to decide what should belong into the first sections and what
should be written in later ones.
|
|
The build system should convert the documentation source files
automatically to a single PDF file to make documentation generation
trivial.
|
|
This target removes the build directory and is thus repository-global.
|
|
This LaTeX document should contain the full device documentation for
soundbox. It will not cover aspects about the source or how to build.
This should be covered inside the README of this repository. Everything
else will be part of the resulting documentation PDF file.
|
|
This license should cover the documentation of soundbox because software
licenses like the AGPL or hardware licenses like OHL are not well
suited.
|
|
The front panel needs holes for the HDMI, micro USB and cinch connectors
of the Raspberry Pi Zero W.
|
|
|
|
After switching the panel to PCB-based dimensions the shell follows with
this commit.
|
|
The whole case should move from case- to PCB-based parameters.
|
|
The long term goal is to switch from case-oriented parameters to
PCB-oriented parameters to simplify re-using the pcb_case library.
|
|
This makes the file structure simpler and makes it easy to produce the
whole case in one run.
|
|
This value used to consider only the required space for the Raspberry Pi
Zero W board, not for the required HifiBerry board.
|
|
|
|
This will help to identify calculation issues by human visual
inspection. The PCB is not yet aligned.
|
|
Without the bolt_ds_tol the drilling is too tight to be used for
tolerance testing without drilling manually.
|
|
Based on tolerance test printing.
|
|
Result from test print.
|
|
This is the result from a tolerance test printing.
|
|
Reducing from +/- 3 to +/- 2 reduces printing time for the tolerance
test.
|
|
|
|
The printer resolution is set to 0.15 mm so this is a useful step size.
|
|
This makes the results of tolerance tests available for the actual PCB
case.
|
|
There used to be two panels but this is not required.
|
|
The width and height tolerance test was unusable because the thickness
tolerance was not added. Thus the test part did not fit inside the slot.
|
|
The current tolerance values should be written down inside the files
covering the related parts. The tolerance_tests.scad file should include
those values.
|
|
nut_d should be used exclusively to avoid handling to alternatives for
the same parameter.
|
|
This makes the file structure and module naming simpler and allows to
easily print all tolerance tests at once. This is helpful to validate a
specific printer setup.
|
|
This allows to check the tolerances for panel width and length.
|
|
This tests makes it easier to fine-tune the slot width which holds one
of the two panels.
|
|
This should make sure the right hole diameter is selected for bolts.
|
|
This bolt is a good starting point for most PCB cases.
|
|
This special variable decides on the level of detail these cylinders are
rendered with. Since this depends also on the size and thus on the
individual cylinder it is also set per cylinder individually.
|
|
|
|
The printer configuration should not only be added to the repository but
instead should also be used for the default Make-based builds of
mechanical parts.
|
|
Adding a slicer configuration is important to have reproducable printing
results. While a default configuration should be sufficient to print the
part roughly it is especially important for correct tolerances that the
printer settings are exactly the same.
Starting with the i3 Mega S provides only configuration for one 3D
printer. Nevertheless additional configurations for other printers can
be added easily.
|
|
It is quite easy to add bugs to *.scad files and miss them. Warnings can
be hidden inside the long log output.
This commit will ensure that bugs are detected earlier.
|
|
|
|
|
|
|
|
The holes used to be all the same size. This is clearly a bug since the
test's intention is to check different sizes.
|
|
That way it is easier to get that the test is built and not nut when
building the corresponding file.
|
|
The old name was not descriptive and now the file contains only
parameters.
|
|
This avoids unrequired usage of other source files and cleans up the
common.scad file.
|
|
According to the 'Mastering OpenSCAD' [1] book it is not recommended to
set these variables globally. They should be used as local as possible
and only if needed.
This rule makes sense to allow making the model as rough as possible and
only increase the detail level if required to reduce build times.
[1]: https://mastering-openscad.eu
|