Without actually seeing the model, it's hard to tell exactly the geometry needed. Are those "hard" sections, that have to be used? The method I'd try then would be: You COULD create datum curves thru all the sections endpoints, with tangency conditions at the ends where it joined the pther protrusions shown, then use one of the 6 curves as the VSS spine and use the other 5 to control the section continuously. Then the VSS WOULD go thru all the endpoints, though the sections themselves might not be exactly perfect because of the difference in "timing" (length) of the different curves.
Think of the graph as the "X" value being the length of the trajectory spine, (made equal via the evaluate feature - love those! - so it's parametric) and with every "Y" value of th egraph being continuously put into the VSS section by the section relation. The "X" value of the hard points in the graph directly correspond to the datum points (the "X" value on the spine) I put on the trajectory spine, via relations, but the "Y" value (angle) can be changed in the graph (and relations added to them, etc.). All the relations make sure that as long as that spine length is, the graph "X" length always is equal to that so you don't "run out of graph". Meaning you don't get the full "Y" values of the graph at the right end - sometimes you actually WANT do do this, but I digress....
Did you play with dragging the points dynamically? That was pretty cool! Too bad you can;t drag the graph....
Why not just copy the surfs from your customer's model as a copy geom, etc.? Or does it need to be parametric.
Even though the method you showed was ingenious it wouldn't work in the application I am using. Each section has squeezes, dives and tilts that can be different from section to section. Variations are in X, Y and Z. Datums are tilted. All 6 walls of the sections are independently twisted and positions of the rails vary up and down in X and Y.
I do like how easy it is to change sections positionally within the sweep you created. I finally understand the graph. I didn't realize you could chart distance as an angle. I'm baffled how you put your influence sections after the sweep. I don't see anything inside the sweep creation that allows for the graph inclusion.
The reason we have to build separate models is because the preforms in our dies have to have additional draft. These preform shapes also have to have less detail than the finished part impression.
Our work is for a crude process, but because of the constraints required within this process it makes the creation of part models very difficult. We have to have draft, strange locks and radii going from everything to everything.
Yeah, I thought it might not. Like i said, you might be able to do it with the spine and 5 other trajectories, depends on the blend needed between sections. It would probably smooth it all out better than the independent sections.
The sections at the end do NOt influence the VSS, I put them there so you could see that the datum points and graph forced the correct angle at a plane normal to the spine thru those points. So you could "check" and see what was going on, they have nothing to do with the creation of the VSS, being after it in the model tree.
A graph can drive ANY dimension I know of in a section. You must include the graph in the SECTION relations, via trajpar.
Well, here's one, how about make both ends as shown, and do boundary blends, eact quilt having a curvature continuous or at least tangency to the previous section, and the last one having those conditions to BOTH ends? I think that would probably smooth things out, and still give you EXACTLY the sections you need. Try that.
And if not, now you'd had a lesson in evaluate and graph features!
I am using a extrudes as adjoining surfaces that launch good tangency for the rails.
The rails are either datum curve or ISDX. They start and end at the extrudes with tangency. In between they connect with edge points on corresponding edges of the sections to shape the rails.
I do use Boundary blend to fill out the skeleton frame. I like how it gives me a fully enclosed sidewall. I love how I can tweak the curves and it will parametrically update. This is the 1st time I've ever fully done a part with parametrics. The only thing I couldn't figure out was how to tweak the sidewall draft on just one feature to fully update the rest.
Yes, I really appreciate your primer on using Trajpar and other features related to VSS.
I wish they didn't get rid of the helpful points on this forum as you have helped a lot.
I realize this is a late reply, and hopefully it doesn't muddy the water too much....
Something to try. Create two top level parameters, one for the starting angle and one for the increase increment.
CURRENT_ANGLE = 10 (or whatever)
INCREMENT_ANGLE = 1
Next, create a relation statement in the first feature to initialize the starting angle: CURRENT_ANGLE = 10 (or whatever)
Next, add the exact same statement to each successive feature to increment the angle: CURRENT_ANGLE = CURRENT_ANGLE + INCREMENT_ANGLE
Also add a feature specific statement to drive each feature using the current angle. For example: d45 = CURRENT_ANGLE
You will probably get Creo complaining about some features being out of date (because the value changes on every regen.), but it should work.
Don't worry about muddying the waters. I'm past the stage where I will change what I have done, but I still would like to know whether a relational statement could easily provide a parametric solution. I'll have plenty opportunities to put this into effect.
Your idea is similar to what I thought should work.
I'm not sure this can be done any different but the one thing that scares me (and I did observe this) is whenever you have a condition on the left of the equal sign (Current_Angle) and have the same condition on the right side of the equation (Current_Angle) + Increment_Angle it would cause an increment up every time the model was regenerated.
Also, perhaps I'm wanting too much but the other inconvenient side of this is that you would have to repeat the equation correctly for 56 instances. I was just hoping that relations could snag a common name tag and repeat the pattern with anything with that string of characters.
With those 2 problems aside this would work excellent.