Would you like to be able to make gears like these?

[Anonymous]

A little something I've been working on has allowed me to create this. I'm debating if I should expose such crazy gears in the next version of my Helical Gear Add-in. Let me know what you think!

Here's an even crazier one

Clearly such gears would not be manufacturable by conventional methods - but in the day of 3D printing and 5-axis CNC such things can be done.

By the way, gears like the following are what I'm actually aiming for

All of these gears were created 100% as-is with my work in progress add-in.

The major challenge I'm facing now is actually finding a way to give the user sufficient control with the very liming UI available to a Fusion Add-In 😞  I'll try to find a way!

[hanskellner]

Those are some very cool gears.

As for the UI limitations, what exactly do you need?  Imagine you could create the UI that would satisfy the needs for your Add-in.  What would it be and/or what UI widgets would it need?

[Anonymous]

Honestly, I'm not sure. I've been thinking in terms of what's possible with the current limited, and sometimes broken, inputs available (tabs, tables, IMO groups are also broken as a group with the "checkbox" shown can cause up to 3 previews to be triggered when expanded OR collapsed). For one I would appreciate a way to control when a preview is fired - or a stock solution where an add-in can provide the user with a button they can click to refresh the preview instead of any little change causing a 30 second (or more) preview to fire.

So far, I've been more focused on working around the very poor performance of sketches, even with my workaround for a bug in profile computation, it can take a 20 seconds or more to draw the sketch for a gear with a couple hundred teeth - which python was able to compute all of the geometry for in a couple of milliseconds. I'm computing the full gear profile to avoid the the slowness of combining hundreds of bodies - and honestly the new sweep is really awesome when acting on the full gear profile. I'm still exploring where the right balance is for performance - it's a battle between sketch slowness and the slowness (and complexity) of working with hundreds of bodies. I've gone so far as considering using the new drawing and "Temporary B-Rep Construction" API's but the drawing API is very low-level and i'm not that desperate yet, and the "Temporary B-Rep Construction" API is of no use (apart from being a possibly easier layer over the drawing API) in a parametric document as far as i can tell.

I digress... sort of... the above performance issues means that the UI needs to stand on its own without providing the user with any, or perhaps very limited, visual feedback of how their changes are impacting the result. This makes the challenge of providing a way to describe a wavy gear, for example, extremely difficult as I have no way to know ahead of time how may waves the user may want - each could have its own angle, length (or start/end location), the diameter of the gear could be changed, heck even the tooth profile (e.g. Crowning) could change over the length of the gear (my existing helical gear add-in uses loft as it predates the sweep-twist operation - but only loft would provide this ability, albeit a bit messily).

I digress gain... anyway, my general UI wishlist 

• An honest float input would be lovely, the lack of something that resolves params and provides unit-less float input has been a constant thorn in my side - i've had to code up float validation  using regex's and a custom elevator wrapper for such inputs and I haven't gotten to doing the param resolution yet.
• The single input per row form factor is inherently limiting, I understand it but i still want to be able to horizontally group things so i dont need to find a way to vertically separate repeated collections of inputs (such as number of teeth and backlash when defining a gearbox which contains multiple gears***)  - i know the table input is supposed to help address this but see above about "broken inputs", I ran into the same mess when i looked at them the first time so I haven't looked again yet, but I haven't seen any mention of this being fixed in release notes or the API whats new page since it was reported.
• Custom validation feedback would be helpful. In my existing helical gear add-in I had to roll my own error messaging solution... which at some point read only text inputs started triggering previews by the way - not sure if that has been fixed yet or not either.
• Dynamic inputs with rich interaction is really the big thing... So much so i've considered seeing what i could do with "pallets" but I rather expect it to also be overly limited and not a fully functional HTML container... I'm HTML, CS, JS savvy, I'd trade the custom input ball of wax for a fully functional HTML UI layer in a second - esp. if i could use libraries like JQuery and Angular. 
• I love that the text input supports HTML formatting and _some_ css but figuring out what it supports and doesn't is blind trial and error as it's simply not documented anywhere i've found.

*** The second bullet point above may capture a key pain point - one that the ability to define a collection of inputs as an entity (a set of related inputs which belong to some container) that could be repeated in the UI and iterated over in code. IIRC table works something like this 

[hanskellner]

Really appreciate the feedback/response.  Going through it again and reading linked posts.  Sounds like similar issues I've run into.

[Anonymous]

And i really appreciate you reading my walls of text 😄

Current helical gear add-in UI for context (this one already as the dendum multipliers exposed which my released version does not)

Given the UI limitations I was thinking of breaking the gear into standard sections and allow the user to control each section of gear generation (eg: a double helix would have: cap, face, point, face, cap - where the 2 faces would be treated the same but of opposite helix directions but the 2 caps might be treated separately).

Along with the standard inputs of helix angle, pressure angle, teeth, module, backlash, handedness and "thickness" I plan to also surface addendum and whole depth multipliers as an advanced option and adding double helix normal and double helix radial standards. Then give control over the endcaps and point transitions (for double helix). I was thinking of providing a canned list of options (e.g. dropdown) for each with appropriate icons of course.

For end caps I was thinking of the options of: 

End Cap Style: None, Parabolic - ease out, Parabolic - ease in,  Parabolic - ease both, Linear Taper

End Cap Position: Outside, Inside, On Center (relative to the specified overall thickness of the gear).

And a checkbox to give the option to leave the end "pinched" or to restore it to the root cylinder.

I could either provide a few canned values for the various options or give the user a set of dynamic inputs (ok so hidden or shown because dynamic is not really practical) to give the user more control over the radius of the small end of the cap and how thick the cap is. The issue with this is that it is most practical to specify radius as relative to the outside, pitch, or root circles and to specify both radius and thickness in units of module or whole depth is even better. Using whole depth would mean that the user could change any other gear param and the end cap would still "look", and more importantly, print the same without having to futz with the values specified.

Similarly the transition point between the two halves of a double helix gear has a load of options

Transition Style: Sharp, Strait Segment, Smooth, Cosine, Parabolic, Smooth to Strait, Cosine to Strait, Parabolic to Strait

  each of these, except sharp, has a length involved - and the XX to Strait options have 2 lengths, the transitional length and the strait segment length

Then there's also the option of reducing the radius through the transition as well to avoid point loading (and lets face it that point gets messed up when 3D printing)

... and we haven't even gotten to the exotics like those wavy gears - those would likely be fully canned options, or perhaps I could let the user specify the number of direction changes at least.