Making "Default" config identical to one other existing config

SOLIDWORKS API/VBA Macros
1

Hello,
I am working on a tool to help us dissolve some of our configured part files into files, each with one config. So instead of having n part numbers in 1 file we’ll be back to having 1 part number per 1 file.

I have not done much with configurations and I’m trying to find how to more or less copy a derived config back to the Default config. Or edit the Default config to be identical to a specific derived config. I think I’m looking for it in all the wrong places, I don’t even have a start.

2

Hmm. I vaguely remember a tool called Config or Data Ripper by Lenny's SolidWorks Resources.

Is this what you are looking for ? Also, one of @artem’s tools can probably do that for you…

Happy to write something together if we do as opensource. :smiley:

1 Like
3

I looked at Lenny’s website a bit. Looks like it’s been there a long time.

I asked similar question over at the other new cad forum and did get a good pointer. I’m not well versed in using Configurations in SW so had blinders on. I had tried making a new config but I didn’t understand that it would copy the active config, bit of a duh moment there. Also I was just going about it wrong and kept making another derived config. Once I found the IModelDoc.AddConfiguration3() instead of using the IConfigurationManager.AddConfiguration2() method I could add another root config.
Edit_20210902: Since I’ve made a mess of this thread by posting progress then asking follow questions I decided to come back and highlight the multiple solutions.
The instruction shared was:
1) activate desired config
2)create new [root (not derived)] config with temp name
3) delete Default config and all it’s dependents
4) rename new config to "Default"

      swModel.AddConfiguration3("_Default", configNameToKeep, "", 0);

      swModel.DeleteConfiguration2("Default");

      Configuration c = swModel.GetConfigurationByName("_Default");
      c.Name = "Default";
1 Like
4

Are you basically trying to save each configuration per file?

5

pretty much. Most of the configs, the ones that have a part number will be saved out to a file with only one config “Default”

I’ll put a step by step here in a few. I had a process mapped, but it’s changed as I have learned more of what’s available.

1 Like
6

have a process working that will take a configured file of a couple hundred configs down to one desired config and deletes all the suppressed features. I fell like I’m getting close to having the PDM side of it done; initial check in, check out, set variables, check in.
I noticed the file size is still large at ~1.5MB, nearly the same as the file with couple hundred configs. Part files of similar complexity are a few hundred kB. The feature tree looks pretty empty, I don’t see anything that could be causing the bloat.

Does anyone know how to ask SW to clear out the trash in the file from the deleted features so the file size gets back down to reasonable size?
Edit:20210902: Eddy provided the setting needed to get the file size down.
Tools > Options > System Options > Performance and select Purge cached configuration data.
set to ON?
thank you Eddy.

image
image286×692 21.8 KB

7

Hi Ben,

Do you have
Tools > Options > System Options > Performance and select Purge cached configuration data.
set to ON?

another idea:
Force rebuild all configurations (QTRL + SHIFT + Q) and save of course.

2 Likes
8

Check the macros here

3 Likes
9

Hi Eddy, I had been working on other edits but just got back to this and can confirm your suggestion was exactly what I was missing. Thank you.

1 Like
10

Glad i could help
Eddy

1 Like
11

Been running on and off for a couple of days now.

  1. Connect to SW app
  2. wait for file to be opened
  3. read configs on button press
  4. save the checked configs as individual files with supressed features deleted on button press.

Unconfigure

2 Likes
12

That looks sexy!

Btw, you have shave a lot of time you ditch the Winforms UI and use a console application.

1 Like
13

I often change my mind between console or forms app after I get started. I completely agree though about dropping the GUI for speed. Not saying I’m doing it right, but I’ve learned that when the input set is not fully defined the amount of planning and programming time rises exponentially as I try to identify and address more and more of all the possible ways my program can go off the rails due to unexpected inputs. I use a lot of if(this is expected) else (wth?) in my code where the else should never happen and I put a break on that line or throw exception in the else body. However, having a graphical window into what it’s doing is often helpful to catch still other SNAFUs in the data set that I didn’t realize I needed to deal with. Trying to read lines whizzing by in the console is a bit less helpful.

Once I have these parts unconfigured I’ll likely never run this again so efficiency nearly at the bottom of the list of priorities for the app. Since I’m working and producing in a live data set that is constantly in motion and hopefully used for 20+ years, consistency and fail safe behavior were priorities.

I have much to learn about efficiency on the SW API side. I’ve read but still don’t understand Artem’s in process vs out of process articles/blogs. But even that on the simple parts that don’t have a lot of suppressed features to delete the SW API stuff would finish before PDM had added the file to the vault and the unlock would fail. So I added a bit to make sure the file had been added if the unlock failed.

This is just about done with all the configs/part numbers that didn’t already have their own sldprt file. and it’s somewhere around half of the total. So next I’ve been working on dealing with the list of the existing file that needs to be saved over (because the model does not have the same internal geometry IDs as the proper hardware models from the configured file). They pretty much all have many where used with mates and drawing annotations and multiple levels of the where used tree, so that’s all going to blow up when I make a new version of those files. First, I was just making new .sldprt files, next I’m adding code to check out the existing .sldprt file and save the unconfigured file over it as a new version. If all the existing where use of the file stay using the current version all will be well, but we all know there’s no way (out of the box) to get PDM to default to always get referenced version we will have serious blowups if I do this. So we have A LOT of work to do updating mates and drawing annotations in all the where used of the ~400 hardware files that I need to make a new version of that will have all different internal IDs.

If we could just do a “where used” of an internal ID of a part in drawing or assembly and replace it with the know new ID for the new model my life would be VERY VERY much better. But I cannot find those API calls.

1 Like
14

Thank you Gupta, I watched this and looked at a few other macros. Thing is I have nearly 1000 configs to break out and I need to save them in certain places based on the existing (messy) data set. The removing all but one config and deleting suppressed features is just a small portion of what the tool must do.