SOLIDWORKS: Yellow Colored Cells of Derived Configurations?

Configurations have been a part of SOLIDWORKS since the beginning release in 1995. They allow you to create several different iterations of a component or assembly without needing to create new documents. This could be done by manually creating them and changing values or using an Excel design table. In SOLIDWORKS 2001+ (anyone else remember plus releases?!) Nested Configurations (now called Derived Configurations) were added to the core of SOLIDWORKS. This allowed you to create a child configuration where all the parameters were linked to the parent unless you override a value, then that parameter was unique to the child and no longer linked to the parent. Finally, in 2008, SOLIDWORKS added the ‘Modify Configurations’ Dialog box to edit long lists of configurations without needing excel. The table could be saved and accessed at a later point in time.

This brings me back to today’s topic; Why do yellow colored cells show up for some configured components? Now I have used SOLIDWORKS since 1998 and this question had me stumped the other day when one of our customers was also confused. I had never seen this before, and I was intrigued to not only understand what this color meant, but also, when was the functionality added? Upon initial glancing at the configure component window there were indented rows, with some of the cells white, and others yellow. I knew that these were derived configurations, but this was the first time I had seen a yellow cell in the modify configuration window. I have used and created configurations in the past with manual methods, using the configure window, and also using design tables, but apparently, I have never used or created derived configurations because I would have know what this yellow color means.

The yellow color means that the value indicated has been changed and no longer linked to its parent. Let’s look at the example below to help us understand this coloring of cells.

In the example of this “Super Block” there are 6 different configurations. There are two base sizes, Original, and Size1. These two configurations vary only be one dimension, the width or length in the X direction.

Size1 also has 3 variations (Derived Configurations) on the original:
1. Hole moved to a new position (Size1 – Hole Moved)
2. Minor modifications to the overall size (Size1 – Minor Size Adjustment)
3. One with no hole (Size1 – No Hole).

Finally, there is one last configuration (Size1 Adjusted – No Hole), which is a child of ‘Size1 – Minor Size Adjustment’, where it should inherit the changes from its parent AND the hole is removed.

If a variable was changed in the table for any derived configuration, the cell turns yellow to show that this value is not linked to the parent any longer. “For Size1 Adjusted – No Hole” you can see that the dimensions for the Block Sketch, and Block feature show as white, meaning that they are still linked to the parent.

If I change a dimension of a parent configuration from the table, each derived configuration that is still linked should update. Shown below, a change is made to Size1, Block Sketch, “Y” value from 70mm to 90mm; this change propagates through all derived configurations properly. Below you can see highlighted in green that the value for Y changed for all 3 of the derived configurations automatically.

However, these links only work one level deep; one root configuration, and one child. If a change is made to a derived configuration where there is an additional child/derived configuration, the change DOES NOT propagate to its children. Seen below, for configuration “Size1 – Minor Size Adjustment”, Block Sketch, value Y was changed from 65mm to 80mm.  Confusingly, the table initially shows that the value is still linked.  Its only after the changes are saved and the table re-opened that the additional derived configuration (Size1 Adjusted – No Hole) did not update and the link is now shown as broken (yellow color).

So, the next time you want to make derived configurations, remember that these links currently only work with the first derived level of configurations (as of 2020, SP1.0). While you can create additional derived levels of configurations, I would suggest you use Excel to properly manage the links to the values of each child/derived/nested configuration. And in the future, who knows, maybe we will see some ability to link each dimension to a parent, or some kind of indication, or maybe it will all just work. I don’t have a crystal ball to tell what will happen, what I do know is that change starts with you; if you or someone you know would like this function, fill out an enhancement request. Or even better yet, upvote some that already exist. (Like this one: SPR 591162)

Alex Worsfold
Application Engineer – CSWE
Computer Aided Technology, LLC