Dirty Files and what causes them.

[Rob]

Hi All!

I don't suppose I've ever really delved too deep into this topic, but as the size of my assemblies is increasing it becomes an essential consideration.

In the past I often noticed that even when you open a file that has just been saved on reopening it there will instantly be that little asterisk next to the file name and SW will want to save it and along with it the entire dependency chain.

As I alluded with smaller assemblies and drawings, where rebuilds and saves take fractions of seconds it's no biggy but now my rebuild/ save times are getting up into minutes and I do not have the time to sit watching SW rebuilding and saving files that I know 100% are up to date.

This morning I noticed my top level assembly had developed this annoying trait, so I decided to diagnose the cause.

My System Options External References are

• Open Referenced Documents With Read Only Access
• Don't Prompt To Save Read Only Files(discard changes)
• Load Referenced Documents: Prompt

I opened up my components one by one to see where the root cause lay.

The first one has two configs with an inserted part that is configured to match.

image.png

All of my parts have a rebuild save mark for every config, so the parts contain full data sets with every save.

When I open the part I am presented with these options

image.png

When I select

• Don't open any referenced parts - all is good.
• Open any documents that have changed - all is good ( because nothing has changed)
• Open All referenced documents - I get the asterisk.

This is despite no changes and the readonly setting set... and heres the kicker and why I think this is possibly a bug.

If I already have the referenced part open there is no problem.

So why should merely opening a referenced part cause the file to be flagged dirty?

What do you think?

Do you know any other causes / workflows to avoid this problem?

[Merovingien]

you are using the famous "PRT in PRT" aka "Ext. Ref." in SW
that feature can make running SW very slowly.

if you only need to add "removing volumic feature",
you can consider the "ASM, with PRT inside, and feature to remove volumic"

another thing, if you want to work with the "Ext. Ref."
is to know to use it more efficiently.

are you needing a "Dynamic Ext. Ref." or not ?
at the beinning of using it for PRT, it's dynamic.
but in many cases, after the worked done, turn it into the "Static Ext. Ref." is enough.

i saw you work with the "Read Only" workflow.
So you may understand the benefit of "Static Ext. Ref."

to set it, right-click on the top of PRT with Ext. Ref. inside, go to the Ext. Ref. menu,
and choose "Lock",
So SW will stop trying to calculate-evaluate it.

and if you need to update it for a change, simply unlock it, do the change, relock it after.

[AlexLachance]

Hi All!

I don't suppose I've ever really delved too deep into this topic, but as the size of my assemblies is increasing it becomes an essential consideration.

In the past I often noticed that even when you open a file that has just been saved on reopening it there will instantly be that little asterisk next to the file name and SW will want to save it and along with it the entire dependency chain.

As I alluded with smaller assemblies and drawings, where rebuilds and saves take fractions of seconds it's no biggy but now my rebuild/ save times are getting up into minutes and I do not have the time to sit watching SW rebuilding and saving files that I know 100% are up to date.

This morning I noticed my top level assembly had developed this annoying trait, so I decided to diagnose the cause.

My System Options External References are

• Open Referenced Documents With Read Only Access
• Don't Prompt To Save Read Only Files(discard changes)
• Load Referenced Documents: Prompt

I opened up my components one by one to see where the root cause lay.

The first one has two configs with an inserted part that is configured to match.

image.png

All of my parts have a rebuild save mark for every config, so the parts contain full data sets with every save.

When I open the part I am presented with these options

image.png

When I select

• Don't open any referenced parts - all is good.
• Open any documents that have changed - all is good ( because nothing has changed)
• Open All referenced documents - I get the asterisk.

This is despite no changes and the readonly setting set... and heres the kicker and why I think this is possibly a bug.

If I already have the referenced part open there is no problem.

So why should merely opening a referenced part cause the file to be flagged dirty?

What do you think?

Do you know any other causes / workflows to avoid this problem?

I've jumped to the conclusion that it's an issue caused by outdated templates but I've no idea what causes it to be honest. If you ever do figure it out though, I'd like to know.

[Rob]

Cheers Merovingien

Yes, I lock them when I can, but this one needs to update.

One problem I have found is that when unlocking references - it causes errors in the parts

[mattpeneguy]

