Properties Configuration with Part Arrays, or with many config parameters

connor_pinson

I have not used the properties configuration tool for long so I may be missing something very obvious, but I ran into some trouble configuring part properties for arrays of parts, or for parts with many feature parameters.  I have worked around these problems, but there must be an easier way.

Problem:
When a part is patterned or copied in a part studio, it 1.) does not inherit properties from the original part (is there an option for this that I missed?.)  Also, there does not seem to be a way to 2.) declare only a selection of feature parameters that will govern properties configuration.  It is not practical to configure part properties for every possible combination of arrays or parameters. 

I use configurations to insert arrays of custom parts into assembly to rapidly draft custom systems composed of many repeated components.  Without assembly configurations, creating BOMs for these assemblies with properties is sometimes difficult.

Solution:
Properties can be configured to only specific parameters by creating a part studio that employs only the parameters that you wish to govern properties, configuring properties here, and then deriving this part into another studio that further modifies and configures the original sketch or features.
 
 However this still presents the problem of propagating these properties into an array of parts.

For now in lieu of creating a modified pattern part in Featurescript, I have found a very silly work around for the array problem: I create a construction part that passes through and boolean unites my array of parts resulting in a single part that inherits the properties of the first part.  From here, I create a remove pattern that separates the single part back into an array of identical parts.  Again, very silly.  

Does anyone have any thoughts on this? For now I am looking at customizing my part pattern feature to inherit properties, but creating extra part studios for the properties configs is still annoying.

konstantin_shiriazdanov

agree that in configuration input fields need the support of text expressions, but creating new parts by patterns in part studio is a bad idea, because part studios were not made to do that. replicate them in assembly invironment

connor_pinson

Typically my assemblies are only 3-4 unique parts, all of which are replicated in two dimensional arrays of varying parameters.  Without assembly configuration, doing this in assembly is MUCH more time consuming than configuring these arrays and their relationships to configuration variables in part studio.  My assemblies are used for creating drawings and BOMs for custom orders that will never be a part of a larger system, so scalability is not a concern.

Jake_Rosenfeld

@connor_pinson

Have you tried our new built-in configurations?
https://www.onshape.com/videos/introducing-onshape-configurations

With this, you wouldn't need to make arrays of parts in the part studio.

I think I misread your question.  Better answer incoming.

konstantin_shiriazdanov

can you provide an example? the only way i can imagine is that you using variables for positioning, so it feels easier to make part studio arrays

ilya_baran

There are several issues you're hitting here.  Starting with your second suggestion, we're aware of the need to allow "wildcards" in the configuration selection when specifying configured part properties and we'll be working on that functionality soon.  Much sooner than that will be available, we'll ship FeatureScript functions for setting part properties, which, since you are comfortable with FeatureScript, you'll be able to use as a workaround.

Your first issue, namely patterns copying properties, is trickier -- your workaround is clever and I don't know of a better solution at present.

The challenge is that part properties are set "after" a part studio regenerates, so at the time that the pattern is happening, there is nothing yet to copy.  The exception is if the part came via a derived feature (in which case the properties set in the base part studio are already applied) or if the properties were set via the soon-to-be-released FeatureScript functions in an earlier feature.  Unfortunately, even in those cases, today's pattern does not copy the properties.  Soon, though not in the next update, we intend to fix the pattern to copy properties of derived parts (at least as a FeatureScript option), so if your workflow can shift to designing the part(s) in one part studio and then deriving them in and patterning them in another, that update will solve the properties propagation problem.

I ran into basically this issue building the instantiator I just posted here https://forum.onshape.com/discussion/8074/featurescript-instantiator-configurations-featurescript-more-power-easier-coding, which prompted the realization that the pattern/property interaction needs work.

connor_pinson

Thank you for the clarification...it's good to at least know that I am not missing an obvious fix that already exists.
If anyone is curious, I will post here an example document I made that demonstrates my processes. 


Again, this document shows how you can: 1.)  configure properties only for a subset of configuration parameters, 2.) (indirectly) pass logic into properties configs, 3.) pattern parts in a configuration while retaining their original properties for use in assemblies and BOMs.
Keep in mind that these processes require some planning ahead, and may be difficult to retroactively implement.
https://cad.onshape.com/documents/b1c15ce5422c0789da501d06/w/274ef656a8d411d5d673dab0/e/289cb0e77d5bcdfd2bd47bcb

The document is designed for a fictional fence company that draws up fence configurations for aspiring sheep herders.
The document allows you to quickly create fence assemblies, have a look at "Sheep Enclosure" to see what you might make.  These fences are simple and made up of only 2 components, but you can imagine for a fully operational fencing company there might be many orders of magnitude more complexity.
Try inserting a fence from "Fence Configurator."
 
