Any potential for FS seeded sketches?

traveler_hauptman

It would be nice to be able to have FS created sketches be editable.

There's a couple of levels of this that would fit with how Onshape currently works (If I understand correctly).

Level 1 would be to allow editing of constraint dimensions in FS created scripts. The user cannot add or delete sketch elements.

Level 2 would be to allow FS sketches to have a read-only seed geometry and be otherwise fully editable. Geometry could be appended and modified at will.

The use case of Level 1 is to allow the user to modify feature parameters in context and avoid an overly complex definition dialog.

The use case of level 2 is to allow a custom feature to generate complex or table based geometry that the user could build on.

Thoughts? Useful for anyone else?

ilya_baran

This sounds useful, but I don't think we can do this soon.  Level 1 is much easier -- the way I think we would do this is to have a dimension-as-manipulator: just like a feature can expose manipulators today, we would have a new manipulator type that looks like an editable dimension.  For Level 2, I don't a see a way that would avoid turning some of the system inside out -- the workaround for the time being is to build on the complex geometry in a separate sketch.

traveler_hauptman

ilya_baran said:

  For Level 2, I don't a see a way that would avoid turning some of the system inside out -- the workaround for the time being is to build on the complex geometry in a separate sketch.

Apart from allowing the user control of a feature via geometry information, the solver is the useful element, so separate sketches would not work.

I think I see what you mean by needing to turn some parts inside out (I'm making a lot of guesses about how you manage feature data and the FS evaluation internally).

Best I can think of with my limited view is allow an 'InternalSketch' function for each feature that takes the feature definition map as input returns a sketch object. If defined then a top-level sketch function is created that builds on that.

const FYfUDGqfsEcUVVL_1 = function(id)
        {
            if (true)
            {
                <Feature queries>

                <sketch initial guess>

                annotation { "Internal Sketch Name": "My Features 1" }
                var sketch = ZVfJRFRANDAcHb::myInternalSketch(context, id + "OTMEIOFHEHOT_0", { "axis" : qUnion([qkreyyDYIxTiDz_query]), "reference" : qUnion([ymjWqoIxGZFgSB_query]), "dist" : try(4 * millimeter) });

                <elements generated from user edited sketch>

                skSetInitialGuess(sketch, initialGuessFPTUkUZ3QoBDILw_0);
                skSolve(sketch);

                annotation { "Feature Name" : "My Features 1" }
                ZVfJRFRANDAcHb::myFeature(context, id + "FYfUDGqfsEcUVVL_1", { "axis" : qUnion([qkreyyDYIxTiDz_query]), "reference" : qUnion([ymjWqoIxGZFgSB_query]), "dist" : try(4 * millimeter) });
            }
        };

I don't know what the round-trip between sketch editor and internal representation looks like so I have no idea how difficult it would be to pre-populate a sketch with the contents of *myInternalSketch* for the user editing phase.

Just musing on the possibilities out loud here. I prefer you make progress on the next feature rather than reply to this

ilya_baran

This is interesting -- we could in principle generate part studio code like this, but I'd like to understand the use case better.  You don't want a separate sketch because you want myInternalSketch to return complicated *flexible* geometry?  And do I understand correctly that myFeature is part of the same feature, rather than separate is to share the definition?   Do you have an example of the type of thing you'd do with this?

traveler_hauptman

Yes to all your questions.

What I want is allow the user to easily (and interactively) provide geometry information to a feature. The sketch editor interface is in essence a big dialog for gathering geometry information from the user.

Seeding the sketch with an initial set of geometry is needed for exactly the same reason the definition dialogs aren't just a blank text box. It's not that you can't parse the contents of the text box... it's that you want to hint to the user what info is relevant to this feature.

And you want the information seeded into a sketch to be relevant to the definition of the feature, hence using the features definition map.

myFeature *is* the feature. I'm inferring that the Onshape sketch editor can't work inside FS code from your 'inside out' comment. myInternalSketch would best live inside myFeature (with myFeatures' definition) but to make it manipulable by the sketch editor we need to bring it out to the 'top level'. Having the same definition eliminates the need to juggle two definition dialogs (and the heuristics of how to parse two precondition blocks). I'm assuming the top level is in some non-featurescript representation.

A trivial use case is a 'hex broach' feature that seeds a hexagon fully constrained such that it can be rotated and translated but remain a hexagon. When the user edits the feature, they can constrain the center point and add a dimension.

There is a big limitation in the easy implementation of this. The sketch editor is probably state based rather than an operations list and has no 'modify' primitives. EG modify the value of constraint x, delete LineSegment y.

So one could not pre-populate dimensions for editing or expect the user to remove an unwanted portion of the seed sketch.

An additional quirk of the easy implementation would be that a user could delete seed geometry in the sketch editor and it would reappear as soon as they closed the editor or the editor refreshed.

Even with these issues, I still think it would be useful. Incremental changes could probably eventually resolve the issues.

traveler_hauptman

Another use case that I was dealing with yesterday in creo. (I've been away from Onshape so not sure this could be done another way.)

I needed to project points from a source plane to sketch plane, along the normal of the source plane. I created axis datums for each point and then constrained points in the destination sketch to the pierce location of the axis.

I could use FS sketch seeding to project points from another plane, along that planes normal, onto the plane the user is editing. I'd then be able to edit and use that seeded sketch.

In this case myFeature would have no operations in it. Only myInternalSketch.

ilya_baran

The first case is very interesting -- basically IIUC, you want to use sketch constraints to position and possibly flex predefined sketch input into a feature.  I don't see why the second case needs sketch seeding though, since the projected points don't need a constraint solver.  In any case, this takes some time to digest -- working on the next feature for now

traveler_hauptman

@ilya_baran Yeah, I guess there is no advantage for the second case over just having a 'projection' feature and opening a fresh, normal sketch that uses the output of that feature.

traveler_hauptman

If this capability was available I would use it to create a component positioning solver.

In mechanical design one is constantly using pre-existing components (things that you can't change the geometry of) and integrating them into a complete design. Where the components are placed depends on the design goals and structure. Where the structure is placed depends on the position and shape of the components.

In all the CAD I've seen (limited to SW and Creo) this circular relationship is managed manually and iteratively. However this is exactly the type of problem that a geometric solver can (and should) deal with.

I usually choose to transpose the relevant component geometry by hand into a sketch and then use the sketch solver to manage the circular relationship. This is better than not using the solver, but the manual portion (transposing geometry) is still error prone; especially in the early phases when components are being changed often in search of the best design. For example, if I'm positioning two bearings, I'll draw the cross section of the bearings and their axis in the sketch and then use constraints to shape the structural geometry I'm creating as needed.

It would be better if I could import components into my part-studio, specify the sections, faces, or silhouettes that I want to work with (1 per component), and have a sketch seeded with sketch blocks of these profiles. I could then do my normal constraints between blocks and between sketch geometry. The sketcher solves the component position and orientation along with the rest of the sketch. The components are transformed appropriately after this.

The above is a feature I could and would create if sketches could be seeded with geometry (and then subsequently edited with the sketch editor).

MBartlett21

@ilya_baran
Just reading this, and the custom-feature-started sketches look very interesting. Will they end up getting added to Onshape?

tim_hess427

I'm just seeing this thread now, too. Its really interesting. It all sounds like a more general application of how sketch patterns and the sketch polygon tools work now. Maybe the key thing is allowing the 'seed' to be driven by some external feature.

Although, the bearing example sounds like all you really need to do is 'use' the geometry of the bearings in the sketch - I'm not sure why a new feature is needed, unless you want the ability to control things more directly through featurescrip? This and the hex examples don't seem particularly compelling. 

What does sound interesting to me, would be using a sketch as an interactive feature input. For example, if I wanted to add some custom hardware, I could select a feature that creates a generic screw profile sketch and allows me to edit the profile as desired. When I accept the profile, the full part is automatically created or more complex operations are carried out. This would, presumably, allow the constraints in the sketch to be used to enforce valid geometry for downstream actions. I could see the same workflow with custom tube profiles or something as well.