Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Community
- Creo+ and Creo Parametric
- 3D Part & Assembly Design
- Dynamic Sketches - VSS Discussion

Options

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

May 12, 2013
06:44 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 12, 2013
06:44 PM

Dynamic Sketches - VSS Discussion

For those of you who work with variable section sweeps, one of the options in the Sweep feature, you know just how finicky this command can be. The problem is two-fold; one - the trajpar statement in Relations has to be logical based on the trajectory type, and two - is the validity of the section though the full range of the variable parameter.

For case one: The trajpar... or trajectory parameter, is simply a value. Yet, it depends on the type of trajectory selected to know how to formulate the *trajpar* statement in Relations. The variable *trajpar* is simply a value from 0 to 1. Rules for using *trajpar *is different depending on the type of trajectory is selected. All trajectories yield a value of 0 at the beginning and 1 at the end. Logical enough. This simply means that -along the trajectory- the value increases linearly from 0 to 1 depending on how far along the chosen trajectory the sketch has "evolved". This is a very simple rule to follow for open trajectories. The variable *trajpar *can be used in any valid formula in the Relations of the VSS sketch in which it is called. However! when you choose a closed trajectory, things seem to change. Many trajpar statements seem to fail. Consider a simple vertical line swept along a circle. You add the statement "d(n)=1+trajpar", you would expect the line to sweep along the circle and increase from length 1 to length 2 from the beginning to the end of the circle. For some reason this is not logical to the programmers because the ends would not meet seamlessly. So you might consider the trajpar statement -requires- the end condition to be the same as the beginning in the case of closed trajectories. This is most often resolved by using sine curves to ensure the end condition of the profile sketch is equal to the beginning.

For case two: Sketch validity is much more problematic. Just as when you drag a sketch, the Solver seems to suddenly suffer brain-freeze at the most peculiar times. The Solver finds two solutions, or a paradox in the evaluation. Lines jump from one side to the other; they inverse; circles become zero, or worse, infinity. Angles simply reverse geometries at 180 degrees. Something should really be done about this in Sketcher but for the time being, we have to outwit the Solver. This is not easy, but we must manage if we wish to have solid and reliable variable section sweeps. Ambiguity is simply not allowed! As for rules, the Relation statement using *trajpar -*cannot- allow values to go negative. Whatever you use the range 0 - 1 for, it -must always- return a positive value or zero. Yes, zero is allowed! Line length=zero is allowed; angle=zero is allowed; Even circles can ...=zero! But in no instance does a negative value work. It simply fails the sweep feature. There does seem to be a special case for resulting angles. When an angle exceeds 360 degrees in a sketch, the Solver will return a value between 0 and 360. This is true, for instance, when you drag a line around past 360 degrees using an unlocked angle dimension in a sketch. Yet, in Relations as a trajpar statement, you can exceed 360 degrees as a value and it will continue to whatever value you set when more than a full rotation becomes the result. You just have to remember rule #1: "...the end condition must be the same as the beginning in closed trajectories".

For further investigation on how to manage trajectory parameter values is to convert the generic *trajpar *0 - 1 to a sine curve value. You will see it over and over again in VSS applications. The basic syntax will be "cos(trajpar*360)". Using this statement, instead of the resulting value being a linear "0 to 1", the result is now a sine wave 90 degrees out of phase, or correctly stated, a cosine wave starting with the value of "+1" at 0 degrees, becomes "0" at 90 degrees (1/4 along the trajectory), is "-1" at 180 degrees (50% along the trajectory), "0" again at 75%, 3/4 along, or 270 degrees. and finally ends at "+1" again at the end of the trajectory. And this is key, it begins and ends with the same value, which seems to be required for all closed loop VSS. Therefore, you now have a non-linear curve with a value from 1 to -1 and back to 1. The only real difference between the cos() vs sin() is that the cosine will provide tangency at the start position of the trajectory. Practically, however, sin() and cos() are interchangeable if you know the ramifications.

The following examples show how a closed trajectory can use cos() statements to provide common sketch variable control. These also prove that zero length lines and zero diameter circles are permitted.

A line with variable length: sd3=1+cos(trajpar*360) - the value statement "1+" is to ensure no negative value exists. The value of cos(trajpar*360) is +1 to -1 and back to +1 (90 degree ofset sine wave). So the line is 2 long at the start; 0 long at 50% along the trajectory; and back to 2 at the end.

A circle with a variable diameter: As in the line above, the circle diameter is 2 to 0 to 2 again.

Revolving a line along a closed trajectory is little more complex, apparently. The reason for this is not immediately apparent. In this case, the value range is 1 to -1 and not back to 1 (half the cosine wave). Also, the full range -must- convert to "360" or multiples there-of. The same "1+..." statement is to convert the value range from 2 to 0 (all positive or zero). The "...*180" makes the value range 0 to 360. But also notice the "cos(trajpar*180)". In this instance, we only want one direction of rotation from 360 to 0. This is the special condition where 360=0 and therefore abides by the basic rule #1; the end condition must be the same as the beginning. Any other value in this statement that does not result in a value following rule #1 -will- fail. However, this particular closed loop with a revolving section does not require a sine function. In fact, you can revolve the line linearly using "d(n)=trajpar*360". Again, for the very reason that this range of 0 degrees to 360 degrees create the same end condition as the start condition. Try replacing "...360" with "d(n)=trajpar*(360*20)" in the Relation for multiple loops around the trajectory path similar to the next example.

of course, these are simplified examples but the power of these equations should be self-evident. The following examples show that angles with values greater than 360 are allowed: sd9=trajpar*720...

