I’ve been learning how to write featurescripts, and I figure I should share what I’m making with the community so they’ll go to good use. (Instead of just being used by me since I haven’t been able to convince my team to switch to Onshape yet). Here’s what I have to start:
Chain/Belt C-C Calculator:
Finds the correct C-C distance for a chain/belt run given the sprocket/pulley sizes, chain/belt pitch, and either the number of links/teeth in the chain/belt or the approximate C-C distance. Returns a variable which can be used in sketches to define the true C-C distance or directly into your preferred belt/chain featurescript.
Gearbox Plate Extruder
Extrudes a plate of your desired thickness that encloses the gearbox entities of your choice. You select the points or circles defining the holes that you want to be “enclosed” in the gearbox. For each point or circle you select, you choose an offset defining the minimum distance between the point or circle edge to the outside of the plate. The featurescript automatically finds the tangents connecting the outside circles and extrudes a solid plate. Note: circles/points must be selected in order (CW or CCW) and only the outermost circles/points should be selected.
I’m working on an “improved” Lighten featurescript like I described here, but that one isn’t quite ready yet. If you have trouble using these or find any problems with them (not unlikely considering I’m new at this), feel free to post here or send me a PM.
Could it be done? Sure, it’s not too hard. But it turns an already crowded UI into something almost unusable. Some bearing holes may need recessed flanges, so you need an array parameter to ask that for each one. Different standoff holes might be different sizes so you need an array parameter to get that for each one as well. (And who knows the drill/tap sizes by memory anyway, that’s what the standard holes are for.) Each motor mount has 6 parameters (using your featurescript) so that also needs a huge array parameter. At that point even putting each section into a group doesn’t help because each section on its own is longer than the screen. You’d be scrolling for days just to get through the featurescript inputs.
As it stands right now, you only need one feature each to make the part, bearing holes, standoff holes, and motor mounts. And if you make the layout sketch so that everything except the bearing holes is construction geometry (like I did in the example) then you can easily extrude cut the bearing holes from the original sketch. It seems easier to me to keep everything separate for better comprehension than cramming everything into one featurescript, even if it means a few extra features in the tree. I’d be interested to hear your reasoning if you disagree.
Hey, I have 175 posts of scope creep in my thread so it’s only fair that I get to ask for some from you Of course it’s entirely your decision what to add. I like having as few features as possible to keep my feature tree navigable and semantic but the UI crowding is a compelling argument.
I’ll also note that you can now use boolean array element parameters to show/hide other array element parameters to increase clarity. Nothing that will make it too much clearer of course, but might help.
This might be easy to do without making the UI much more complicated, you don’t even need an array parameter for it, just a query. It also reduces the number of features from 4 (script, cut, standoff holes, motor mounting) to 3 (script, standoff holes, motor mounting) which is the same number that a normal gearbox plate would have before (extrude with a profile in the sketch, standoff holes, motor mounting).
Oh! I’m really surprised right now becuase I was going to make plate extruder for my next project. And my first project was also a belt calculator. Huh. Maybe we could work together? I’ve been thinking about trying to use a convex hull algorithm to find the hull automatically, to remove the need to select holes in order. And some other QOL things as well. But I’m still in the conceptual/testing stage for that. In any case, I’ll definitely use your stuff for inspiration, assuming I do end up moving forward with it!
I have a convex hull implementation in my gusset script here, line 522. The limitation is that it a) only returns convex hulls, which means that it wouldn’t be able to do concave plates, and b) that it operates only on points, so if there were a larger circle between two smaller circles that should form the hull, it would improperly identify that as a non-hull point.
I’d be very interested in algorithms that you could use to find the convex hull of a collection of circles.
Yes, I thought about that issue while brainstorming. My friend @OneMoreIteration came up with a potential workaround; Instead of using the centers of the holes, you use the edge of the circle furthest away from the center of the bounding box (So for each circle, you add a vector to the center of the circle pointing away from the center of the bounding box with magnitude equal to the center of the circle, and use that point for your hull). I’m not sure if that would work in every situation (There might be some weird outliers if the center of the bounding box is in an odd place?), but I think it should be robust enough for the majority of plates.
In order to allow concave hulls, I was going to add a secondary option to go back and basically select the (three?) holes you would want to make concave using an additional drop down, and that would just use those centers to figure out where to cut into the plate. So it would start with the convex hull, and then you would cut away as needed. Again, I haven’t had a chance to actually start working on it because college, but I’ve been scheming about it for the past couple of days, and I think I see a path to a working implementation.
Yeah I found a few papers similar to this, but the math in here is well over my head (I stopped after PDE). If someone else wants to implement it, I’d be more than happy to steal their code (with proper thanks and attribution of course). In the meantime, it doesn’t seem so hard to select the outside circles in order or rearrange them if you mess up the first time.
Question to the community though: would it be easier to use if I left in the debug showing the offset circles as you’re selecting to better visualize what the plate bounds will look like? Or does that just add clutter?
Results are looking promising. Regen times are a bit slow (~2 seconds) but that’s not terrible considering lightening should be the last thing you’re doing anyway. Looking for one or two people to do a quick beta test before I release it publicly.
I just pushed an update with the gearbox lightening featurescript:
Gearbox Lighten
Hollows out the plate on the face selected, except for the ribs you select and a margin around all edges. For FRC gearboxes, It’s a good bit easier to use than the regular Lighten featurescript. The regeneration time is around 1-2 seconds, depending on the number of pockets.
Of course it’s entirely your decision what to add. I like having as few features as possible to keep my feature tree navigable and semantic but the UI crowding is a compelling argument.
