search

ubitux / shimonbox

Semi-automatically generated 3D printable cases for development boards using OpenSCAD
177 stars 22 forks source link

Add RPi4 (w/ optional "blower" case) and other component changes. #7

Open thehans opened 4 years ago

thehans commented 4 years ago

Here are my changes for adding the board model and case for the Raspberry Pi 4 which include:

There's still some issues I had with implementing my blower case with duct, which I'm not too satisfied with. I'm still willing to fix them up so it integrates better with the main scripts, but was hoping to maybe get some input from you @ubitux on best way to handle.

1) I added the printed fan duct under "electronics/misc", so it would be more easily positionable like other components, but I think maybe it should be part of case.scad somehow. a) Automated export doesn't create an stl automatically for the duct, and requires user to manually export it by uncommenting lines. b) The demo gif just shows the duct in fixed position fixed relative to the PCB, and the case top passes through the duct as it lowers. Really the duct should be lowered from above after the case-top. 2) The bottom of the blower case uses vent holes on the side, but this also requires manual uncommenting to view. I wasn't sure how best to handle a completely new style of vent like this without some input from you first. 3) I also left commented option to view the mockup of the blower, by putting NopSCADlib in a folder next to top level shimonbox project, since I think you didn't want to add dependencies when we spoke in IRC. I don't feel like seeing the fan model is particularly crucial so I don't mind leaving this as "manually uncommentable" option compared to other points above.

So yeah, I think my changes could still use some work, but was hoping to hear some thoughts from you before I go changing even more of the main functionality! And I understand if you are busy and occupied by other things, so take your time. :)

ubitux commented 4 years ago

Here are my changes for adding the board model and case for the Raspberry Pi 4 which include:

Hey, nice work. You even took photos and updated the README, awesome :)

* All new USB-C port, redesigned microHDMI port.

* RPi4 board model

* RPi4 case (in same style as RPi3)

* Alternate blower style RPi4 case using "5015" centrifugal fan

* Minor changes to USB mini and micro "rear plate" (this change is why many of the board animations are replaced. though its just a few barely-noticeable pixels at the image scale)

Alright so, These changes are nice, but one thing that would be welcome would be to split the commit atomically. Right now, it's very hard for me to follow how the changes are tied, it makes the review painful, and it will be problematic for potential fixes/blame/revert in the future.

Typically, I'd have individual introduction of new electronic component in dedicated commits. Prototype/behavior changes in their dedicated commits as well. The introduction of the board in one as well. And finally the case(s). On the other hand, your "fixup" commits should be included in the appropriate commits. It would really help me reviewing the changes.

If you need help with git, I can provide that on IRC, but I'm sure you can find help out there as well. git rebase -i and git add -p will be your close allies in this adventure if you need startup directions. Since you'll be rewriting your history, you'll have to push force into your branch. Feel free to do so as much as you need to, and you do not need to re-open another PR each time.

There's still some issues I had with implementing my blower case with duct, which I'm not too satisfied with. I'm still willing to fix them up so it integrates better with the main scripts, but was hoping to maybe get some input from you @ubitux on best way to handle.

AFAICT, that blower is very similar to the button pushers thing used for example in the BBB. It's something that has to be printed separately by the user. Look for that button pushers code in case.scad. They are still defined in the electronics, so having the blower there as well is not shocking.

These button pushers are built automatically according to button components present on the board. A dedicated .stl is generated. Maybe something similar could be done with, let's say the CPU: you make the CPU dig a blower-sized hole into the top case, and the engine figure out where to place it according to the top case position and thickness. Having the blower always perfectly aligned with what's hot is likely what you actually want. Does that make any sense to you?

ubitux commented 4 years ago

I Forgot to reply this:

I also left commented option to view the mockup of the blower, by putting NopSCADlib in a folder next to top level shimonbox project, since I think you didn't want to add dependencies when we spoke in IRC. I don't feel like seeing the fan model is particularly crucial so I don't mind leaving this as "manually uncommentable" option compared to other points above.

So yeah you are correct: I don't like dependencies. OTOH, it is debatable that people wanting to contribute to shimonbox would have to design every single component. My position would be: all or nothing. If you can have all the components we have defined in shimonbox available upstream in NopSCADlib (or any other similar projects), then we can indeed consider this.

I see a few issues though, the main one being that in shimonbox components have an extra information for the "digging". I'm not sure if this would fit in another project. Also, the dependency for something as core as the component means that if we can't get a component upstream, or if that dependency dies-off, decide to change stuff, it's problematic for us. Any change in a component there could also affect the layout of our boards. In the end, we would probably end up with components split inconsistently between the two projects, and I'm not sure that would be an improvement. I'd rather have a smaller database, with ugly component sketchups, thank risking badly printed cases for our users.