How to edit commands after they are executed? (Edit custom features)

[Anonymous]

What's the best way to edit custom features after creation (eg Spur Gear)?

I'm about to try this by jumping through a bunch of hoops involving the marking menu and attributes on the objects. But I can't tell if all the pieces will fit together yet.  I saw mention of 'client features' in one of the blog posts a while back (http://modthemachine.typepad.com/my_weblog/2015/09/fusion-360-hackathon-qa-1-2.html), but don't see it in the API list...

[ekinsb]

Funny that you should mention the spur gear as an example because I have plans to add this behavior to that add-in.  I did some work in the last update of that add-in to enable edit functionality later when the context menu functionality would be available. The context menu is available now but I haven't had time to update the add-in yet but I can tell you what I was thinking about how I'll go about supporting edit.

The thing that I did before and is already in the current Spur Gear add-in is that I'm adding attributes to the gear component that the add-in is creating. These attributes contain all of the information that was used when the gear was created; essentially all of the settings in the dialog.  I can use this later when editing the gear to initialize the dialog with the current gear values.  Also, just the existence of this attribute on the component tells me that it's a component created by the spur gear add-in.

My plan was to add handling of the markingMenuDisplaying event to the add-in and watch for whenever the entity currently selected is an occurrence that references a component with the attributes I've added.  Whenever that's true, I'll add a new "Edit Spur Gear" command to the context menu.  If they select the command then I'll display the spur gear dialog but initialize it with the values I get from the attributes.  They can now edit any of the values and click ok.

Now, there are a few decisions to make about how to change the gear.  I haven't decided which way to go with the spur gear yet.  The easiest thing to do in my case will be to delete all of the contents (sketches and features) of the gear component and re-create the gear geometry.  The problem with this approach is that anything that referenced any of the gear geometry, (for example, creating any joints on the gear), will go sick because the geometry they referenced no longer exists.  The other approach is to try and modify the existing geometry.  This would be quite a bit harder but better for the references.  

Depending on the geometry you build and the changes that can be made, it might be possible to just change parameter values to get the new shape. If you can construct the model in a way that this works, that would be the easiest of all but it's not an option in the case of the gear because the shape of the tooth isn't define parametrically.

[Anonymous]

Your approach is what I was thinking might work in a pinch. A bit of a hack though no? Shouldn't the parameters of a feature be model parameters instead of attributes? (I understand that the add method is not exposed in the api and that's why you are using attributes. But the point is that features should be consistent whether created by the user or not.)

I poked around the api a bit more, and I have a better feeling for where the developers drew the interface boundary now. It appears they had a meeting and said something like:

"Only we, the grand wizards of topology, geometry and UX, are capable of the intricacies of feature creation. Any user wanting to get stuff done shall wait for our permission and the blessing of our wisdom. So shall it be."

Hopefully there is a bold and clever visionary in their midst, who no doubt at great personal risk, will, like Prometheus, bring the Client Feature to the masses.

Until then we wait in the darkness...

Thanks for your reply. In the case of the spur gear generator you might reconsider how you have it set up. You should probably be building the gear teeth off existing hub geometry. I think gear teeth are usually a final detail (you are not often modifying the faces of the teeth with additional features). In which case deleting and rebuilding the feature works fine. Dependant geometry will reference the hub and be unaffected by changes to the teeth.

As a side note, I'd choose to use an existing cylinder face to define the pitch circle as my first 'parameter' and then add details from there, as that better matches the design workflow for both custom and off the shelf gears better. (One chooses a ratio and sees if the volume is acceptable before choosing things like tooth size or backlash).

[ekinsb]

Some of what I suggested is a bit of a hack but I think it's the only solution given the current tools we available.

We've had discussions about providing the ability to create custom features and it is something we plan to do, so it's not something that we've intentionally hid.  With any new feature we have to weigh the benefits vs. the cost.  Custom features definitely provide some benefit but at a very high cost.  The cost will also be across several teams so the impact on resources is high.  When weighed against other things we want to do that have a high benefit and much lower cost the prioritization of custom features puts it lower in the list.  

Regarding your comment about using parameters instead of attributes; I don't see that as a use this or that question but instead see a use for both.  Unfortunately, until custom features are available there isn't a good way to take the best advantage of parameters.  But even if I could there would be some things that make sense to expose as a parameter and other things would be a "property" of the feature which I can store as an attribute.  For example, when you create an extrusion there are parameters for the depth and taper angle, but there are a lot of other settings (extent type, operation type, etc.) that are stored by the feature.

And finally, regarding your comment about how the spur gear program works; I agree that it might be better to allow the selection of an existing cylinder and add the gear to it. The API samples weren't necessarily designed to be full featured utilities but are samples demonstrating various capabilities of the API. The fact that they are sometimes actually useful is an added bonus.

[Anonymous]

Ah, you are one of the wizards 😉

I understand prioritization of capabilities. Also that few users are likely to exercise the api. And that certain approaches to implementing features internally could make exposing a generic interface difficult. All good.

I see what you are saying about storing object properties in the attributes collection...