@Rob,
Can you post your part? Also, get an AE from your VAR involved. The more eyes looking at this the better. This is something to identify and it's very possible it is a bug.

I think I have run into this before, but I'm not sure I ever dived in and sorted it out.

I had an ASM a while back that would actually throw an ! error. It was one I created before I knew as much as I know now and had A LOT of components in the ASM. I now know to break it into sub assemblies for exactly this type of problem...Unfortunately, I don't remember what I did to fix that one.

[AlexLachance]

Cheers Merovingien

Yes, I lock them when I can, but this one needs to update.

One problem I have found is that when unlocking references - it causes errors in the parts

Rob,

Thinking out loud here, but could you have a cross-reference, or a file with the same name in 2 differing locations?

Example: First assembly would load file with reference A. Top asssembly would load file reference A2. So when you open with no referenced parts, all would good.
If you ask it to open any document that have changed, all is still good. because nothing has changed.
If you ask it to open all referened documents, File A2 loads first, overriding the reference into the first assembly, causing the first assembly to require a save or rebuild.

[Rob]

@Rob,
Can you post your part? Also, get an AE from your VAR involved. The more eyes looking at this the better. This is something to identify and it's very possible it is a bug.

I think I have run into this before, but I'm not sure I ever dived in and sorted it out.

I had an ASM a while back that would actually throw an ! error. It was one I created before I knew as much as I know now and had A LOT of components in the ASM. I now know to break it into sub assemblies for exactly this type of problem...Unfortunately, I don't remember what I did to fix that one.

Hi Matt

I am using some custom features from my Add-In, so uploading these files isn't going to be much use. If I can't solve it I and I have time I might prepare a simplified assembly using only native features.

I have been in contact with my VAR but honestly, the help is hardly ever worth the time investment. Most times contacting my VAR is for catharsis, when I want a solution 'the forum' is the best place.

The irony is I have simplified my assembly structure and created new simpler subs. I did this by creating copies of my original components and deleted some features - and this may have been the step that introduced this problem, because I'm 99% certain it was working better before.

[Rob]

Thinking out loud here, but could you have a cross-reference, or a file with the same name in 2 differing locations?

Example: First assembly would load file with reference A. Top asssembly would load file reference A2. So when you open with no referenced parts, all would good.
If you ask it to open any document that have changed, all is still good. because nothing has changed.
If you ask it to open all referened documents, File A2 loads first, overriding the reference into the first assembly, causing the first assembly to require a save or rebuild.

Hi Alex

Could be.

My project folder was getting a bit messy, so I packed and go'd to a zip file - then moved all my dev work to a new directory.
And then extracted new versions of just the files I was actively working on back to my project folder.

I was concerned SW might still look at the old files (not quite ready to delete them) - but they are in a brand new directory that SW has never seen?

[AlexLachance]

SW shouldn't be able to find it then in general.

You could do a quick check by going to file­>view reference and then copying that list to an excel file and viewing if the reference of the file that you speak of, lies somewhere else inside that list.

[mattpeneguy]

SW shouldn't be able to find it then in general.

You could do a quick check by going to file­>view reference and then copying that list to an excel file and viewing if the reference of the file that you speak of, lies somewhere else inside that list.

Yes! If you are doing anything with Pack 'n Sometimes Go, always check the references because those files sometimes don't go. I like to add a prefix like "v1-", to prevent this scenario and to easily be able to see that the files are correctly referenced in the ASMs from the feature tree. Another thing you can do is zip the original folder and delete it to prevent SW from referencing the old location.

If you don't like the v1- at the beginning for your finished product, you can always use PnG again and "Select/Replace" to remove that text and create a new version.

[Frederick_Law]

I did find that constant traffic light is because of circular ref.
Happen when I add a part to the ref master assembly and re-ref that to the master sketch.
The re-ref may not be intentional.
While editing Master Sketch in assembly, SW could and will pick anything to ref. It is very easy to pick wrong part.

[matt]

I just finished a project with some heavy external references. In my view external references are better than in-context assembly references. Don't criticize stuff just out of habit.

I did recently have one part that went to 1.8 GIGAb. 1 part. This part did have some wacky complex geometry, and a lot of fussy detail.

