feature identity/selection stability with parametrized models

kyle_altendorf

https://cad.onshape.com/documents/31d9f3436d1f6286f056967a/v/85b86a9ace50715ca6716cea/e/28794b8e69f77c9e0f3125ad

In insert_unit I have a single square unit I use elsewhere.

In bin I use my featurescript to instantiate a grid of these based on x and y count parametrization.

In the script the grid of instances are booleaned together to form the base of the bin. I then add various other features to build up the rest of the bin. When I reference the face that is the union of all the insert_unit top faces and then reconfigure the part to be larger or smaller (more or fewer repeats of the insert_unit in x and y) I'll end up with the reference sometimes breaking. I have a few ideas how I could make this face a bit more stable by adding an extrusion that raises it a bit without referencing it or maybe some other games.

Is there a good way for me to actually improve the inherent stability of that surface though? It regenerates fine but references to it break. I just started with featurescript a few days ago so I assume I've got plenty of terrible practices in that code that can be resulting in various aspects of reference instability.

Thanks.

Cheers,

-kyle

kyle_altendorf

I'm using .transientId in a few places that could matter. I imagine those are, well, transient and nondeterministic…

for (var thing in evaluateQuery(context, mate_query))
{
    debug(context, "duplicating mate: " ~ thing);
    var mateConnector = evMateConnector(context, { "mateConnector": thing } );
    debug(context, "                  mateConnector: " ~ mateConnector);
    opMateConnector(
        context,
        id + name + thing.transientId + "mate",
        {
            "coordSystem": mateConnector,
            "owner": owner
        }
    );
}

I feel like I've missed a pretty basic thing. How do I get the id of thing? Or the id of the thing that the query thing resolves to I suppose.

Handily, this path lead to:

https://forum.onshape.com/discussion/comment/64129#Comment_64129

And there is indeed now a forEachEntity(). https://cad.onshape.com/FsDoc/library.html#forEachEntity-Context-Id-Query-function I'm switching to that so we'll see how it goes.

kyle_altendorf

I have made a more focused workspace, though it presently references back to one of the part studios from above.

https://cad.onshape.com/documents/00b67732bc7167237f3edf89/v/7132657e9570ba01efb46618/e/c275a65479aa9e0fb0840022

Note how in the assembly pictured above the two instances that were parametrized to be larger have a fillet on the outside of the top surface while the two smaller instances do not. This is the sort of issue I have been running into as far as maintaining constant resulting feature IDs from my script. The basic activity is to create a grid of instances that are parametrized by location in the grid (left edge vs. back edge vs. middle vs. corners) so they can adapt themselves to each case. (I suppose instead of 9 configurations i should have three and use rotations on the instances… anyways, performance next) Then the instances are boolean'ed together.

I can certainly understand how opBoolean() could end up picking a surface from a different instance when joining the parts to create the single top surface. But, perhaps there is still something I could do to make this more robust?

instantiate(context, instantiator);

var bodies_query = qBodyType(qUnion(instanceQueries), BodyType.SOLID);

if ((definition.xn * definition.yn) > 1)
{
    opBoolean(
        context,
        id + "boolean",
        {
            "tools": bodies_query,
            "operationType": BooleanOperationType.UNION
        }
    );
}

I could imagine both the arbitrary ordering of the query and the uncertainty of what surface is chosen as the original when they are joined being inconsistent.

Thanks for any pointers as I try to learn how to not just get some geometry, but to get it well.

Cheers,

-kyle

kyle_altendorf

Perhaps passing an identity to addInstance()would be good. I'm not sure what to pass though. My feature is basically a grid pattern but with location identifying configuration set for the instances so they can adapt to being at the left side vs. in the middle etc so I don't have a pre-existing source for an identity for each instance.

kyle_altendorf

As part of debugging, I went ahead and created points at the locations of each of the parts before i instantiate them, named the points according to their grid location so they would be … at least in part deterministic. I also made a query for the face that's actually giving me trouble as far as downstream features broken due to failed references to this face in different configurations than the feature was defined with.

Is it possible to just set a deterministic id for that face? This seems like a hack and the logic to select it is reasonably specific to this case so I don't consider it a solution, but it could stlil be useful in the meantime.