[sgraves]

@ekinsb

Brian,

Seeing as how this is a recent post and I was in here searching on this very subject.  I would like to tag on to this discussion.

I was thinking about expanding the gear creation capabilities in exactly the way you have described.  But my ambitions go further.  I created a set of tools for OpenSCAD to create gears.  I started with the thinking that gears are always created in pairs and extended that concept to gear trains.  So when creating a gear one could also create a compatible gear.  And since a subsequent gear in a gear train would be along a shared shaft I added the ability to give a direction and length offset to the next gear in a train of gears.  Ultimately, I had a mechanism to define an gear train in a specification.  I also had a function that scanned the gear train specification and validated the gear pairs (or more in the case of planetary gears etc.) and output where there were problems and why.

I also had helper functions that allowed one to use different approaches to defining a gear.  These helper functions originally were to aid in using the various different ways in which manufacturers specific their gears.  They expanded to cover other things like creating a pair of spur gears given the distance between two shafts and the desired ratio etc.

The concept is that I have developed a knowledge about gears (more than one would expect an EE to have) that I would like for others to leverage.  The example of designing spur gears to go between two shafts is but one of many use cases where a tool could solve the problem so that one does not need to understand in great detail how gears work.

And I would like these tools to act like all the other tools for parametric design.  That one could go back and tweak the parameters and have the effects of the new parameters propagate through design.

My tools covered bevel gears, spiral gears, etc.  And helper functions are even more useful for these types of gears.  In fact, my dream is to understand and implement the tooth shapes for hypoid gears.

And Brian, I am thinking one can parameterize gear tooth profiles.  There are several papers on describing the involute curve using beziers, b-splines or one of the other polynomial curves.  These curves take fewer points and are actually more accurate than the piece-wise linear approach most often used.  And they can be defined parametrically and not as a series of programmatically generated points of the piece-wise linear approach.

I am just learning the API and have no where near the experience that I had with OpenSCAD.  Presently, I am not seeing clearly how one might create tools in the style of being part of a parametric design.  All the examples I see of scripts are more like macros than things that become a part of the whole parametric design.  Am I too ambitious? If not, do you have advice in where I might look for better examples?  One of the great things about OpenSCAD was that there was (is) a large number of examples that I could look at and learn from.  I haven't found that mother lode yet for the Fusion 360 API.

Thanks,

Steve

[sgraves]

@ekinsb

Brian,

Since I wrote the last post, I have done some investigating to see what has been suggested in the Ideastation.  I found this video from your design team from over three years ago.

It kind of takes away any motivation to work on this if a better solution is already in the works.  But, three years is a long time in today's world.  What is happening with this tool?  Is it dead?  Can I justify spending my time working on a gear design tool?

I think the proposal from three years ago would get a lot more votes but it is confusingly placed in the Ideastation.  It seems to be tied up with a bolt connection tool and it appears that the bolt connection tool is the proposal one is voting on..

Additionally, there are multiple requests for gearing tools in the Ideastation.  With separate proposals getting votes it dilutes the individual proposals and makes a gear tool seem to have less demand than it actually does.

Personally, I use gears a lot.  They are very handy for 3D printing of various gadgets.

Thanks,

Steve

[sgraves]

@ekinsb

Brian,

I have also seen that at least one of the gear design tool requests has been marked as implemented.  I think the manager who did that was using your spur gear script as justification for closing the request.  You and I both know that he is mistaken.  Is there a mechanism to appeal his decision?  A higher level authority or some kind of review board perhaps? 

I have worked for giant corporations (AT&T for one) and small ones as well.  In the giant corporations, management's lack of technical expertise and inability to defer to the ones with the expertise was frustrating. I can see that Autodesk has the same malady.  I understand that they have limited resources, but using techniques like this to ignore the demand for a tool is silly at best.  It is insulting to your customers.

Thanks,

Steve

PS  I see you as one of the people with the technical expertise that probably gets ignored by management.  We are clearly in this together. At least you are allowed to interact with customers.  Autodesk has done that right!

[ekinsb]

Thanks for your vote of confidence and I certainly understand your frustration.  I hadn't seen that video and don't know what's going on in that area.  I'm fairly certain that the work has been shelved while work is done on other projects deemed to be a higher priority.  Inventor supports something called "Design Accelerator" that is quite a few tools to automate the creation of geometry that fairly common in typical design, like bolted connections, spur gears, shafts, bearings, cams, etc.  The video is a port of some of the spur gear functionality.  It would be nice to have in Fusion.  The "Design Accelerator" functionality was written using Inventor's API but it would be difficult to port straight over to Fusion because of some basic differences between the two programs.  In some cases there is missing functionality in Fusion that it needs and in other cases there are just differences between the two programs that would take some effort to overcome.

The best thing to bring attention to this would be to create a new item in the IdeaStation and be fairly specific about the capabilities needed and pointing out the deficiencies of the current solution. If there are a lot of other customers interested in the capability it will get noticed.  If there isn't much interest by the community, resources will likely be used on other items that more people are requesting and interested in.