1 and 2:
The "Fence Configurator" studio derives pickets and support poles from the other part studios, adds features, and patterns the parts.  If you look at the "Pickets Base Layer" studio, you can see that it only contains two parameters: cross section and length.  These parameters govern the configured part numbers  for pickets, which denote a cross section and length.  You can see that the length is not actually configured to any features, and is only passed into this studio to create a part number.   This fence company stocks wood in multiples of 24", so if a customer orders a 40" tall fence they are billed for the full 48" of wood used...we want this logic to be built into the part number.  

When you configure a length and cross section for a Picket in the "Fence Configurator," the length is rounded up to the nearest multiple of 24" and stored in a variable so that a part number can be referenced from "Picket Base Layer."  This allows us to embed some logic into our part numbers by storing the logic in an intermediate variable (this can also be done in the derived dialogue box) before a property is configured from the variable. 

From here, you can see that the Picket is modified to be the precise length specified, and has some optional features.  The original part number persists through these changes, because we are modifying a derived part.

**In this way, we can pass any number of parameters of our choosing into this base layer part studio that creates only the first feature of the part.  Unused parameters for the base layer feature are used to configure properties.**
 
3:
When we pattern our derived part, we lose the properties of the original part.  This company makes drawings and BOMs of custom fence assemblies, so we want to pattern parts without losing the part numbers.This part is definitely sketchy, but with a little thinking you can set it up so that we keep our properties no matter how we use this configuration studio in the future, so in some cases this is worth it. 
  
In the  Fence Configurations studio roll back to the features marked with "!!!!!" referencing the "Uniter."  Before we array the pickets, we add an arbitrary extrusion to the picket called "Uniter" that is configured with our array parameters such that it will overlap with the subsequent "Uniters" in the picket array.  Now, we array the pickets using the "Add" option.  Now we have one part that resembles a line of pickets that retain the name and part number of the original picket.  Finally we create an extrude feature using the "remove" option with the original "Uniter" sketch that runs the length of the part and removes the Uniting feature.  We are left with a line of individual instances of our customized picket, all retaining the properties defined in the underlying picket layer.  The support poles were not given a uniter, so only the first support pole has properties.  


I am confident that properties will be easier to manage for this type of application soon, but in the mean time maybe you can make use of these tricks.

owen_sparks

I salute your "uniter" concept, that's a stroke of genius

Regards,

Owen S.

Jake_Rosenfeld

@connor_pinson

Try this out:
https://cad.onshape.com/documents/490b3f3a8dd5c84e1807bc65/w/2789fb957544de1db53be216/e/d211c7a31bd083244758f127

I made a 'Copy properties' FeatureScript which uses your methodology but wouldn't require any advanced planning.  Basically it just surrounds everything with a bounding box, booleans everything together to share the properties, and then subtracts a negative of the original geometry to get the original geometry back, with copied properties.

A couple limitations: it will annihilate any hole information made by the 'Hole' feature, and it will not work with sheet metal.

Please let me know if it works for your case.

connor_pinson

@Jake_Rosenfeld

Nice work Jake! I was thinking of something like this when I was trying my own featurescript.  It seems to work for most of my arrays. I bet there is a way to make it work with holes too.

I was doing some more thinking on this, please do me a favor and hear me out and let me know if what I am suggesting is already doable with what we have:  

It also occurred to me that an easier way to retroactively create a base layer for properties configuration would be to copy your configuration studio, delete all of the features and unwanted configuration parameters, and then create an arbitrary part.  This part could then be derived into your config studio and used as the primary target of a boolean union to inject properties into the desired part before it is arrayed.  You could avoid the subtraction step by making this part small enough to fit inside the target.

Is it possible to make a "Properties Seed" FeatureScript that creates a part studio with selected configuration parameters of the existing studio, and creates a tiny derived feature that booleans itself into a selected part?  This would make it possible to quickly create properties configurations for selected parameters.

Of course the natural extension of all of this is --layered-- properties configurations...once a part is derived into a studio, its properties can be configured within the new context.  So we can have a name and part number assigned to a derived part, but then we can alter the description based on what happens in the next layer, then pass it through a material selection layer, etc etc.  The result is a top level studio that instead of having a 1 to 1 properties to configuration ratio, has a multiplicative effect throughout its layers.  In other words not only can we configure properties for only the desired feature parameters, but we can configure only a desired selection properties to individual features as well.  This is of course achievable in other data management schemes, but this may be the best way to achieve this in Onshape.  

connor_pinson

connor_pinson said:

@Jake_Rosenfeld

 This is of course achievable in other data management schemes, but this may be the best way to achieve this in Onshape.  

Obviously, the best way so far as I expect this will probably be easy within the properties config tool soon enough.