Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Comments
So I've read all that I could and watched all the videos about polyline creation. I'm working on a plumbing project and trying to make "route curve" parametric.
Notes:
-The "polyline" stores x,y,x locations for points. There are no angles involved.
-At each point, it does remember the orientation of the manipulator.
-The relationship between a point, manipulator & mate connect is weird.
It seems odd that the inputs are called vertex and everywhere else they're called points, I'll call them points:
At each point, the manipulator orientation is remembered. Rotating the manipulator is an unknown value and not sure it's useful. I hope someone can explain why this is needed:
"add point on drag" doesn't work if the you've rotated the triad. I usually just reset it and then leave it alone. You can see below it didn't add a point:
Referencing other points is hard. "relative to previous point" works well. I'm at point 1 so I know I'm working at the beginning of route. Notice that it says "mate connector" for the reference. Notice that the point is highlighted and picking it will change the focus to point 0. When assigning a reference for a point, you can not pick any other points. The change focus overrides your wishes. You always have to pick a mate connector or an external point for a reference, never a point in your route. Notice the point is highlighted and picking it changes to point 0:
Highlighting the mate connector will allow you to reassign the reference to the start. You could have easily used "relative to previous point" which is usually the preferred referencing scheme. With this approach, all subsequents points are relative to each other and update in a meaningful way:
This comes up a lot "part of a mate connector" as a reference. I think this should be removed and changed to the mate connector in it's entirety:
The "previous reference" below is wrong and needs to be assigned to the end point. This is how the route was created. Defining the end of a route is always more challenging. Below is the way the route was built:
I change the reference to the mate connector defining the end of the route. Notice it's just "part of mate connector". It's the point of a mate connector. Below the offset is based on the last point or the "to" of the route. In all your routes, you have to deal with a "from" and a "to". The "to" is not easy in "route curve":
So the simple routing above is parametric and will update correctly all day long with any change that'll come along.
So let's break it.
It's not hard to break the parametrics in "route curve". Let's remove the diagonal tube and route using ortho path. There are 3 choices, and I want the fewest bends, I choose a path which extends the starting offset:
"curve reference"
The world coordinate system is probably the worse system to use. A better approach is to use "curve reference" which establishes all orientations for points. Another way is to be careful and select point 0 correctly. When you have many routes, you'll learn to define a coordinate before starting a route.
This is the cleanest looking plumbing when everything is in alignment:
Make a change, I don't think "route curve" will ever be parametric.
A quick fix, delete the errored point:
And do it again:
If you figure out how to make this more parametric, please let me know.
I want to start using the Button Parameter in a feature I just made for woodworking but can't seem to find any documentation on it other then a little note in editing logic function section:
The final button is missing from CPC.
If you're serious about good surface modeling, you'll eventually end up following those rules since it's the only way to achieve good surface quality and final model. 🙂
When I first learned about them in the university (while working in Alias) I thought I could live without them and do things on my own. It didn't take long and I got back to them, study and understand them. You're not able to produce good surface from terrible inputs as I initially thought. 😁
I agree, and I did end up following them. but seeing them made explicit and how to work around challenges (e.g. if your surface isn't four sided) is very helpful. I was never taught surface modeling well. I've just learn't it over time.
Another update today! In this version we ensure that arbitrary periodic curves can now be processed and their degree can be elevated/decreased. I know this issue came up early in some folk's testing, so hopefully you can try it out again on those use cases.
Today's version:
https://cad.onshape.com/documents/2c2c376d9979115f9f969a08/v/8d24d6dd5f7ac9587f5d4220/e/929d02bbbb5f71c6176ac653
Hmmm. I had this 3D curve (degree 9, 9 spans, closed):
I hit elevate once, and it comes up with this:
This is not what I would expect.
I was able to approximate/process a sketched circle and get something useful, but again, elevation is strange.
Hit elevate once and we get degree 9 with 8 spans:
Here's what I would hope to see when elevating a degree 8, 2 span closed curve (this was done by changing the approximate/process parameters):
[edit to add this bug:]
I'm also noticing that if I approximate/process and change the degree and number of points the resulting degree is adjusted correctly, but the resulting number of spans gets stuck.
I tried approximate/processing a sketch which is a 180-degree arc and a half-ellipse. The resultant control point arrangement is not exactly what one would hope to see, and the curvature combs are not symmetric like the input curves.
Here I tried reference edges which are two degree 7 Bridging curves (in a symmetric arrangement). Through trial and error, I found that approximate/process to degree 8 with 16 points got the closest without adding too much wobble, but it's still far from the underlying curves.
I can understand how the previous test with an arc and elliptical arc was challenging due to them only being G1, but this arrangement of inputs is G3. The result does seem to be symmetric, which is good, but the zig-zagging of the control points is not ideal.
Control over the angle of the manipulator is a must.
Now that Control point curve is getting better at creating closed curves, Boundary surface's inability to handle closed curves is more frustrating. Clean closed curves are more useful if you can use them to create clean surfaces. Right now you have to split closed curves in order to use Boundary instead of Loft (which turns everything into multi-span degree 3 curves).
Please vote for this improvement request.
What an amazing job ! Thanks !
In the particular case of piping and tubing (or electrical routings), how would it be possible to add a parameter to keep automatically a given distance from the environment ? I don't even know if it's possible…
This may be a small quibble, but I've noticed that control point curve is static once processed. I'm using it to create an approximated spline through a number of edges in a configured design. When I update the configuration, the location of the seed edges change, but the Control curve output does not (until I manually edit the feature and re-process). There are ways around this problem (3D Fit Spline, creating a small/simple approximate spline FS), but It'd be great if Control point curve would update dynamically to take upstream model changes into account.
It's been some time since the last update. I've been trying to use CP curve for a real project, but the fact that "Process" is not parametric and I need to edit the curve each time the underlying edge changes makes it not really useable.
With more use, I'm also thinking that having a choice of a "point reference" that is local to the curve, but scales as the chord changes (à la Mutate Curve) would be really nice. Full NUV and/or slide (along the control polygon) movements would be nice, but just to start, it would be great to have the reference be the mid-point of the chord and the average plane through the rest of the CPs.
did someone say Mutate?😀
also, check out my latest script, you may find it useful: https://cad.onshape.com/documents/0c9c1d6da0265651452fb454/w/a19d49c88c42cd1c1f7eecaf/e/511d2a5d9fc7bf0b9382fa4c
For editing curves created with this, could we have Next point and Previous point buttons so we can work within the UI window, an not have to select points with the mouse?
@GregBrown
I've been using routing curve as a centerline/skeleton model. The centerline is created in its own document, then derived into a part studio to build off. When referencing the vertex of the routing curve in my model new constrains immediately get added and labeled as "Some external references are missing" This seems to only be a problem while referencing a vertex. I am able to add dimensions from sketch entities to routing curve curve (line) itself.
I entered support ticket 362847 as I wasn't sure it was related, but now I think it is, hence the post here.
@GregBrown That's indeed a great work. But the triad should also have angle reference. I didnt see any angle can be driven parametrically here.
Just another quick inquiry- Does onshape have any variable pitch helix?
Check out the "variable helix" FS from CADsharp:
https://cad.onshape.com/documents/692c433abc951800d638d840/w/0514acf79f73292acbd70beb/e/e53677c83586a66ee9d01961?renderMode=0&tangentEdgeStyle=1&uiState=67292971cac6610c096e9d61
Thank you @eric_pesty
I've been working on this problem for about 2 years and have finally succumbed to a simple solution.
Solutions tried:
-morgon's piping script, it's public
-routing curve the script featured here
-routing the script I wrote
-stupidly simple
Morgon's script is pretty old code but is an amazing piece of work. I do like that a route is defined by a start and end. Routing curve, the one featured in this post, is a great attempt showing a lot of potential. Routing, the one I wrote, looks the simplist of all these but it would only work for 80% of my use cases. And, the problem is, while I could figure out solutions for many routes, no one could ever figure out what made them work.
My script interface. Start and end how simple is that?
This is when I gave up writing a routing script:
180 degree bend and the fs polyline function requires a strait halve way through the bend. Ok, I'm done.
The solution I've been using, the simplist is the following. I'm working in an assembly and I want to connect the 2 elbows:
I'm in a partstudio from the assembly and create a sketch defining the orthogonality of my route.
I create 3 planes:
I sketch on 3 planes. I know, it's ugly:
The rest is trivial:
Back to the assembly and I make a change, actually I make millions of changes:
It updates!
I know it's ugly, but it works 100% of the time. I do keep all of the components of a route inside a folder for tidiness and I've converted all my old routes to this simple style. I'm not saying that a fs for routing is a bad idea, it didn't work for me.
My biggest fear when designing is to create something no one can follow. These single feature routes can be impossible maintain or debug. When you have a parametric project and someone starts to deleting stuff, it'll kill the project and the model you created.
I'm happy and have all my routings controlled inside an assembly.
As a side note, I can now fill a computer rack with beer in less than a minute.
Chris, sounds like your "route curve" parametrics are held together with duct tape and hope
Two years of battle for a solution that’s ugly but works? Chris, you’ve just invented the engineering mantra
yeap, kiss
It was a fun journey and I learned a lot. As an old engineer, not everything works out and that's ok.
It turns out you can't fillet curves from the standard interface so this weekend I a FS called fillet curve. It'll take a trajectory and fillets (bends in this case):
The end result now looks like this: