"Variants" in Enterprise?

S1mon

I'm working on setting up our Enterprise system. A bunch of parts that we use are painted in a choice of colors. I think of these as "variants" of the part number. So if the base part number is 1234, the variants might be 1234-01 (black) 1234-02 (red). Not every part has a variant. Variant -01 might be black for a bunch of projects, but not all. I'm thinking the color ways would be defined in a separate (text?) document with L*a*B, delta-E, inspection processes, colorfastness, abrasion specs, etc....

How should we handle this in Onshape Enterprise? Should the variant be captured in a custom property? Is there a way to concatenate the part number and variant (if it exists) into title blocks or other places where there would normally just be a part number?

eric_pesty

I ended up creating a custom feature based on @Evan_Reese's Part Color for our "standard appearances", which includes powdercoat, PCB colors and standard metal colors (aluminum, galvanized, etc...) so that we would use consistent ones.

You might be able to use variable studios now, but I'm guessing you'd want to use the hex value in there and then either use these with the built in "configured properties" or a "part color" feature.

Or you could not use configurations and just pull the color values from a variable studio and set them there (but you'd have to either update a version or have everything in the same doc for it to take effect.

Haven't experimented with it but I'm guessing you can't configure a variable studio?

romeograham

I think it could be a Custom Property, for sure.

Then, you can concatenate to your heart's desire on drawings, using Custom Properties from the part.

Finally - look up Export Rules - if your Custom Properties are set up correctly, you can build a nice filename for exports that could include your color way as part of the part number as you suggest.

We have ours set up to build the filename with: Part Number-Revision Size Description (from Document Name)

This give us PartNumber-Rev which is really important - and the "document name" gives breadcrumbs to know which Onshape document the part / drawing came from. This is a custom property we have to remember to populate manually.

I think with a combo of custom properties and export rules, you can get what you need.

S1mon

@romeograham

I had seen the export rules. It's puzzling that "document name" isn't available as a variable in the export rules. That seems like a good improvement request.

romeograham

You're right, @S1mon . There are a couple of funny things about Custom Properties and export rules that require a bit of duplicate work when entering properties. For us, we have to remember to NOT enter the "size/Capacity" information in the "description" field of our custom properties, otherwise it will appear twice when we export the parts / PDFs. You'll need to work out something to automate it that works MOST of the time, but has the flexibility to be overridden for all the edge cases that will pop up.

adrian_vlzkz

This seems like a good use for Configurations, have you tried them?  You can configure the Custom Property and the Appearance in each Variant.

S1mon

@adrian_vlzkz
If this was just in a single part, configurations would be enough, but I'm trying to make this work across multiple parts/documents, with a single place to set up the variants. We want a standard company palette of colors (referenced by a variant code) which are defined in a single document. In theory, the new variable studios could be a way to define the RGB values, but I'm still thinking that making our own Featurescript - similar to @Evan_Reese's Part Color - would be the best way to go. I just haven't gotten around to solving this issue yet.

eric_pesty

I ended up creating a custom feature based on @Evan_Reese's Part Color for our "standard appearances", which includes powdercoat, PCB colors and standard metal colors (aluminum, galvanized, etc...) so that we would use consistent ones.

You might be able to use variable studios now, but I'm guessing you'd want to use the hex value in there and then either use these with the built in "configured properties" or a "part color" feature.

Or you could not use configurations and just pull the color values from a variable studio and set them there (but you'd have to either update a version or have everything in the same doc for it to take effect.

Haven't experimented with it but I'm guessing you can't configure a variable studio?

S1mon

@eric_pesty
Are you putting some sort of color value or code into a part property using your custom feature?

eric_pesty

@S1mon
No I am not, the feature has drop downs and enums. I would have liked to do a lookup table (to avoid having to do "IFs" for each "category" but then it wouldn't be configurable. Arguably you might be better off having separate features altogether for "paints", PCB colors, etc, I'm still not sure what the best approach would be. It just makes the code a lot more complicated the way I have it but as long as I don't add to many new categories it should be manageable and that's way it's just one feature for any "standard" color...

Here's what it looks like. I'm not making it public as these are what make sense for us and I might decide to break things at any time! but feel free to rip it off all you want!

https://cad.onshape.com/documents/b7676023abc9f7881a3d67e2/w/43858222fd5c9989fc049f47/e/0db44b78073a3fb1164408b2?renderMode=0&uiState=62be0ca448fc0b125944af9e

S1mon

This problem is still stewing around...

Where I am now is that I'd like to create a custom FS which will create some (say 2-5) configurations which can then be selected to change the color of a part. The actual color changing would be done similarly to what @Evan_Reese and @eric_pesty have done. These configurations will also set a part property called "Variant". In the FS I would define the palette of colors (say 15) which our company plans to produce in a particular set of parts. Any given part might only be offered in a subset of those 15.

1. Can I create configurations with a custom feature?
2. If this custom feature allows me to select a subset of the palette as available colors for a particular part, and later I edit that feature to select different colors, can the custom feature add/remove configurations?
3. Is there a way to modify the export naming rules to only add a property to the string if it has a value? (I suppose I could make the Variant property include the dash and if there are no variants, the property would be null, and could still be part of the string)

Is there some other better way to do all this?

EvanReese

You can configure a custom feature, like any other feature if that's what you mean. No feature can create or edit the configuration table though. The API could, but that's over my head.

Here's an example of one approach, which could definitely stand more thought and optimization. If you want to limit the list of available colors for each part to some predefined subset of your main list, there are a few ways to handle it. I opted to actually just make a new custom feature per part and change the UI to only that subset of colors. You could also make one feature with a drop down to pick which part you're using it for, but it might be more error prone, and would essentially do the same thing with the same amount of work.

There are some abilities to process strings. For example, you could only set the variant property if the string isn't empty. I haven't mocked that up at all, but it might look like:

if(definition.myString != "")

S1mon

@Evan_Reese

No feature can create or edit the configuration table though. The API could, but that's over my head.

I was starting to get that idea, but it's amazing how hard it is to search for that information. Things change over time, so an older forum post may not reflect the current state of reality, and the reference material is tricky to dig through for that type of answer.

Thanks for your example. Way above and beyond what I was hoping for. It definitely makes me think about my problem a little differently.


I've now got my custom feature which will set part/face/feature colors based on a enums which define color names, annotations, variant codes, and the colors themselves. I also write the variant code to a custom property for the selected/affected part(s).

This can be configured easily enough, but it's frustrating how the configuration names need to be manually created. The column "color" comes from the custom FeatureScript, but for each part studio or assembly that gets configured, I need to manually write in the name. I guess this is where API stuff could come into play, but like you say, over my head too. I'm also rediscovering that assembly configurations can't change the instance configuration within a subassembly, unless that subassembly also has configurations.

I was hoping to manage a colorway as a top level configuration without lower level configs other than at the part level, but I suppose that isn't how it would work in reality. So yeah, lots of work, but at least now people won't have to cut/paste so many things, and configure appearances directly, which is clunky and error prone. The variant codes will get written to the parts directly too.

eric_pesty

@S1mon
There might be a way to control the color from the top level without duplicating configs through your structure using a configuration variable that is a HEX in parts and "sub" assemblies, this way when you set your top level config variable it can propagate the code downwards.
The benefit is that you only need to set what colors are available once at the top level and it should propagate down...

@Evan_Reese's color FS doesn't support it (we discussed a while back and if you change it to accept a hex code you loose some other function, don't remember the details...) but might be worth investigating and he showed me an example using a "wrapper" to get to work (see below)...

The dropdown from the assembly can have an arbitrary list of Hex values and the part will change accordingly. If you could tie that value to an assembly level config variable you'd be able to propagate that down an assy structure but I can't seem to get it work for some reason...

https://cad.onshape.com/documents/6bc71eac4d11d3aecd10fc74/w/01f622cee2fa8a4b64e1c3f7/e/b20e435244cd4468a288e060?configuration=List_4hS9VX0bNt9fez=Grey;Size=0.1+meter&renderMode=0&rightPanel=configPanel&uiState=62d1ea39418acb5a14d78e0c

Edit: haven't tried lately but I know it worked with RGB values, the downside was that you needed to propagate 3 values instead of just one using Hex but the same principle should work...

S1mon

@eric_pesty

If it was just one color which need to cascade down the assemblies to the customizable parts, that would be an interesting solution. Unfortunately, there are a few things which are involved with our color ways. Some parts (metal and plastic) are painted, some are molded in silicone, and some are injection molded hard plastic in color. Each group of items colored the same way are likely to all be the same color, but not necessarily. A color way for the product will involve at least 

I will just have to be happy that at least there's only one place to define the colors, so it's less likely that CAD users will config appearances with a color which is close, but wrong, or just completely wrong. We will still need to be diligent about the configs when we add new color ways, but it's less work than it would have been before.

I still feel like color ways should be much easier to manage than this, but it's nice to be able to write FeatureScript which controls things.

S1mon

@eric_pesty

BTW I believe there's a bug in your CMHColors enums. You have all the values as color(1 / 256 * red, 1 / 256 * green, 1 / 256 * blue, 1). 24 bit color values are normally 0-255 for each byte, so the conversion factor to 0..1 should be 1 / 255.

In our company FS, I created a simple conversion function to make the enum consts more readable.

function RGBcolor(red, green, blue) returns Color

{

    return color(red/255, green/255, blue/255);

}

Also, since all of your colors are opaque, you can just omit the alpha.

S1mon

Ok, so now I'm running into the issue that it seems like setting appearance only works if the parts have no appearance set manually. Am I understanding this correctly? If so, how do I "unset" the appearance of a part so that setProperty works?

@Evan_Reese @eric_pesty

 

eric_pesty

@S1mon
Good catch on the 0-255 vs 1-256, not sure how I ended up with that, I'm pretty sure I "stole" that from somewhere but apparently not from @Evan_Reese's part color (which I thought was where I got most of my "inspiration"...) as he's got 255 in there. That's a bit of a mystery as my instinct would have been to use 255!

I think you have to "reset" the part properties ("reset all" button in the property dialogue). I just don't know if/how you can do it in FS...

S1mon

@eric_pesty

Thanks for the "reset" clue. It works, but it sucks since it clears a bunch of properties at the same time. There's no option to reset just appearance. I'm going to create an improvement request.

eric_pesty

@S1mon
Yeah forgot to mention that!
It's definitely best to make sure you don't apply any appearances manually if you are going to use a feature for it! But if you are adding it to existing parts in a pain as you have to re-fill all the properties after you do that.

S1mon

@eric_pesty

Here's an improvement request. Feel free to add on...