Best way to get part a feature is related to

Cappie_Pomeroy

I am using FeatureScript and the Onshape API to define measurements that need to be taken on parts and track them through our production process.  I am in general very pleased that Onshape has developed these tools because managing this in other CAD programs was so nightmarish we avoided it entirely.  Right now I am using a slightly customized version of Measure Distance Extended https://cad.onshape.com/documents/77baa8153589a7fc5f289829/w/cffd0f2a7077380d5378a885/e/d3174bf5315e6aafcb889367 I have added another precondition to attempt to restrict the measurement to a single Part via

annotation{ "Name" : "Part", "Filter" : EntityType.BODY && BodyType.SOLID, "MaxNumberOfPicks" : 1 }<br>definition.part is Query;<br>

It is unclear to me how to restrict the remaining selections to be only on that part any advice on that would be useful, but I'm sure it's just more digging through the docs.  My more pressing question is about API calls.  Currently my work flow from my cloud integrated app is

1. GET part_studios in document
   
2. Iterate over part_studios and GET features_list
3. Filter features_list for "measureValue" features, pull out name, partId, and microversion
   
4. GET parts from part_studio measureValue feature was in, look for the partId, pull out part name
5. POST featurescript to evaluate measureValue varible value for each measureValue feature name

Then I construct my object

{<br>  "featureId": "String",<br>  "name": "String",<br>  "value": Number,<br>  "unit": "String"<br>  "part_id": "String",<br>  "part_name": "String",<br>  "microversion": "String",<br>  "serializationVersion": "String<br>}<br>  <br>

Then the user tweaks things how they want and I send it off to our database and it populates our various measurement UIs etc.

Is there a better work flow for this?  4 API calls + extra for each additional FeatureScript variable and Part Studio seems like a lot.

Thanks!

Ethan_K

Hi @Cappie_Pomeroy!

To your first question, I'm quite sure there is no way to have the precondition filter based on the selection of the previously entered query param. You can only filter based on the geometry/entity types as specified in https://cad.onshape.com/FsDoc/uispec.html . Therefore the best way to do this is to fail the feature and set the problem geometry in the error. I cooked up a short example here: https://cad.onshape.com/documents/35d3454cea522f3aad260f55/w/92947cbb34b76fb048910110/e/588987397d874076e058b96f 

As for the second question, am I right in thinking that all you need is to extract the actual measurements? The strategy that has been taken before is to put all the measurements under a single variable (usually a map), and then retrieve that variable using the evaluateFeaturescript call. This way you only have to make one call per part studio. See here for an example using the python client: https://github.com/onshape-public/onshape-clients/blob/master/python/onshape_client/example_programs/get_measurements.py

Let me know if you need any more pointers! 

Cappie_Pomeroy

Ah thanks for the Featruescript example.  That will work wonderfully!  The map of variables is a good idea that will definitely save on POST Featurescript calls.  I need to extract the measurements and know which part within a part studio they are associated with so I'll still need the extra calls.  Unless there's a way to put a part ID within the measurement variable in Featurescript.  Is Featurescript able to get the API part id's?  This post seems to suggest that it can't

https://forum.onshape.com/discussion/11346/using-partquery-in-featurescript-to-retrieve-parts

Ethan_K

transientIdToString to get the deterministic id (which is just another name for the partId that we use within the API). You'll have to sort out the builtin topology (like the default planes, etc...) . But you could couple this with your measure code in the evFeaturescript call to include the deterministic id within the measurement response - perhaps you should structure 'm' as:

</code>{'myMeasurement':{'measurement': '6*meter', 'pids': ['JHD', 'JJB']}}</pre>Here's a featureScript snippet that would print all the pids to the featurescript console:<br><pre class="CodeBlock"><code>for (var part in evaluateQuery(context, qEverything(EntityType.BODY)))<div>
{</div><div>&nbsp; &nbsp; 
    println(@transientIdToString(part.transientId));<br></div><div>}
</div>

Cappie_Pomeroy

Ah that is interesting I didn't realize that the transientId was the same as the one used in the API.  I see that they are not stable and that makes sense, but if I specify a specific version or microversion in 'm' as well can I count on the transientId to be consistent over time? i.e. In Part Studio 1, transientId 'JHD' refers to 'Part 1' in microversion 'v' so if I make an API call to Part Studio 1 at microversion 'v', 'JHD' will always refer to 'Part 1' now and forever?

kevin_o_toole_1

@Cappie_Pomeroy
Correct, at a given version or microversion, those ids will always refer to the same parts. Versions and microversions are immutable in every way that can effect these ids.

They are called "transient" because they may change whenever the model changes. So, for different microversions, or at different points in regeneration (i.e. before and after a feature, or before and after some operations inside a custom feature), those ids may not be stable. But in a version or microversion, the model can't change, so neither can those ids.

Cappie_Pomeroy

Ok great! Thanks for all of the clarifications and tips @ethan_keller769 and @kevin_o_toole_1 !

Ethan_K

Also note that if you'd like to be able to track parts as they change - translate the ids, so to speak, we have endpoints for that and to handle associativity within our versioning system.