[Anonymous]

The 3 of us should sync up. I'm the author of the Helical Gear Generator add-in. I'm in the process of a heavy re-write. I'm at the point where I can create profile shifted gear pairs and I plan to push this to generating bevel gears, internal gears, helical gears (cuz re-write), internal helical gears and racks for all - all with profile shift / center distance adjustment support, addendum dedendum modifications and more. I'd love to take it to the point of generating gear-trains as well but that's a stretch 😉

I've crated a framework for making developing add-ins far less painful using python (I started this when i made my initial helical gear addin). I'm expanding it to enhance drawing (sketching) as well. I expect to be able to make gears pushing 1000 teeth with this version in "reasonable" time.

In any case if you guys want to team up on this or not I'm more than happy to share my code with you, or anyone who requests it for that matter.

And just so Brian E. doesn't feel left out, because I know you do what you can to help us all after all, with the new sweep feature supporting twisting (this is soooo awesome by the way) - helical gear generation just got really really easy - it's just some trivial math to convert the helix angle to a twist angle. Anyway, I think you could easily add support for some basic helical gears to the stock add-in/script. Just something to consider 

P.S. I totally found this post by accident - happy accidents!

[Anonymous]

This thread seems to describe the information that I thought was simply missing from the API docs. I am stunned to find out that there is no supported way for a user to go back and re-engage with the command UI to make changes? Is this still current information?

I cant really justify spending my free time working on add-ins for Fusion 360 until this is fixed because they wont meet my needs as a user. I really want to try and stay in Fusion because the CAM and Form tools are so valuable.

[Anonymous]

Hi! Any news on the topic? I recently stumbled upon Onshape's FeatureScript description and documentation (https://www.onshape.com/features/custom-features), and it seems they have a very powerful functionality there.

Is there any plan to move toward a unified API on which built-in features as well as custom ones are built?

In any case, is there a short term plan to support going back in the timeline and editing the result of a script by showing the script's UI? It is really a shame to have to delete the operation and start over each time.

Thanks,

Etienne

[Anonymous]

I created a request in idea station:
https://forums.autodesk.com/t5/fusion-360-ideastation/allow-add-ins-to-be-fully-parametric-and-repre...

AFAIK there is no plan to do anything to implement this.I read through the Fusion 360 API and I cant see a any way of doing this with what currently exists. There is no point writing a plugin if all it can really do is automate sketching and modeling commands.

I too have seen and used the OnShape API and it does what I want. In particular I want to do some very complex models using accurate Airfoils with lots of downstream geometry based on the airfoil plugin. I don't even want to think about how much work it would be to fix everything if I had to go back and re-make the airfoils without that capability.

On the other hand, OnShape just got bought out and we may find that they are less hobbyist friendly in the future. So ideally we would get this in Fusion.

[Anonymous]

I gave my vote to your request, even though I'm not terribly optimistic about this being implemented anytime soon. It seems like Onshape's FeatureScript was built to be the foundation of all the standard features in Onshape, and that user defined custom features are simply leveraging this powerful abstraction. I played with it for the past 2 weeks, and it is indeed very nice.

[OceanHydroAU]

It seems pretty simple to support parametric add-ins to me - Fusion 360 just needs to make another call to our command handler, sending us a copy of either:

a)the original input, plus whatever has changed (e.g. the chord length of an airfoil)

-or-

b)just the new input (our add-in can store its old input and output if it needs to know that for whatever reason)

I don't care if it's my job as the add-in author to remove what my add-in did earlier, and replace it with the new output, or, if fusion 360 "un does" what my add-in originally did, so I just have to run my work afresh (the second is of course way easier though).

[OceanHydroAU]

So - I've done a bunch more work on this, and this feature does appear to be already supported, albeit in a roundabout kind of way.

You can write command handlers to listen to almost anything:

# Check to see if they changed something (e.g. chord len or parameter) that would require us to re-compute any airfoils...
class CommandHandler(adsk.core.ApplicationCommandEventHandler):
    def __init__(self):
        super().__init__()
    def notify(self, args):
        global _ui
        try:
            # Possible things to watch...: FusionDragSketchCommand SketchEditDimensionCmdDef SketchDimension ChangeParameterCommand
            if _ui.activeCommand == ... :
                pass
                # Here, the change of UserParameters is checked.

So you just need to ensure that your add-in does it's job "properly" (has constraints, uses parameters, etc), then you listen for anything that might require you to do more work.  In my case, I've added extra data into user parameters so my add-in can remember what it did along with and a short-cut to where it needs to start working on changing stuff (specifically - in the comments part of the user parameters - a JSON string with the ID's of the constraints I'm using which I need to change to update to the new correct shape if the airfoil chord changes).

I also added metadata (add-in version numbers etc) so if in future I update my add-in, it will be able to look at what it's predecessor has done, and if needed update/improve on that too - so you not only get an "add-in code update", you also get an "add-in work update" - the ability for the updated add in to (after prompting the user) update the work it did in the past as well...

@Anonymous  @abz32ghkfusion