Auto-populating Part Numbers and/or Names

Aidan_Benysh

As best I can tell, part names are automatically generated by Onshape when parts are initially created with the nomenclature Part [Number in design hierarchy]. Part numbers can be created automatically as well such that you can also use a numbering scheme that has a continuous counter that goes up for any part that is released, or for any part which the part number is manually applied in the same format. Bearing this to be true, I have the following issue: 

In my case, my company does not use release management at this time, therefore it is required to add the part number (through the auto generate button) to parts individually or at the BOM level in assemblies. This is a step that could be perceived as "skippable" to some. In order to save a not insignificant amount of time, is it possible to automatically populate the part number with the pre-formatted sequential numbering scheme that is set? (I have only found information stating that it is not possible to auto-populate the part name, but little information on the part number) I have seen in these forums many people finding work arounds utilizing the part name with a preset excel sheet or a conjunction external PDM software but this is not something I would be interested in; I feel like it could be inherent to the product.

The reasoning behind this may reveal a different method of attack for the true problem I have; once parts are complete in Onshape we will export them into our ERP software (Revision management is handled within the ERP software at this time, hence why we aren't as worried about it while designing in Onshape). Within this software every part must have an individual name as to not overwrite previous logs associated with any existing parts. You can imagine there are a lot of "Part 1"s.

Therefore I see two possible paths:
Option 1: We could simply use Onshape's built in part/assembly numbering system which would retain a constant count of parts designed keeping each individual as a property level that could then be referenced under the export rules to label them with "uniqueness" upon export. In this case the part number would be the extent of the characterization of the part.
Option 2: We could define custom properties that could be referenced within the export rules to characterize the part, along with an individual string of characters or numbers. The best way I can figure to create an individual string would be a timestamp for the export time on each part. That being said, an issue arises when exporting multiple files for reference by the guys on the shop floor as when comparing the filenames/part numbers for a DXF vs a STEP file they could have contrasting numbers, normally a very bad thing. 

I'm mainly looking for opinions on what method may been seen as more "robust", or if there is a better custom property method that could be used during export to generate individual yet characteristic file names?

Thanks in advance.

Aidan_Benysh

I have returned with new knowledge, and even a solution. As my original problem was to create individual, characteristic name for parts the onboard name generator did not suit my needs [P-4002 is individual but not characteristic as to be usable by floor operators]. Sheet metal parts are the bulk of our workload so that is the main focus. What is most important to me is the size of the part as it will be cut on the laser/waterjet/plasma. This same information is also most important to the operator of said machine.

Previously as a stop gap solution I was using the StockSize featurescript [https://cad.onshape.com/help/Content/manage_procompany_account.htm?cshid=company_properties#CompanyProperties]. I would then use the output from running this as a Property - in the sample document it is shown the original creator used this to populate a BOM table - which could be called under export rules. Due to some change in ~April 26, this stopped working. Not sure if it was a change in Onshape or a change in the StockSize that has stopped this from working.

The StockSize featurescript is too complex/out of my depth so I wanted a tool that would be simpler. Returning to the original problem, below is a featurescript that would pull the flat pattern, create bounding box, arranges the dimensions, and give a string output. The code as created is here:

FeatureScript 3008;
import(path : "onshape/std/common.fs", version : "2695.0"); 
import(path : "onshape/std/sheetMetalUtils.fs", version : "2695.0");
import(path : "onshape/std/evaluate.fs", version : "2695.0");
import(path : "onshape/std/units.fs", version : "2695.0");

annotation { "Property Function Name" : "computeFlatPatternSize" }
export const computeFlatPatternSize = defineComputedPartProperty(
    function(context is Context, part is Query, definition is map) returns string
    {
        try silent
        {
            // Try to find the flat representation of the given folded part
            var flatPart = qCorrespondingInFlat(part);
            
            // Fallback: If empty, check if 'part' itself resolves
            if (isQueryEmpty(context, flatPart))
            {
                flatPart = part; 
            }
            
            if (isQueryEmpty(context, flatPart))
            {
                flatPart = qEverything(EntityType.BODY);
            }
            
            // Final check
            if (isQueryEmpty(context, flatPart))
            {
                return "BrokenA"; 
            }

            // Evaluate the 3D bounding box around the sheet
            const box3d = evBox3d(context, {
                "topology" : flatPart,
                "tight" : true
            });
            
            // Extract the 3 overall sizes
            const dimA = box3d.maxCorner[0] - box3d.minCorner[0];
            const dimB = box3d.maxCorner[1] - box3d.minCorner[1];
            const dimC = box3d.maxCorner[2] - box3d.minCorner[2];
            
            // Sorting logic for 3 dimensions (thickness, width, length)
            var minDim = dimA;
            var midDim = dimB;
            var maxDim = dimC;

            if (minDim > midDim) { var tmp = minDim; minDim = midDim; midDim = tmp; }
            if (midDim > maxDim) { var tmp = midDim; midDim = maxDim; maxDim = tmp; }
            if (minDim > midDim) { var tmp = minDim; minDim = midDim; midDim = tmp; }
            
            // Convert internal meters to inches and round to 2 decimal places
            const t = toString(roundToPrecision((minDim / inch), 2));
            const w = toString(roundToPrecision((midDim / inch), 2));
            const l = toString(roundToPrecision((maxDim / inch), 2));
            
            const resultString = t ~ "x" ~ w ~ "x" ~ l;

            // DEBUG PRINT
            println("Flat Pattern DXF Debug -> Output: " ~ resultString);
            
            return resultString;
        }
        
        return "BrokenB"; 
    });

This code is probably not optimal and the debugging methods are basic but it appears to work.

This outputs a computed property that is "computeFlatPatternSize" this string gets hidden away in the document.

For the next step we create a custom property in the company settings. I called this property "stockSizeProperty" since it already existed from the previous stop-gap solution. The "stockSizeProperty" then can become a computed part property referencing a working version of the "computeFlatPatternSize" property. Do this while selecting the categories Part and Part Studio to be Active with scope of Part and Part Studio respectively.

Finally, under preferences we can change export rules for the file types as necessary using the "stockSizeProperty" in the proper naming convention. I partnered this with a few other properties to further characterize the files. See the image below.

These do seem to have a 'stack' where the order does matter as to how they are applied. [This seems to be trial and error and I don't know how that works] You can see this on part studios where the regeneration time is long, where upon export the original file name will appear then change very quickly once the export rule is applied by the system.

Once these things are complete the result can be seen in the image below.

I hope this helped somebody, but if nothing else I wrote this just to remember what I did next time it breaks.

Aidan_Benysh

Since writing this I have learned the following, both option one and option two above have their issues due to an unforeseen problem. I've been testing different methods and the current system is as follows. 
We have implemented the automatic part numbering schema and have turned on the release management in order to better utilize the part numbering feature. With the part numbering feature we have also applied export rules to export STEP files with parts following this format: ${partNumber}-${revision} therefore with our part number system we would be looking for a file with the name "P1201-A" as an example.
This works fine for singular parts, the problem appears to be with assemblies. When exporting an assembly I can't seem to figure out how to get the components within the assembly to come through to the next software with their assigned part number. The assembly would come through fine (with the expected part number) as "ASM1201-A" however the parts come through with their (un)assigned name, "Part 1" or whatever random name is applied to them. Our assembly export rule looks like this:


With the category set to all categories I believed it would apply to assemblies, subassemblies and parts underneath the scope of assembly, is this correct?
At this time the scope for parts also has this same export rule.

Inherently this also returns to my original question and one that was posed in 2021: 
https://forum.onshape.com/discussion/16972/part-names-part-numbers

Under the linked forum post there are work arounds but not perfect solutions to the problem asked. 

Aidan_Benysh

Every once in a while I return having learned more and upon reaching a new dead end. This is slowly becoming a repository of information generally related to the issue of getting usable, auto-generated part names without using release management; I plan to continue this. Within the following links are related forum posts that seemingly corroborate to the issues I am running into, each without answer or without an answer that works for the case I am presenting:

https://forum.onshape.com/discussion/19532/export-rules-does-not-apply-to-multiple-exported-files-inside-zip-file

https://forum.onshape.com/discussion/comment/82452#Comment_82452

https://forum.onshape.com/discussion/comment/80605#Comment_80605

Since the previous post we have turned off release management as the part number generator (a positive feature) did not outweigh the learning curve that appeared. In that case the part numbers which were being generated were great, however they did not carry through when we attempted to export assemblies or part studios wholly. Therefore for the time being release management has been taken away. 
Currently I am attempting to make export rules work for our use-case and the following nomenclature appears useful: 

This, once again, works great for singular parts and for the top level of assemblies and/or part studios. The parts within the assemblies do not seem to translate over however once the files are exported from Onshape for further use, reverting to their Part 1, Part 2 etc. common naming convention. 

This appears to be a common issue when using a different step translator between import and exporting operations. Looking into the causes of this I reference the following sources for information:

https://forum.freecad.org/viewtopic.php?style=4&t=39438

https://forums.autodesk.com/t5/fusion-support/when-exporting-to-step-file-all-body-names-and-folders-are-lost/td-p/10758938

https://www.alibre.com/forum/index.php?threads/loss-of-part-names-in-exported-assemblies.7123/post-37687

Per these sources I went to look at an exported Step (AP242) from Onshape and imported it back into Onshape to see what happens.
That test yields positive results:




Looking at the step file from that export we can see that the part name is provided under the identity "PRODUCT". And when imported all the names match with the imported parts.

Ref. https://www.steptools.com/docs/stp_aim/html/t_product.html

So we know that the exporter is taking the part names. We also know the part names cannot be auto-generated or directly link to a part number. Therefore, what does export rule do for me when I am trying to get parts to export with a provided file name from within an assembly or a part studio? 
Even if I include Parts as a category within the scope of Part Studios and assemblies, I yield the same results. Have I misunderstood how the export rules are meant to function?

Under these settings Part Studios import using the names created by the export rules as shown:
 
Are we unable to utilize this on contained parts in the part studio?
Any feedback or thoughts would be appreciated.

Aidan_Benysh

I have returned with new knowledge, and even a solution. As my original problem was to create individual, characteristic name for parts the onboard name generator did not suit my needs [P-4002 is individual but not characteristic as to be usable by floor operators]. Sheet metal parts are the bulk of our workload so that is the main focus. What is most important to me is the size of the part as it will be cut on the laser/waterjet/plasma. This same information is also most important to the operator of said machine.

Previously as a stop gap solution I was using the StockSize featurescript [https://cad.onshape.com/help/Content/manage_procompany_account.htm?cshid=company_properties#CompanyProperties]. I would then use the output from running this as a Property - in the sample document it is shown the original creator used this to populate a BOM table - which could be called under export rules. Due to some change in ~April 26, this stopped working. Not sure if it was a change in Onshape or a change in the StockSize that has stopped this from working.

The StockSize featurescript is too complex/out of my depth so I wanted a tool that would be simpler. Returning to the original problem, below is a featurescript that would pull the flat pattern, create bounding box, arranges the dimensions, and give a string output. The code as created is here:

FeatureScript 3008;
import(path : "onshape/std/common.fs", version : "2695.0"); 
import(path : "onshape/std/sheetMetalUtils.fs", version : "2695.0");
import(path : "onshape/std/evaluate.fs", version : "2695.0");
import(path : "onshape/std/units.fs", version : "2695.0");

annotation { "Property Function Name" : "computeFlatPatternSize" }
export const computeFlatPatternSize = defineComputedPartProperty(
    function(context is Context, part is Query, definition is map) returns string
    {
        try silent
        {
            // Try to find the flat representation of the given folded part
            var flatPart = qCorrespondingInFlat(part);
            
            // Fallback: If empty, check if 'part' itself resolves
            if (isQueryEmpty(context, flatPart))
            {
                flatPart = part; 
            }
            
            if (isQueryEmpty(context, flatPart))
            {
                flatPart = qEverything(EntityType.BODY);
            }
            
            // Final check
            if (isQueryEmpty(context, flatPart))
            {
                return "BrokenA"; 
            }

            // Evaluate the 3D bounding box around the sheet
            const box3d = evBox3d(context, {
                "topology" : flatPart,
                "tight" : true
            });
            
            // Extract the 3 overall sizes
            const dimA = box3d.maxCorner[0] - box3d.minCorner[0];
            const dimB = box3d.maxCorner[1] - box3d.minCorner[1];
            const dimC = box3d.maxCorner[2] - box3d.minCorner[2];
            
            // Sorting logic for 3 dimensions (thickness, width, length)
            var minDim = dimA;
            var midDim = dimB;
            var maxDim = dimC;

            if (minDim > midDim) { var tmp = minDim; minDim = midDim; midDim = tmp; }
            if (midDim > maxDim) { var tmp = midDim; midDim = maxDim; maxDim = tmp; }
            if (minDim > midDim) { var tmp = minDim; minDim = midDim; midDim = tmp; }
            
            // Convert internal meters to inches and round to 2 decimal places
            const t = toString(roundToPrecision((minDim / inch), 2));
            const w = toString(roundToPrecision((midDim / inch), 2));
            const l = toString(roundToPrecision((maxDim / inch), 2));
            
            const resultString = t ~ "x" ~ w ~ "x" ~ l;

            // DEBUG PRINT
            println("Flat Pattern DXF Debug -> Output: " ~ resultString);
            
            return resultString;
        }
        
        return "BrokenB"; 
    });

This code is probably not optimal and the debugging methods are basic but it appears to work.

This outputs a computed property that is "computeFlatPatternSize" this string gets hidden away in the document.

For the next step we create a custom property in the company settings. I called this property "stockSizeProperty" since it already existed from the previous stop-gap solution. The "stockSizeProperty" then can become a computed part property referencing a working version of the "computeFlatPatternSize" property. Do this while selecting the categories Part and Part Studio to be Active with scope of Part and Part Studio respectively.

Finally, under preferences we can change export rules for the file types as necessary using the "stockSizeProperty" in the proper naming convention. I partnered this with a few other properties to further characterize the files. See the image below.

These do seem to have a 'stack' where the order does matter as to how they are applied. [This seems to be trial and error and I don't know how that works] You can see this on part studios where the regeneration time is long, where upon export the original file name will appear then change very quickly once the export rule is applied by the system.

Once these things are complete the result can be seen in the image below.

I hope this helped somebody, but if nothing else I wrote this just to remember what I did next time it breaks.