FeatureScript: Query imported geometry

leon_poot

I am trying to figure out how to refer to any geometry of a feature that has been imported into a PS through FeatureScript.
(Import is done using either opMergeContext() or importDerived(), not sure which one is preferable).

It is important to me that there is no user selection (feature querying) involved, as I will be doing this many times. 
Here is a simplified example of what I want to do:

1. Create e.g. some geometry and a reference point in Part Studio 1, using Feature A.
2. Import (+ mate, transform) in Part Studio 2, using Feature B.
3. Create geometry based on the reference point in Part Studio 2, using Feature C.

I have created a public test-bench document here: Referencing Testbench
I have tried with getAttributes and querying using qCreatedBy() combined with a variety of Id combinations (I am not sure how "ANY_ID" works, but it seems to be part of the answer).

If anyone has any input that can put me in the right direction, please do have a look at the document and let me know.

lana

I suspect newId() + ANY_ID would not work - we would not like wildcard for top level id.
You can use setAttributes and qAttributeQuery or qAttributeFilter sheetMetalAttribute.fs and sheetMetalUtils.fs in std library have some use examples.

In general task which can be described as "Find topology" is solved by evaluating a query. All queries FS can handle are defined in query.fs

Alternatively - you could make FeatureC accept Feature B as one of parameters ( definition.mergingFeature is FeatureList;   in precondition) then 
var mergeId;
for (var entry in definition.mergingFeature)
{
    mergeId = entry.key;
    break;
}

if (mergeId != undefined)
{
     qCreatedBy(mergeId + "merge" + "extrude1", ...) 
}

lana

opMergeContext() completely merges other context into this context, as if the feature script of another part studio were executed at this point.  importDerived() wraps the call to Part Studio 1 build() , opDelete call to leave only requested bodies, and opMergeContext(). Use either, depending of what you want to achieve.

If you are calling opMergeContext(context, id + "merge", ..) then qCreatedBy(id + "merge" + "extrude1", ..) will give you entities created by the feature in Part Studio 1 which has id i + "extrude1".

If you know Prat Studio1 content you can use qCreatedBy(id + "merge", ..) in combination with filters.
Does this make sense? 

leon_poot

Thanks, @lana. That does indeed make sense. However, this only seems to work when qCreatedBy(id + "merge" + "extrude1", ...)  is called after opMergeContext() in the same feature, i.e. Feature B.

Once I try this in Feature C, the query resolves to nothing, since the id differs. That is why I was hoping to be able use ANY_ID, which seems to work as a wildcard. Something like this:

qCreatedBy(newId() + ANY_ID + "merge" + "extrude1", ...)

I'm thinking I could use setAttributes in B and getAttributes in C, but I am unsure how these work and I can't find a proper example. The name of the reference is really quite important, as I might have many different reference points in one PS for different functions.

lana

I suspect newId() + ANY_ID would not work - we would not like wildcard for top level id.
You can use setAttributes and qAttributeQuery or qAttributeFilter sheetMetalAttribute.fs and sheetMetalUtils.fs in std library have some use examples.

In general task which can be described as "Find topology" is solved by evaluating a query. All queries FS can handle are defined in query.fs

Alternatively - you could make FeatureC accept Feature B as one of parameters ( definition.mergingFeature is FeatureList;   in precondition) then 
var mergeId;
for (var entry in definition.mergingFeature)
{
    mergeId = entry.key;
    break;
}

if (mergeId != undefined)
{
     qCreatedBy(mergeId + "merge" + "extrude1", ...) 
}

leon_poot

Thanks again! The combination of setAttributes and qAttributeQuery seems to do the trick for me. I figured it out somewhat clumsily, I'll have a look at the sheet metal examples and see what there is to learn.
I will certainly look into having the feature as a parameter, that seems like it could be a very neat solution indeed.

Really, FeatureScript is just about the best thing with Onshape, the possibilities seem endless once you get the hang of things.