In this instance, the open trajectory uses "trajpar" directly using the value 0 to 1. sd9 is an angle dimension where at the start of the trajectory "0*720=0" and at the end, "1*720=720". This creates 2 full rotations of the line defined by sd8. Now see what happens is you replace this with a curve function by replacing the sd9 statement with "sd9=(1+cos(trajpar*180))*360". Notice how the ends are now beautifully tangent to a horizontal plane.

There are endless solutions that can create some very specialized section geometry, not to mention the multitude of applicable trajectories. Here is another way to remove the "-1" aspect of the sine wave. In the case - sd3=abs(cos(trajpar*720)) ...includes 2 cosine waves with all the negative values inversed with the abs() function. Again, zero is encountered 4 times.

Of course, none of this means anything if you followed the rules; you know there is no negative value in the equation; you know the ends of the closed trajectory have the same condition at the beginning as at the end; and you know that all trajpar statements were used in accordance with the rules, and it still fails. Next you have to look at what your sketch is doing at the various values. I cannot tell you the level of frustration I have with the Solver. Even static sketches can really test us, but when the sketch becomes dynamic, all manner of strange incarnations tend to occur, many of which could even crash your session. Fortunately, when you define a VSS, the system evaluates the sketch throughout the range of the *trajpar *variable before it "casts it in concrete". Even if the Relation statement passes mustard, that is no guarantee that the VSS Sweep will accept it. -If- you get a preview that looks like it has followed a variable section, you are in luck. You did something right!

Test you sections. Replace the variable with values that you know it will encounter. Suspend the Relation and drag the sketch to check it for robustness (lock the other dimensions 1st!). If nothing else, you will learn if your sketch is robust enough to handle the manipulation. I'm willing to put forth the statement that rotational aspects along a trajectory will be the least stable in any given sketch. It is my hope that the observations above will provide a better understanding of VSS and the *trajpar* variable do.

*If you find this document useful, please remember to rate and like this.*

Thanks, and may your VSS work for you.

6 REPLIES 6

May 13, 2013
12:09 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 13, 2013
12:09 AM

Ok Antonius,

I bow to your superior knowledge. I have used most of these aspects over several years and often with the frustrations you mention. Most of my issues have to do with "robust sketches"; what is great for ordinary sketches is often not appropriate for VSS sketches that change the section along the trajectory. Often it was silly things like the automatic horizontal or vertical constraints but most of the constraints can be an issue around the trajectory without a lot of care.

Not sure how to vote on this but it is by far the most comprehensive work I have seen in this area.

Regards, Brent

May 13, 2013
01:47 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 13, 2013
01:47 AM

Thank you, Brent. Obviously I am not a Facebook fan... "Like" is what I meant

I give much credit to our Frank for really pushing the bounds of trajpar. Even 6 months ago it was a taboo feature that just kept calling. Then I started actually using it but not before I hit my geometry and algebra books again along with some work on the motor curves.

Of course, the second part of this discussion is at the heart of the VSS power is the sketches used with guide curves. These sketches too are dynamic and deserve a document of their own. Yet, any learning of one will help guide the other.

I did add an update as I realized that you can use angle trajectory parameters without a sine/cosine function on a closed trajectory path. A linear whirling of a line around the trajectory path is perfectly all right as long as it ends where it began. Just thought it was worth noting considering I did it here earlier today:

May 16, 2013
04:55 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 16, 2013
04:55 PM

this is beautiful.thanks a lot for this beautiful post.

i was having a trouble creating a "star" asked on this forum and wasn't able to recreate it.it was after several tries,my sketches were locked as soon as modified,due to config.pro settings.so locked dimensions doesn't work,only strong and weak dimensions for adding relations

just want to confirm one more thing and hopefully a post from you lol about it, sorry ,when sketching in (after selecting trajectory) vss,x-direction is always right side,y-direction is up and z-direction is looking through the screen at the user,just want to get my head around this.

May 16, 2013
05:12 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 16, 2013
05:12 PM

Thanks, I am glad the information is of use to others.

I too lock dimensions by default but once you assign that dimension to the sketch relations, it converts to strong. Other dimensions, however need to be weak; not locked, if they must vary. As for the strong dimensions, I suspect they need to remain constant.

As for X, yes, that is the default section X-Y. So if you lock X-direction to something else, the section orientation could change. Z would be along the trajectory opposite the trajectory direction (Z doesn't really matter in this case).

Beware, however, that the X-direction along a curve is defined by the curve itself. All too often I find the curve has a twist or something that changes the expected results. Guide curves or locking the x-direction are good ways around this, but sometimes it is easier to manage the original curve feature. For instance, a wrapped curve will maintain a constant X-direction where a curve curve with Z-changes in a spiral or circle will change angle the X-direction along the trajectory. I recommend you always test your results to make sure it did what you thought it did. You can use the analysis tools for viewing curve and edge characteristics.

May 17, 2013
01:55 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

May 17, 2013
01:55 PM

I added an image to the tips photo album that seems appropriate here.

Sometimes a pure sine wave is less than optimum. Here is a simple way to change the cos(trajpar) statement to get some interesting results: Note the inverse using "-1" and even raised powers (red) change the range from +/-1 to 0-1. This is useful for motor profiles and datum curve equations also.

I know the math guys know all this, but it is certainly worth posting in this discussion.

Jun 12, 2013
12:42 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator

Jun 12, 2013
12:42 PM

I learned something new about trajpar in a sweep section. It appears to be a special case.

Before I mentioned that a trajpar cannot go negative. For the most part, this is true. The special case is where a line is swept along a spline, 2D or 3D.

This special case appears to still be limited as the line cannot be zero length at the start, but it can cross over itself (reverse) along the trajectory.

Essentially, you can create a sweep sketch with a line with the midpoint at the origin (for instance). You can give the line a length with the following relation: sd(n)=cos(trajpar*360)

This will vary the line from 1 to -1 and back to 1.

Strange but true