Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Work Around to Configure Part Properties without Dependence on All Configuration Inputs

Kyler_WalkerKyler_Walker Member Posts: 202 PRO
I am trying to configure a part number to depend on two List inputs.  The part also has a configuration variable input, but I don't want the part number to depend on it.  A strategy I have conceived to do this is something like the following.  The part number would be configured in the configured properties table using a default value of the configuration variable.  A different part studio would derive the part, referencing a document version and using the default value of the configuration variable.  A custom feature used in the original part studio would import the second part studio that has the derived part.  The custom feature would read the part number of the derived part and write it to the part number of the real part in the original part studio.  Can someone please tell me if this type of workflow is viable?  I see that getProperty can't be called in custom features, so I'm not sure if I can implement this.  Is there another way to get properties of the derived part though?  The derived part referencing a version should be able to build completely and independently from the original part studio, right?  I don't think I would be created circular references.  I would appreciate any suggestions for possible strategies.  Thanks!

Answers

  • MichaelPascoeMichaelPascoe Member Posts: 1,908 PRO
    edited March 2023

    Here is something that may help. You can getProperty, but it has to be within edit logic, then passed back through your features definition. This has limitations, but it is possible. For example, edit logic only works while the feature is open and active. So it will get the property at that moment, but will not update automatically if it changes in the future; you would need to open the feature again for it to get the property again.

    https://cad.onshape.com/documents/90725236c8afc273e163d439/w/aab71dc2825eb36fc1fa983b/e/894e6d5e239401f62c5fee7c

    FeatureScript 1930;
    import(path : "onshape/std/common.fs", version : "1930.0");
    
    annotation { "Feature Type Name" : "Get Face Property Test",
            "Editing Logic Function" : "editLogic" }
    export const getFaceProp = defineFeature(function(context is Context, id is Id, definition is map)
        precondition
        {
            annotation { "Name" : "Face", "Filter" : EntityType.FACE, "MaxNumberOfPicks" : 1 }
            definition.face is Query;
    
            annotation { "Name" : "String data", "UIHint" : UIHint.READ_ONLY }
            definition.stringData is string;
        }
        {
            println(definition.stringData);
        });
    
    
    export function editLogic(context is Context, id is Id, oldDefinition is map, definition is map, isCreating is boolean, specifiedParameters is map) returns map
    {
        const data = getProperty(context, {
                    "entity" : definition.face,
                    "propertyType" : PropertyType.NAME
                });
    
        definition.stringData = data;
    
        return definition;
    }

    Learn more about the Gospel of Christ  ( Here )

    CADSharp  -  We make custom features and integrated Onshape apps!   cadsharp.com/featurescripts 💎
  • Kyler_WalkerKyler_Walker Member Posts: 202 PRO
    Thanks for the help.  I played around with this a little, but, unfortunately, I don't think it can help me because it doesn't update automatically.  Do you know why we can't read the properties of parts at a particular version?  It seems this must happen any time you derive a part, as it comes in with properties attached.

    I'm thinking that a viable work around for my problem might be to derive in a template part with the desired part and do a Boolean union to get the part number from the template part to be applied to the real part.  
Sign In or Register to comment.