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.

Best way to get part a feature is related to

Cappie_PomeroyCappie_Pomeroy Member Posts: 7 PRO
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 }
definition.part is Query;
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
{
"featureId": "String",
"name": "String",
"value": Number,
"unit": "String"
"part_id": "String",
"part_name": "String",
"microversion": "String",
"serializationVersion": "String
}

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!


Comments

  • ethan_keller769ethan_keller769 Member, Onshape Employees Posts: 25
    edited July 3
    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_PomeroyCappie_Pomeroy Member Posts: 7 PRO
    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

  • ethan_keller769ethan_keller769 Member, Onshape Employees Posts: 25
    edited July 8
    You could get the partids that we use in the API through featurescript by getting the query for the particular part, then using @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:
    {'myMeasurement':{'measurement': '6*meter', 'pids': ['JHD', 'JJB']}}
    Here's a featureScript snippet that would print all the pids to the featurescript console:
    for (var part in evaluateQuery(context, qEverything(EntityType.BODY)))
    {    
        println(@transientIdToString(part.transientId));
    }
  • Cappie_PomeroyCappie_Pomeroy Member Posts: 7 PRO
    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_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 446
    @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_PomeroyCappie_Pomeroy Member Posts: 7 PRO
    Ok great! Thanks for all of the clarifications and tips @ethan_keller769 and @kevin_o_toole_1 !
  • ethan_keller769ethan_keller769 Member, Onshape Employees Posts: 25
    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.
Sign In or Register to comment.