-
Notifications
You must be signed in to change notification settings - Fork 151
Any interest in a D-Ring module? #1687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Seems like there is interest. Hardest thing to figure out about this is probably how to handle the attachment settings. Do you attach to the bounding box cube? It's also not a D-ring, so maybe the name should be something else? Any thoughts on where it belongs in the library? |
Do you support a D-ring form where you only have a half-circle? |
My BOSL2 skills are not to the point where I use attachments, so I have no idea .... I call it a "d_shape".
shapes3d.scad, "other round objects"
Are you asking about the overall shape, or the through-hole? The overall shape can approach a half circle, as long as the rounded_prism() shape has a finite height. The current code for the through hole only supports a full cylinder. |
I was asking about the hole---you know, to make it an actual D-ring. The thinking about this is that it's a "part" rather than a "shape" so it would belong somewhere in the parts library. But I'm not sure what it would be called. (Coming up with names for things in the library is often a challenge.) What name would convey its use and function, so that somebody would find it if they needed something like this? I encourage you to read through the attachments tutorial https://github.com/BelfrySCAD/BOSL2/wiki/Tutorial-Attachments and learn about attachments, because I think they are possibly the most important thing in the library for how they can simplify a model made from more than one object. |
I tried to modify this code:
to use attachments:
but it fails with an error
It works without top_half(), but I tried several different things and never got it to work with top_half(). Any suggestions? |
I can't actually run the code to see what you're doing because it's got a bunch of undefined variables. But in your second example, you're using top_half as a module but passing it a p argument, which only exists for the function form, because the There is another issue, which is that top_half is going to lose the geometry info (because we can't get geometry out of modules) so attachment won't work properly there. If you want to do that operation you'll need to attach the full cylinder and cut it off after attaching it. Note that making your object attachable is separate from using attachments to make your object. To do that you need to decide what the correct anchors are for your object and invoke |
Following code includes attachments, but attachment are only correct in Z-dimension when b_height = d_rad. The part is non-symmetric to the center of the "D" circle when b_height != d_rad and then anchors are incorrect. I don't know how to fix this. Since this part is non-symmetrical in Z, it might make more sense to anchor the part to the X-Y plane, but I couldn't figure out those anchors either. Also, I will take a look at allowing a D-shaped hole. Are you thinking the D-shaped hole would be a semicircle? Otherwise we are adding several new variables ....
|
The way attachable works, the children need to be centered in every direction. Your asymmetric shapes where anchoring fails are not centered vertically. Basically when you give the size, it's defining a centered cuboid with that size as the anchor points. If you then make BOTTOM the default anchor, the shape will appear sitting on the XY plane. I think the way you have it with the attachment point DOWN is the right way to do this. (Note also that if you turned it sideways the anchors would still be wrong if you didn't center it.) Regarding a D shaped hole, only if you think it's useful and you want to do it. I toss out ideas and they aren't necessarily always good, so pushback/dialog is fine. You may want to consider talking about contributions on the developer chat (link on the github landing page). Why would we want a D hole? Well, a D hole lets you have a wider slot in a shorter height. You could address the need for a wide slot by making the hole an ellipse, which just requires one parameter and would possibly be a trivial modification. That also avoids the problematic issue of rounding the inside corners of the D. Another wide hole option might be a rounded rectangle of some kind or the squircle. For naming it seems like this object is like an eye bolt without the bolt. The front running name so far is connector_ring() which I'm not a big fan of, so still looking for ideas there. |
Here's the code, including the module calls for the examples above. Let me know if you find any bugs.
|
From your examples it's looking good. Can you write the doc text. Just take a look at some module in the library and follow the same form. The one thing that might not be obvious is in the Arguments section, the "---" separator separates between positional arguments, listed first, and named arguments. The docs processor uses indentation to parse stuff, so pay attention to indentation. You should create enough examples to display the significantly distinct modes of operation and various features. |
Did we get consensus on the name of the part? I saw the discussion, and I do agree that "attach" should not be part of the name. Other than that I have no strong feelings about any of the proposals. |
Go with connector_ring for now. We can change it if some better idea comes along before we push the release. We also don't know which file it's going in. It should be categorized as a "part" but doesn't obviously fit in anywhere. |
I should have the documentation ready later today, maybe tomorrow. How can I test it to make sure the doc looks correct in the wiki page? |
In principle you can install the docsgen package that creates the docs and run it locally. I haven't done this myself and hence can't tell you how to do it. Basically once it appears on the wiki...I look at it...and fix all the things that are wrong. I'll look over your docs for any obvious issues and then we'll see how it looks. |
After a bit more thought, I realized that we're looking at this part a little differently. For me, the through hole is just an extra option, and could even be removed from the module (and use the documentation to show how easy it is to add the through hole). |
The name should ideally be chosen so that people who want the thing will realize that it fits their needs and is the thing they want. It seems to me that the functional purpose of this thing is to put a ring on something. With an edge case option to turn off the hole, presumably because you're adding your own hole of some kind. I'm not compelled that calling it "connector_ring" is a bad choice or that it misleads---unless you can develop a major use case for the hole-free version. |
Here you go, with the documentation text. There are a few blanks to fill in .....
|
Doc formatting looks ok to me---I don't see any obvious issues that will cause problems. You have a sentence introducing limitations that are never articulated. Is there a compelling reason to use three variables for the dimensions of the object instead of a vector parameter like cube() uses? I am uncertain about whether roundingb should have its sign flipped. I understand why it works the way it does, but a value that is always supposed to be negative seems wrongly chosen, and in other contexts (e.g. join_prism) where a fillet is expected, the value is positive. |
My feeling is that one parameter with three unnamed values would confuse me. I would prefer named parameters so I can remember which rounding is which.
For the Topics heading, I would include: For the See Also heading, I would include: Remove the line "Some contraints to be aware of:" unless there are constraints to be aware of. The documentation is automatically tested when you submit a PR, and you'll be notified if the tests fail. Should this be part of joiners.scad, or a standalone file? |
As still-a-newb, I would expect it to follow the convention of
I'm putting together a PR for a new joiner (a clamp with internal fins) so I've been going through this right now. There's some good ideas in here. |
Thanks for the feedback, guys.
Fixed.
I am passing the roundingb variable directly to rounded_prism() without changing the sign.
I prefer Alex's suggestion. base_h is not the height of the prismoid, it's the z-location of the Y-cylinder. Z-height of the prismoid is the tangent point of prismoid & Y-cylinder.
Please clarify exactly what change you are asking for.
I will implement this feedback. |
I know that you passed the negative radius through directly. That's is in fact the justification for using a negative value there. But I think it should follow join_prism: rename I think Rename Rename anchors hole_ctr_front and hole_ctr_back to just hole_front and hole_back. Note that CENTER is zero, so FRONT+CENTER is the same as FRONT. So also in the docs: "same as part BACK" not "BACK+CENTER". I wonder if it would be better to refer to a "disk" instead of "Y-cylinder". You can just say "center" not "rotational center" of a cylinder (or disk). Also maybe write the description for someone who doesn't know what a prismoid is, so it's a self-contained explanation of what this module does for the person who only uses the parts library. It seems like the first 4 parameters are pretty confusing because things that aren't the same are named the same and the order is surprising. I think either: base = 2-vector giving x and y size of the base (e.g. like rect) or base_x = x dimension of base I could also see doing length and thickness instead of base_x and base_y. It's crucial that And then you have ir, id for the hole. Should there be a parameter that is an alternative to ir/id that gives the ring width? Analogous to the I think that Alex was not asking for a change when he said he preferred named parameters. Rather, he was opposing my suggestion of using a vector of parameters. However, the expectation is that the positional parameters will be used without names, so the order should make sense and you shouldn't be relying on the names of those positional parameters to understand the named parameters. Regarding the right file, I'm not sure. This doesn't seem like it belongs in joiners.scad. It doesn't function to join things. I had the idea of a new file called hooks.scad, but that would be a little more compelling if it already existed and was full of (other?) hooks. A "loop hook" does seem to be a concept out there. That could be a potential name for the module. |
What Adrian said. Apologies if my earlier response was muddled. Don't we already have a hook model somewhere? Or a snap clip? If we do, they could be merged into one file along with this. I was thinking of this D-ring as a sort of fastener to hang one object onto another; that is, join them. That's why I suggested joiners.scad, but maybe something like hooknring.scad (in the spirit of vnf.scad, which means "vertices 'n' faces") could work. |
I played around with the idea of size = [base_w, thickness, total_height], and tried it out in the code I'm writing that instigated this new module. This serve to remind myself that this part is all about placing a cylinder (screw, heat insert, whatever) a certain distance from a plane. So perhaps base_h should be hole_h (short version hh). |
The default is 0, which tells the code to omit the hole. Do you prefer a separate Boolean? The rest of the feedback is complete or in progress. Seems to me that adding the wall variable will require a holeBoolean... |
The reason I remarked on the default is that in the example posted, the defaults were not zero. It really seems like this object should be first and foremost a loop---that is, with a hole. In other words, it's not a thing with an optional hole. It's a thing with a hole...but you can turn the hole off. Given that nobody can think of a use case for a version with no hole, this seems like the right way to bill it. Maybe it should be required to specify a hole dimension somehow, and you can give zero for no hole. In the examples there is just one example at the very end that is "by the way, you can set ir to zero and get no hole". If the above is the plan then I'd probably code that something like:
Or maybe you use Regarding the vertical height parameter, hole_h is bad. What's the height of the hole? It's diameter? Distance to the top of the hole? Position to the hole center is very far down the list of what I think the "height" of a hole is. The parameter should be hole_center, or something along those lines. I had suggested disk_center above, but you're now acknowledging that the hole is important. I guess Some thought needs to go towards the right choice for the positional parameters. If the hole is primary for example, it should maybe be: [base_x,base_y], hole_center, ir, wall but that might be too many positional parameters. It might be that just base_x, base_y and hole_center should be positional. |
I think should work as a final version.
|
You still need a topics heading. I suggest "Parts" at a minimum. If I recall correctly, docsgen may fail without it. The blank line before the first example will also cause a failure. Or it will cause none of the examples to process. Remove it. There's some debate in the gitter chat about what file to put this in. We discussed making a new file for hooks and loops and putting it there. |
I wrote a module to create D-rings. It's quite simple, a union of a rounded_prism() and a ycyl(). It's only interesting because the tangents are calculated so that any reasonably sized base can join to any ycyl. If you are interested, I will add some error checking and share the code.
The text was updated successfully, but these errors were encountered: