FeatureRequest: FeatureScript expanded to Assembly and/or drawings

Artis_Johnson

I was walking through the documentation for FeatureScript. I realized that it only functions within the Part Studio. Is there any way that the FeatureScript could be expanded into Assembly and Drawing? Is this something that is being looked into?
There could be created functions that operated between the parts, assemblies and drawings. 

alan_baljeu

FeatureScript is designed to work within the context of a history tree, where earlier objects provide inputs that are used to derive later objects.   A Feature is a function that computes a new object from the designated inputs.

Assemblies are not histories.  They are collections of parts brought in from PartStudios and constraints between the parts.  So while there could be scripting for assemblies, it's not clear it would operate the same way as scripts in a PartStudio.

This is not to dismiss your request, but just a preamble to: what sorts of things would you like to do in Assembly with scripting, that can't be done effectively either with configurations or by scripting in the PartStudio and bringing in the parts thus created.

Same question for Drawings.

I'd love to hear some examples.  

mahir

While not trivial, the transition from FeatureScript running in a part studio to FS in an assy or dwg is relatively straightforward in scope. Instead of taking as input the history/context, an assy/dwg FS would take as input the assembly component and its constituent geometry (faces, edges, points, etc) or a drawing object/geometry (view, annotation, line, etc). I don't see why that would be inherently incompatible with the existing FeatureScript paradigm. The hard part is that the functionset would need to be expanded to include assy/dwg commands. Part studios already run FS under the hood. I'm not sure that assy/dwg do as well.

konstantin_shiriazdanov

I beleve FS is already used in assemblies silently, I can remember some examples from @MBartlett21 who shown me some declarations from standard library related to assemblies. If it was exposed and advanced enough we could have some custom assembly patterns and constraints at least, which is the lack in OS for now.

Fda

Could the following Script be implemented in Assemblies?

Measure Value

https://forum.onshape.com/discussion/comment/44077#Comment_44077

Auto Layout

https://forum.onshape.com/discussion/comment/38378#Comment_38378


I think they are two good characteristics to start playing in the Assemblies ...

Brendan_Leipelt

Mirror would be nice in Assemblies. Usually linear or circular patterns can get the job done between them but Mirror would be preferable in some cases. If there's an elevation change with a part at an angle or specific rotation, circular will put the new part at the reverse angle needed, and linear will put it facing the wrong direction. In this case, usually a new copy is inserted and mated when neither of the pattern options suffice. Mirror isn't strictly necessary but it would be very welcome.

ilya_baran

I'll try to shed a little light on this.  First, what is currently in place.  FeatureScript is the basis of Part Studio regeneration; it is used for some aspects of assemblies (like expression evaluation) and drawings (like doing section view cuts), but its presence there is minimal.  FeatureScript is primarily intended for creating and modifying geometry and assemblies and drawings just don't do that.  That's not to say there wouldn't be value in FeatureScript-based automation there, but it's not present (neither exposed nor under the hood).  For assembly automation, we currently have our REST API, and we're expanding its usefulness for working with drawings also.

Getting FeatureScript to automate Assemblies and Drawings is much trickier than it would seem.  For Part Studios, the feature list is a program and the geometry is its output, which we compute whenever we don't have it and need to display it.  For Assembly and Drawing automation, you want FeatureScript to be able to control which parts and drawing elements appear where.  That means either having the FeatureScript run on the user's command and modify the tab definition or we would have to introduce some sort of regeneration aspect to these tabs.  The former is not super-convenient and the latter is quite challenging.

As for the requests listed, Mirror is something that we definitely plan to have, so no need for automation there.  Measure value is interesting: if you automatically assign the distance between two parts to a variable, presumably you want to be able to use that variable to constrain things in the same assembly, causing a circular definition loop.  We do plan to make reusing variables easier, so hopefully, we'll be able to measure in-context and then use the measured value in the assembly.  That's probably easier to control than via assembly automation.

Auto layout is a good example of the type of thing one might want in assembly automation (although of course there are special nesting apps for this type of thing).  What are some other examples?  If we had some compelling real-world potential use cases, that would help us narrow down the design space.

tim_hess427

I think I would be Ok with the scripts running on the user's command. To me, this would be analogous to a macro in a spreadsheet. Perhaps, there could actually be some "macro recording" function as well.

I think its somewhat difficult to come up with very compelling use cases without knowing exactly what the capabilities are (I know that's some circular logic, unfortunately), but I'm always amazed at what people come up with for featurescript in part studios. A few things that do come to mind for me:

• Automating clearance or other fitment checks in configured assemblies. We have a configured product and when we make a change to one component, it would be useful to automatically rebuild each configuration using the component and check for clearance issues or other key dimensions. 
  
• Automating clearance or other fitment checks in moving assemblies. Similar to above, it would be good to have the assembly loop through a range of motion (or several named positions) and check for clearance at each position.
  
• I could also see special use-cases where automation could speed up part import and mate creation and assignment. For users that have a lot of standard components (like someone design automation equipment and uses lots of standard hardware) - What if you could import a layout sketches and automatically import configured components (such as 80/20 added and configured to length) along with automatic import and mating of brackets and screws? (The more I think about this idea, the more I like it). Seems like there are some furniture/cabinet makers here that could add a panel and have a scrip automatically identify pockets for hinges and add the correct hinge and hardware. 
• In addition to the mirror function - I could see more complex patterns driving instances based on other assembly features and geometry that aren't handled well be the current replicate function.

mahir

I'd love to have something similar to SW's Derived Pattern. You can sort of do that now with placing fasteners in similar sized holes, but it's not smart. If hole patterns move or change count the fasteners don't follow along.

pmd

One use of assembly automation I would like is the ability to automatically insert and mate parts to existing items. For example we make a case with recessed handles and catches so the sheet metal part has cutouts for them and these are already generated by our own FeatureScript  but when we bring the part into the assembly we have to manually place all the catches and handles which is a (small) chore.

Our FS script could easily place a mate connector on the part in the centre of the cutout hole and the assembly automation could have a rule saying insert handle to all mate connectors called "handle1234" which are not already mated, insert a catch to those named "catch1234" etc. etc.

Kind of like replicate command but with a ruleset, based on mate names part-refs and explicitly has to be invoked by the user just like replicate.

Other rules which could be useful would be something like insert a rivet into all 4.2mm diameter holes which do not already have one.

alan_baljeu

I think the core of this question is correctly combining the two paradigms of parametric modelers: constraints and history.  Back in the dark ages, even before SolidWorks was around, some CAD systems did parametrics entirely by history.  A sketch was defined progressively as a parametric line, maybe with fixed start point and a length and an angle, then you could attach other geometry on either end. Eventually you get a profile generated through this history, and then extrude or revolve it to form a solid.  It was tedious, with all the complaints about history applying also to the creation of sketches.  Then D-Cubed came along and revolutionized sketching with concurrent constraint solving.   It was so much better that the two paradigms were the thing from now on. 

FeatureScript, an amazing invention, is based on History.  And this is why it does a poor job of handling sketches, because the paradigm is wrong.  OnShape Assembly again is based on concurrent constraint solving, and FeatureScript wants a sequential organization.  This *can* technically be done, but by introducing a complexity to the assembly modeling scheme.  This relates to what @ilya_baran was writing about circularity.  If you want to add a scripting element to the system, you need to establish a history ordering within your assembly.  At base this is hard because the existing paradigm allows at any moment to add a constraint between any two under-constrained subassemblies to modify the placement of both.  

So what you might want then is to define part of the assembly as a collection of parts and constraints on them, and then add a Feature, with input maybe being a part or some subassembly, and maybe parameters the user defines, and the output is additional parts and additional constraints, or modifying some variable values of the input.

But we now have a history element in the middle of the assembly.  When does the feature update its definition?  Perhaps when any element of the input changes.  But remember that assembly modeling allows at any moment to add a constraint, and that constraint might be between an input of the feature and an output of the feature, or things associated with either.  And that constraint will naturally amend the input.  And now we have a loop; one that could be avoided by fully constraining the input prior to even invoking the script, but obviously that kind of rule limits what can be done.

I imagine doing this for drawings ought to be much easier.  A drawing consists of references to the model and other elements drawn about them, some of which, such as dimensions, are driven by the model.  There isn't much history within the drawing system, so it would seem to be easy to define a Drawing Feature, taking inputs of whatever selection, and creating any geometry as outputs.  Yet perhaps more useful would be deriving things from the model itself.  If you do this, the key is to have an associative update.  When the source of the feature changes, the feature must recreate its outputs.  This doesn't seem hard to me, just needs OnShape to have this update mechanism.

konstantin_shiriazdanov

alan_baljeu said:

FeatureScript, an amazing invention, is based on History.  And this is why it does a poor job of handling sketches, because the paradigm is wrong.  OnShape Assembly again is based on concurrent constraint solving, and FeatureScript wants a sequential organization.  This *can* technically be done, but by introducing a complexity to the assembly modeling scheme.  This relates to what @ilya_baran was writing about circularity.  If you want to add a scripting element to the system, you need to establish a history ordering within your assembly.  At base this is hard because the existing paradigm allows at any moment to add a constraint between any two under-constrained subassemblies to modify the placement of both. 

In the end featurescript is just a language, you can't say the FS itself is not suiting for assemblies because functions we writing for part studios are designed to take top level id and context. We can only state that we are not aware about abstractions and top level wrapper functions that are used to define assembly relations and/or patterns. If they possibly using real object types which are not handled well in FS then this would be a big problem and we could say - yep, FS is not a way to go for this, but if a function like defineConstraint(side1, side2, options) used under the hood to define assembly constraint and embed it into the equation system for assembly solver then it possibly all that we need, because we can definitely write FS functions.

alan_baljeu

FS is in part a language, but the key of the tool is that the features you define in that language and add to your model are automatically executed every time it needs to be executed.  Without that you could theoretically achieve the same result if given a Javascript API, but with a lot more complexity to pick up the inputs, and create outputs.  And also manage the outputs, because the history system that does this for us in Part Studio, isn't available in Assembly.

magnus_hammar

Pardon me for waking up an old thread but I wanted to give my two cents on this. I would like AssemblyScript. A totally different animal than FS. A query and update language with no sense of history but with event handlers that pass a context object.

Case 1: A custom configuration that automatically reach into inserted paths to see if it can configure them. Perhaps in the form of a query for a specific variable name + other characteristics of the part.

Case 2: Automatic generation of assembly part numbers based on the configuration values. In some projects I am looking at the selected over all length of the assembly is slapped to the end of the part number. This would become trivial. XYZ - #Length

Case 3: Lets imagine I create a part containing a sketch called "floorPlan" with a bunch of points. I drop it into my Assembly and every time I select a point in that sketch I get a list parts to insert there. I select one and have it automatically mated in place.

At the end of the day my point is this.. There are a lot of things to automate around part insertion and mating and there a lots of useful information to be queried from the assembly. FeatureScript is revolutionary so I sincerely hope that you as an organization have realized that there is also utility for a JS-based Script language in Assembly modeling, albeit with a different characteristic.

tomduf70

Hello,

I'm a french teacher of engineering sciences. My students and I love Onshape and we use during our projects and even during my courses to illustrate mechanicals concepts. I abandoned Solidworks with no regrets...

...except for motion study !

The Animate function of a constrain (revolution for example) is wonderful and the ability to view the motion of all parts of a mechanism and navigate in the view is bluffing.

But in my courses and students activites, I have to talk about movements (motions ? Don't know the english difference...), trajectories, velocity and acceleration vectors.

It would be great if an assembly script language would allow us to create such objects in combination with animations.

Anyway, thanks a lot for this amazing product that Onshape is.

Thomas DUFOUR
Lycée Bernard Palissy
Saintes
FRANCE  

bob_tipton

Hi Ilya, long time since we talked and I hope you're well. Good explanation of the situation.

An excellent example of the need for assembly scripts is making bicycle sprockets and chains. (https://cad.onshape.com/documents/cc993c9de6e256e096bcc688/w/6c8dba00ac04f0e26281ba39/e/4e5b6ff4b550e97dd1799b83)

Assembly features are definitely tricky, but we did discuss them in the past. Maybe an assembly macro might be a better approach A one time tool that populates instances and assigns constraints. I'm trying to model a chain drive today and it's tough.

Feature script is able to create pseudo assemblies, in part studios, but I recall being told this was an "off label" use of the capability. For example I can write a script with creates the chain link path, then populates the sprockets and links to fit the path. It looks great, but it's not really an assembly. You may recall I once wrote a script to create a drilling rig that way.

Before I go off and write a script to make the entire chain/sprocket "assembly" in a part studio, is there a reason why I should not, other than doctrine?