CircularPatternConstraint

[sgraves]

The CircularPatternConstraint was added in Mar 2016.  So far it appears to be orphaned with no way to use it.

Is there a way to use it that I am missing?  If not when will it be adopted by a loving parentSketch?

[ekinsb · Accepted solution]

The CircularPatternConstraint is currently only partially implemented.  A partial implementation was done so that if you have an sketch that contains a circular pattern constraint and use the API to iterate through the GeometricConstraints collection we have an API object that can be returned for that object.  The returned CircularPatternConstraint does't let you do much expect to know there is a circular pattern constraint and delete it.  You'll also notice that there's not a addCircularPattern method on the GeometricConstraints collection so it's not currently possible to create one with the API. It's something we need to still do.

[Anonymous]

---

@ekinsb wrote:

It's something we need to still do.

---

Hate to necro an old thread, but is this still the case?  I just ran into the API entry trying to implement this, and hit a brick wall.

[BrianEkins]

There hasn't been any work done in this area since my last post.

[sgraves]

I still need this functionality.  Why is it not important?

Here is why it is useful.  There is no way to parametrically rotate a set of sketch curves.  This could be done using an angle type of CircularPatternConstraint.  I want to create components with the API that are parametric.  Then they can be tweaked by the user. 

For example, a gear that has user parameters.  In this example, changing the number of teeth parameter would result in a different angle for the involute curve that defines a tooth.  Rotating that involute curve parametrically would allow the user to change a gear in place.  The present methods of creating gears with the API do not use parameters and create a one off gear.  To change a gear one must create a completely new gear.

If there is another way to parametrically rotate a set of sketch curves, please let me know.  Presently I am drawing construction lines from the center point to every point in the curves, setting an angle dimension for every line to a fixed construction line then parameterizing those angle dimensions to rotate the curves.  Very, very messy way to do this.

https://www.timeanddate.com/date/workdays.html?d1=08&m1=06&y1=2017&d2=29&m2=2&y2=2020&ti=on&

[william-c-anderson]

In my experience (in both F360 and DS S*works), circular patterns are better done in feature space rather than sketches, because both tools allow much better after-the-fact editing of patterns in feature space rather than sketch space. It would seem that the API for feature patterns is much better than in sketch space, per my reading of the documentation.

This doesn't solve your general problem (i.e. CircularPatternConstraints in a sketch), but in the case of gears, all of gear implementations I've seen use the "patterned notch" method:

1. Draw the involute and root curves at the proper radius and offset from the x-axis (in the case of F360, you would want to have key parameters, like module, Nteeth, pressure angle, etc in the User Parameters)
2. Mirror the curves across the x-axis.
3. Draw a circle connecting to the tip and an arc between the dedendum points. Your sketch is now complete.
4. Extrude the (complete) outer circle.
5. Cut the notch.
6. Add goodies like fillets if your root curve needs them.
7. Do a *feature* circular pattern of the modified notch, using the Nteeth User Parameter.

This is basically how the F360 SpurGear add-in works, though to my eye the gear curve code therein seems very complex (no offense intended to @BrianEkins , the implementer of that code). All of the above could be implemented in a fairly straightforward fashion in API code, I'm pretty sure. It helps to have good equations for the involute tooth and trochoidal root curves (depending upon your desire for accuracy and the intended method for cutting the gear).

I also need to add that when changing parameters and moving a spline that is parametrically-generated, you will need to disable, then re-enable all the constraints associated with that spline. This is not trivial. It is a battle-of-wills with the sketch solver, which definitely does not let a user move an otherwise-unconstrained SketchPoint anywhere he chooses.

Hope this helps, and YMMV...

[william-c-anderson]

Previously,

---

@william-c-anderson wrote:

I also need to add that when changing parameters and moving a spline that is parametrically-generated, you will need to disable, then re-enable all the constraints associated with that spline.

This is not entirely correct. Only certain constraints cause problems with SketchPoint moves in splines. Any coincident constraint with a circle / arc will have to be disabled, then re-enabled, because the sketch solver does a very poor job with circular arcs, for some reason. Most, if not all, other coincident constraints will move nicely with the SketchPoint. Other constraints (e.g. symmetry) can and should be left alone. Best of luck!

[sgraves]

You have described a way to generate a gear using the API.  I want to generate a gear component that has user parameters that can be changed without the API.  I have accomplished this, but it has taken some kludgy mechanisms to have parametric operations.  It is frustrating that Autodesk seems to not consider making operations that are parametric available to the API.  Why wouldn't you want to create parametric designs with the API?  That is one of the powerful functions of modern CAD systems.  It is how I use Fusion 360.  I want to tweak my gear in situ by changing parameters.  I don't want to go back to the API and generate a whole new gear.  I don't design that way. Why should I write programs to make things that aren't parametric?

Even worse, I suspect that Autodesk has abandoned the API.  It appears that there is no work being done on it.  If you look through the documentation there don't seem to be any recent dates in the Version line.  And with each update I look for mention of API changes and there don't seem to be any.

BTW I found a better way to handle a parametric involute curve.  I have added a horizontal and vertical dimension to each point in the spline that describes the involute curve.  Those dimensions are parametric, if I change the user parameter for the number of teeth my gear component changes as needed without invoking the API.  In fact, I can change any of the parameters that describe my gear and it changes based on the new parameter without invoking the API.

[william-c-anderson]

---

@sgraves wrote:

You have described a way to generate a gear using the API.  I want to generate a gear component that has user parameters that can be changed without the API.

Actually, my intent was to describe what a program would do to automatically generate a gear without any more input than the critical parameters (module, Nteeth, pressure angle, etc). The description could easily be implemented in Python to build the gear.

---

@sgraves wrote:

BTW I found a better way to handle a parametric involute curve.  I have added a horizontal and vertical dimension to each point in the spline that describes the involute curve.  Those dimensions are parametric, if I change the user parameter for the number of teeth my gear component changes as needed without invoking the API.  In fact, I can change any of the parameters that describe my gear and it changes based on the new parameter without invoking the API.

---

Yep, this is how it should be done, for sure. Good old "x = R*cos(t) + t*R*sin(t)" kind of stuff. The involute is interesting, but the trochoidal base curve (which is cut with the very bottom of the hob's tooth) is more challenging to figure out, especially if you want to do profile shifting. If you have any references on gear profiles produced by power skiving, I'm all ears 😉