SW adds a lot of external data including parasolid data for bodies in various states of rollback. So rolling back and using multiple bodies I think really compounds things (which I do extensively). Plus, if you have configurations, that really really compounds things (I don't use configurations, in general). And it also stores information about file locations, so if you move your parts around a lot or reference them from different locations, it's storing information about that as well. There are properties of features, and info about when it was edited....

Some of this is just text data, but the parasolid stuff can get really big, and any time you have even text data repeated again and again for hundreds of features, it can get out of hand.

This is part of the reason I try to avoid unnecessary complications in assemblies, including configurations (as long as I can't avoid it, and then always using a table when I can't avoid configs), display states, in-context, virtual, and things like that. There's no need to push your luck with assemblies just to see how many cool things you can add.

I think this happens in parts with external references and in assemblies. SW stores a lot of junk data inside the files. I thought there was a purge tool at some point. Memory starting to fail me...

Sometimes data just gets left behind and is never purged, and can just build up.

As for the "dirty bit" I know for a fact that it is just there sometimes, and this has been the case for more than a decade. When I worked at a reseller I'd submit parts whenever I could, but I don't think they ever figured it out. You can fix things sometimes by deleting features. You don't have to have a circular reference.

And losing references to edges or things like that? That's where I spend probably 80% of my modeling time. With surfacing you have to reference edges, and all it takes is the tiniest shift and normals flip, directions change, selected become deselected (trim feature). If you want to get real work done, just accept that the tool is flawed deep down inside somewhere, and it has emotional problems we can't fix. Just deal with it.

The big problem I've been having recently is when you use Convert Edges (maybe including when you select a face to convert all edges around face) in combination with regular sketched elements and then sketch trim something. Very often after an unrelated change the trim gets undone, and you've got a wacky hot mess on your hands.

Ahhh, just venting. Had a frustrating last couple of months with this stuff.

[Rob]

I did find that constant traffic light is because of circular ref.
Happen when I add a part to the ref master assembly and re-ref that to the master sketch.
The re-ref may not be intentional.
While editing Master Sketch in assembly, SW could and will pick anything to ref. It is very easy to pick wrong part.

Yo Flaw

I started out with external refs from my skeleton (reffing global variables in equations to control component suppression and spacing) but this created a nightmare for rebuilding, so I spent the weekend stripping out all the external refs and I automated the updates by api, one file at a time. This cured the rebuild issue, but I still have the save issue.

The only thing the skeltons do at assembly level now is provide faces to mate to.

I tend to agree with @matt that sometimes SW files accumulate artefacts that cannot be purged.
Maybe a saveas could help?

[matt]

...

I tend to agree with @matt that sometimes SW files accumulate artefacts that cannot be purged.
Maybe a saveas could help?

It's too bad we don't have more folks from "the old days" here. We went through a lot of these issues and had some sort of fix for them. I think @SolidMuse Anna Wood helped figure out a lot of this stuff. We were doing things like turning the part/assembly to wireframe, pushing the geometry off the screen before saving, making the window as small as possible, extruding a box around the part as the last feature, etc...

But then SW outsmarted us by taking a standard iso image of the model as a thumbnail preview.

I can't remember all this stuff on my own. Anna, are you there? How about @mirisj Jeff M? Surely @mbiasotti would remember some of this?

[Frederick_Law]

I don't use assembly ref.
The Master is the only one ref a Master Assembly to get ref from customer part and purchased parts.
All modeled part ONLY ref Master "Sketch".
Usually mate is not needed since every part is modeled in place from the Master.
When mate is required, Master is put into the assembly and part mate to Master.
Completely avoid mate between parts. Unless necessary.

[AlexLachance]

I did find that constant traffic light is because of circular ref.
Happen when I add a part to the ref master assembly and re-ref that to the master sketch.
The re-ref may not be intentional.
While editing Master Sketch in assembly, SW could and will pick anything to ref. It is very easy to pick wrong part.

Yo Flaw

I started out with external refs from my skeleton (reffing global variables in equations to control component suppression and spacing) but this created a nightmare for rebuilding, so I spent the weekend stripping out all the external refs and I automated the updates by api, one file at a time. This cured the rebuild issue, but I still have the save issue.

The only thing the skeltons do at assembly level now is provide faces to mate to.

I tend to agree with @matt that sometimes SW files accumulate artefacts that cannot be purged.
Maybe a saveas could help?

Rob,

Save-as indeed does a major purge of leftovers. There might be some things left over though. I've seen file be 4 times smaller after a save as

[SPerman]

I have been in contact with my VAR but honestly, the help is hardly ever worth the time investment. Most times contacting my VAR is for catharsis, when I want a solution 'the forum' is the best place.

This should be the first thing taught to anyone using SW.

[jcapriotti]

I had this with a part that had multiple configurations and each had MBD GDT and dimensions. Just opening the part would flag it. I removed all MBD content and rebuilt all configurations, then inserted it into another part and its fine now. You can open the part that contains the inserted part and nothing flags as dirty. 2021sp2

[matt]

I have been in contact with my VAR but honestly, the help is hardly ever worth the time investment. Most times contacting my VAR is for catharsis, when I want a solution 'the forum' is the best place.

This should be the first thing taught to anyone using SW.

To an extent I agree. When it's a "how to" or has more to do with modeling than with SolidWorks, or best practice, or ... or.... or...

But there are some tools that users just don't have. Plus, and I gotta say this out of love, guys, some time users believe the stupidest stuff.

The one big advantage that VARs have is that they can contact SW directly. I agree that a lot of VARs just play goalie with user issues - anything to keep from allowing you to fool them into actually writing something up as something other than PEBCAK. But, for certain things, actually a lot of stuff, you have to guide them to providing you with the right answer.

I've done a lot of tech support, and I've been on the customer side of a lot of tech support. I know users get shoved off a lot, or at least feel that way. But I also know that most user problems are self-inflicted, and if I took the time to troubleshoot every self-inflicted SW wound from users, there wouldn't be any time for real support.

Anyway, why isn't @Alin here defending himself?

[SPerman]

If Alin were my VAR, I would have a completely different opinion.

My communication typically goes like this:

ME: "I'm having this problem"

VAR: "Soldiworks doesn't handle that very well."

ME: "Have you reported this to Solidworks?"

VAR:

[Rob]

SUCCESS!!

So I've finally managed to get a clean open

Here's what I did

• worked my way through my assembly structure noticing which assemblies were causing a problem.
• closed all files
• opened each problematic assembly by itself and checked I didn't have any conflicts across configs eg unconfigured dims
• did a saveas - the funny thing was the asterisk was immediately there on the new file directly after saving, so I rebuilt and resaved.
• compared file sizes of new and old file. Most were slightly smaller, some were slightly larger ?
• deleted the old files and simply renamed the new files in win explorer
• opened top assembly - still had a dirty mark but when I dug down, most of the assemblies were correct and there was just one that was causing the problem.
  
  Nothing to it really - no external refs and never had been
  image.png
• I thought I'd maybe made a mistake or forgotten it - but I was 90% sure I had done it before so performed a few extra steps.
  • changed the active config
  • force rebuild all configs
  • repeated the saveas / rebuild / save again / close / delete old / rename routine.
• This fixed the problem with this sub, but not in the next sub up, so I had to work my way up all the way to the top.
• through superstition I followed all the above steps.

..And it worked!!

Now everything opens up contented.

I do not want to put you through any misery, but I made a recording of the problem here https://www.youtube.com/watch?v=XzOm1dzZXRo

I'm just hoping it sticks..

If not I'll probably write a macro to automate what I just did..

The funny thing is, the only time the mark was applied is when the higher assembly was open - when I opened them by themselves no problem.

Anyway that's another mostly wasted day behind me

[Rob]

you are using the famous "PRT in PRT" aka "Ext. Ref." in SW
that feature can make running SW very slowly.

if you only need to add "removing volumic feature",
you can consider the "ASM, with PRT inside, and feature to remove volumic"

Hi @Merovingien

I re-read your comment and noticed that you are suggesting using an assembly context instead of part - in - part.

I think that would work well in this case, because my inserted part is bringing in a surface which is used to make a cut. I dislike the cavity feature as it has caused me many headaches in the past, but offsetting surfaces at the assembly level is good.

Originally I opted for the part - in - part because I was inserting model dimensions, but they caused a problem so I ripped them out.
I think the massive benefit to an assembly context is for pack and go.

image.png

Here I bring in the same part in 3 configurations and the features get a number appended to them.

• ChamferCutter
• ChamferCutter1
• ChamferCutter2

In my experience pack and go cannot handle this scenario, so an assembly would solve that.. although it would mean an awful lot more assemblies.

Thankyou - I'll try it next time.

[Alin]

Anyway, why isn't @Alin here defending himself?

I am here, but I do not like playing defense. Offense is more to my liking.

@Rob let me know if you can share a file set with the problem you mentioned.

There can be many reasons for the appearance of dirty components and, lately, I am making a pretty good living by hunting them and teaching other would-be hunters how to do that (https://www.javelin-tech.com/3d/people/ ... -workshop/).

When I find the problem, I promise to share it with you.

[Alin]

A few years ago I presented on this topic at SWW. If you have SW 2019 or older, this presentation is still relevant.

Mind you, I had a limited time for the session, so I selected only 7 crime stories. When you attend the whole workshop you get to meet all villains, along with the detectives and the solutions.



This link will work for a week, so if you have a few minutes to spare, check it out.

Also, the description contains hyperlinks to each topic of the presentation, so you can skip the stuff you do not care about.

image.png

Description:

The video recording of the Breakout Session 344370 "Unexpected Villains in the Large Assembly Crime Story" presented by Alin Vargatu from Javelin Technologies at 3DEXPERIENCE World 2020.

Topics:
1. Agenda: 3:59​
2. Theory - Large Assembly Process: 9:31​
3. Crime #1 Face Level Appearances and Large Number of Bodies: 16:30​
4. Theory - Part File Anatomy: 33:36​
5. Crime #2 Inefficient use of Configuration Data by Older Versions of SOLIDWORKS: 38:25​
6. Crime #3 Hidden Features: 50:39​
7. Crime #4 Slow Selection in LDR mode: 57:42​
8. Crime #5 Unoptimized Flexible Assemblies: 1:02:49​
9. Crime #6 Old Version of Cosmetic Threads 1:12:12​
10. Crime #7 Dual Drivers for Dimensions1:23:00

[Rob]

@Alin you are a legend.

I followed your steps to diagnose the problem.

Open Large Design Mode and Update graphics.

image.png

Truly I am shocked that prior to SW2020 we cannot have any assembly containing 2 components displayed in different configs, because by logic at least one of them must be inactive.

I had a hunch this was the case when I had external references, but graphics data! really?
I'm Gob smacked. All my components have full configuration data.

And look at the message

'might' be out of date...

Flagged dirty without even checking?

We have a single license of 2020 so I can test it, but my boss won't be happy when I tell him we have to pay full backdating to upgrade our old license.

As an aside why do you suppose it worked for me when I performed a saveas for every file?

[Rob]

@Alin

I opened my files in 2020 and it works!

I haven't even updated my files yet.

Obviously I am very happy, but what makes me angry is I have spent countless hours with my VAR and they have never known any of this stuff.

Is it possible for you to be our VAR? even though we are in the UK?

[Alin]

@Alin

I opened my files in 2020 and it works!

I haven't even updated my files yet.

Obviously I am very happy, but what makes me angry is I have spent countless hours with my VAR and they have never known any of this stuff.

Is it possible for you to be our VAR? even though we are in the UK?

I have several clients from Europe. Usually they buy batches of 20 hours and use them for whatever they need: support, training, consulting... They like that I keep track of their time by the minute.

[SolidMuse]

...

I tend to agree with @matt that sometimes SW files accumulate artefacts that cannot be purged.
Maybe a saveas could help?

It's too bad we don't have more folks from "the old days" here. We went through a lot of these issues and had some sort of fix for them. I think @SolidMuse Anna Wood helped figure out a lot of this stuff. We were doing things like turning the part/assembly to wireframe, pushing the geometry off the screen before saving, making the window as small as possible, extruding a box around the part as the last feature, etc...

But then SW outsmarted us by taking a standard iso image of the model as a thumbnail preview.

I can't remember all this stuff on my own. Anna, are you there? How about @mirisj Jeff M? Surely @mbiasotti would remember some of this?

I am not remembering working through this. Not something I remembering being an issue for me.

[matt]

I am not remembering working through this. Not something I remembering being an issue for me.

Well, you did the plate with all the holes in it as the benchmark part. I remember that. At least I think I remember that. But again, the memory is the first thing to go, and I can't remember what goes after that...

[SolidMuse]

I am not remembering working through this. Not something I remembering being an issue for me.

Well, you did the plate with all the holes in it as the benchmark part. I remember that. At least I think I remember that. But again, the memory is the first thing to go, and I can't remember what goes after that...

Yes, the punch holder benchmark was my part...

[mirisj]

...

I tend to agree with @matt that sometimes SW files accumulate artefacts that cannot be purged.
Maybe a saveas could help?

It's too bad we don't have more folks from "the old days" here. We went through a lot of these issues and had some sort of fix for them. I think @SolidMuse Anna Wood helped figure out a lot of this stuff. We were doing things like turning the part/assembly to wireframe, pushing the geometry off the screen before saving, making the window as small as possible, extruding a box around the part as the last feature, etc...

But then SW outsmarted us by taking a standard iso image of the model as a thumbnail preview.

I can't remember all this stuff on my own. Anna, are you there? How about @mirisj Jeff M? Surely @mbiasotti would remember some of this?

My tricks are probably old and tired now, where I no longer actively use SW.

One thing I avoided at all costs was external references. Those things caused me more aggravation than help. I hate them.
Of course there was the old "save-as" trick to purge some of the crap.
Sometimes though, you just have to accept that your file is going to get big and sluggish. You can do the whole "lightweight" thing, or save everything in a suppressed state, the big block like Matt mentioned, but I don't think it's escapable. Bear in mind that my opinion is probably out of date. I haven't been a regular user in 2+ years.

[Rob]

Hi @mirisj

One thing I avoided at all costs was external references.

Yeah I have to agree. It's taken me a long time to get here - aren't they the big selling point of the software?

[Glenn Schroeder]

I've found that a big issue for me is just files aging. I don't mean individual Part files, because I'm still using some from my library that are 10 or so years old without issue, but when a project drags on over several years the Assembly and/or Drawing will start taking longer and longer to open, and having more and more issues.

[mbiasotti]

@matt I can't remember all this stuff on my own. Anna, are you there? How about @mirisj Jeff M? Surely @mbiasotti would remember some of this?

You're memory is better than mine and I'm older than you so that's my excuse and lack of reply...

[elmarklammer]

Hi Rob,

Have you tried a stringen evaluate check to see if there are any components with hidden errors.

If you have problems with one particular part then you could try to replace the part template. Although I seem to
remember that it doesn't work with external references inside. But maybe you can fix the references easily.

After your templates are corrected, take existing parts and save them as part templates.
After saving them as part templates, open template and save over part.

Just a thought

Elmar

[Jaylin Hochstetler]

Hi Rob,

After your templates are corrected, take existing parts and save them as part templates.
After saving them as part templates, open template and save over part.

Just a thought

Elmar

That is BRILLIANT! Don't know why I never thought of that. I always thought you have to remodel it to update the template.

[DanPihlaja]

Hi Rob,

Have you tried a stringen evaluate check to see if there are any components with hidden errors.

If you have problems with one particular part then you could try to replace the part template. Although I seem to
remember that it doesn't work with external references inside. But maybe you can fix the references easily.

After your templates are corrected, take existing parts and save them as part templates.
After saving them as part templates, open template and save over part.

Just a thought

Elmar

I don't understand how this will update the template to something that you want. You are taking your existing part and saving it as a template. then taking that same template, creating a new part, then saving over the original part. Sounds like you just get the same thing that you originally had.

Am I missing something?

[mike miller]

Hi Rob,

Have you tried a stringen evaluate check to see if there are any components with hidden errors.

If you have problems with one particular part then you could try to replace the part template. Although I seem to
remember that it doesn't work with external references inside. But maybe you can fix the references easily.

After your templates are corrected, take existing parts and save them as part templates.
After saving them as part templates, open template and save over part.

Just a thought

Elmar

I don't understand how this will update the template to something that you want. You are taking your existing part and saving it as a template. then taking that same template, creating a new part, then saving over the original part. Sounds like you just get the same thing that you originally had.

Am I missing something?

Verified. Does not work.

Before saving.

After "Save As .prtdot" and then "File>New" using template.

[elmarklammer]

Hi Dan,

First you need to create new template files from scratch. Go to options and dhange the path pointing to the Document Templates file location to an empty folder. That will force SW to generate new templates. You will need to use the new templates that are generated to update your old files.

That way you can update legacy files with latest SW template data. For instance if you want to update pre-2013 SM parts to the new multibody SM code.

That should explain it.

Elmar

[DanPihlaja]

Hi Dan,

First you need to create new template files from scratch. Go to options and dhange the path pointing to the Document Templates file location to an empty folder. That will force SW to generate new templates. You will need to use the new templates that are generated to update your old files.

That way you can update legacy files with latest SW template data. For instance if you want to update pre-2013 SM parts to the new multibody SM code.

That should explain it.

Elmar

I understand how to create the new templates from scratch.....where I am stuck on is how to get part A to use said template.

If I save Part A as a template.....I now have a template made from Part A which is a legacy template. Then, if I create a new part using the template from Part A and overwrite the original Part A......I now have a new Part A that is no different than the original Part A.

[elmarklammer]

Hello Dan,

I don't know how the save-as template code really works. This trick was posted by Alex Lachence and his SW VAR and address some issues related with files build on old templates. Not saying it's a one-fix all solutions. But if I was in bind I would look into it. Particuallarly when you use a lot of custom templates. Before redoing all templates from scratch I would try this hack. Has a lot to do with SW inability to upgrade old files to new standard. One example would be the change of the Multibody SM feature/code that took place some time ago. Or populating cutlist properties issues. I can only guess whether SW uses the internal ID of your templates as a means to determine what code comes into play when saving a file. You would need to ask one of the SW engineers or maybe Alin has some insight.

But again. That's a guess. But Alex was a fairly knowledgable user that worked with lots of in-context relations, multibody and cutlist technique. And I guess it must have worked to some degree to solve some issues he had.

Elmar

[Jaylin Hochstetler]

Hello Dan,

I don't know how the save-as template code really works. This trick was posted by Alex Lachence and his SW VAR and address some issues related with files build on old templates. Not saying it's a one-fix all solutions. But if I was in bind I would look into it. Particuallarly when you use a lot of custom templates. Before redoing all templates from scratch I would try this hack. Has a lot to do with SW inability to upgrade old files to new standard. One example would be the change of the Multibody SM feature/code that took place some time ago. Or populating cutlist properties issues. I can only guess whether SW uses the internal ID of your templates as a means to determine what code comes into play when saving a file. You would need to ask one of the SW engineers or maybe Alin has some insight.

But again. That's a guess. But Alex was a fairly knowledgable user that worked with lots of in-context relations, multibody and cutlist technique. And I guess it must have worked to some degree to solve some issues he had.

Elmar

What is your method of seeing the version of the template of a part? I was told the creation date of any of the Main planes is the template ver. is that correct?

[elmarklammer]

Rename sldprt to txt and open in notepad.exe

Search for "_ M O _ V E R S I O N _"

This is followed by a number i.e. 7000

That would be

Case 6001 To 7000

swFileVersion = "SOLIDWORKS 2014"



See list below.



Case 10001 To 11000

swFileVersion = "SOLIDWORKS 2018"

Case 9001 To 10000

swFileVersion = "SOLIDWORKS 2017"

Case 8001 To 9000

swFileVersion = "SOLIDWORKS 2016"

Case 7001 To 8000

swFileVersion = "SOLIDWORKS 2015"

Case 6001 To 7000

swFileVersion = "SOLIDWORKS 2014"

Case 5001 To 6000

swFileVersion = "SOLIDWORKS 2013"

Case 4701 To 5000

swFileVersion = "SOLIDWORKS 2012"

Case 4401 To 4700

swFileVersion = "SOLIDWORKS 2011"

Case 4101 To 4400

swFileVersion = "SOLIDWORKS 2010"

[AlexLachance]

Hello Dan,

I don't know how the save-as template code really works. This trick was posted by Alex Lachence and his SW VAR and address some issues related with files build on old templates. Not saying it's a one-fix all solutions. But if I was in bind I would look into it. Particuallarly when you use a lot of custom templates. Before redoing all templates from scratch I would try this hack. Has a lot to do with SW inability to upgrade old files to new standard. One example would be the change of the Multibody SM feature/code that took place some time ago. Or populating cutlist properties issues. I can only guess whether SW uses the internal ID of your templates as a means to determine what code comes into play when saving a file. You would need to ask one of the SW engineers or maybe Alin has some insight.

But again. That's a guess. But Alex was a fairly knowledgable user that worked with lots of in-context relations, multibody and cutlist technique. And I guess it must have worked to some degree to solve some issues he had.

Elmar

Hey Elmar,

We never really applied the solution because it wasn't something that could be applied on our side. The solution was one for single files and we were looking for something more 'global' that would cover all our files. I just couldn't fathom the idea of going through about 10 000 files to save them as templates and save them back to parts afterwards, because if you forget just one, the issue still remains.

I also have my doubts about the solution. Why would saving a part as a template update it's template? Nobody ever had that answer for me, which is also what someone asked a little higher.

The other question that remains unanswered:
If you can easily fix a template in such manner, why isn't SolidWorks able to automate something on their end so that the user never has to do this?


Edit: To check to see if your template is up to date, look at the creation dates on your planes, the year they were created should represent the SolidWorks version it came from.

[elmarklammer]

Hi Alex,

My bad. I assumed it was something you had actually worked with. That cleared things up. If this trick doesn't do it then I would import my old file into a part file created from a new-template and break the link using the "import feature" option. But again haven't tried it myself.

Working with SW means you need to take a stab in the dark and see if you can hit the target...

Elmar

[ryan-feeley]

I know this thread is a few months old, but it's so good (especially that video from Alin) I'll continue it.

There actually is a little dirty trick for updating a part to a new template that works starting in 2019, and perhaps with older versions. The steps are:
1. Create a new part with the new template.
2. Do insert part, to bring in the solids, surfaces, appearances, and materials of the old part, in to the new one. (Don't include sketches or planes).
3. Then edit the External references. Check the "Include original features (derived parts only), and click "Break All".

This will bring the feature tree into the new template inside a folder. Delete this folder, and you're left with your original feature tree inside the new part template.

The one caveat is this doesn't work if you have configurations. To work around this you can export a design table of your original part. Then delete all but the default configuration. And then import the design table into the new part.

Given that Solidworks is a bit sketchy with appearances and materials in even the best cases, you might want to omit those from the insert part, and re-add them manually. But this trick does actually work.

[Dwight]

[*] I thought I'd maybe made a mistake or forgotten it - but I was 90% sure I had done it before so performed a few extra steps.

• changed the active config
• force rebuild all configs
• repeated the saveas / rebuild / save again / close / delete old / rename routine.

Rob

I'd like to understand more about configurations and dirty files. I find any model file with more than one configuration is automatically dirty whatever I do. I have "rebuild all configurations on save" turned on, even. I just live with it, but I don't like it.

You really had to do a "Save As" to get the file clean?

Thanks

Dwight

[Rob]

Rob

I'd like to understand more about configurations and dirty files. I find any model file with more than one configuration is automatically dirty whatever I do. I have "rebuild all configurations on save" turned on, even. I just live with it, but I don't like it.

You really had to do a "Save As" to get the file clean?

Thanks

Dwight

Hi Dwight

Check out Alins video especially #5

5. Crime #2 Inefficient use of Configuration Data by Older Versions of SOLIDWORKS: 38:25​

If you are running below 2020 then yep it's always dirty.
The problem I had was my assembly was so large it would take toooooo looooong to save and became unworkable

[Dwight]

Rob

We are running 2018 and expect to upgrade this summer. Something to look forward to. I did review Crime #2 and think I understand it a little better this time.

Dwight

[berg_lauritz]

...

to set it, right-click on the top of PRT with Ext. Ref. inside, go to the Ext. Ref. menu,
and choose "Lock",
So SW will stop trying to calculate-evaluate it.

and if you need to update it for a change, simply unlock it, do the change, relock it after.

What exactly does locking those external references do? I never did it - but reading this - I might have to do it!