CAD Forum

We're having some troubles with material as it's stated on the print. Some people do not like 3303-H14 and want to see "Aluminum" on the print.

Ok, we can do that... We already have the print pulling the material from the model, $PRPSHEET:"Material" or something like that and that's fine. I can edit the material table (its in vault so I checked it out and the folder it's in is updated on login). For the models that are currently using this material named 3003-H14 it would be nice if they would update to the new material name in the feature tree (more importantly in the properties) the next time someone opens the file for a revision or whatever. When I try this if I have a file that is not open already using the material when I change the name and save it to the materials file, when I open that file I need to go reapply that material to get the name to update.

I can put out a reminder that people need to do this for the aluminum parts, but I've learned that unless the email I send out is of immediate significance to what they are doing at that moment they just read and forget it.

I do not think so, but would be pleased to be proven wrong.

I have tried something similar, where I was using the preinstalled PVC Rigid for CPVC, and then I made a new CPVC material.
I did similar before also to switch from using Alloy Steel to a newly created Alloy 20 and Hastelloy materials.
I believe that each component retains its assigned material by name - even it it does not exist in your materials anymore! Therefore, I do not think that the name will not update by changing its name in your materials.

Tom G wrote: ↑Fri Jul 02, 2021 4:33 pm I do not think so, but would be pleased to be proven wrong.

I have tried something similar, where I was using the preinstalled PVC Rigid for CPVC, and then I made a new CPVC material.
I did similar before also to switch from using Alloy Steel to a newly created Alloy 20 and Hastelloy materials.
I believe that each component retains its assigned material by name - even it it does not exist in your materials anymore! Therefore, I do not think that the name will not update by changing its name in your materials.

That is what I see as well, because when I open up the model again after editing the material name and go to edit the material it takes me to the top of all the materials tree instead of in our custom material catalog.

What's a little weird is that the catalog itself seems to NOT track the material object by name but rather some other ID, because if it keeps all the other attributes. So I can apply a new name to the same material and the material catalog is ok with that. Even the sort order stays, it's not sorted by name so that "Aluminum 3003-H14" is still right after "3030-H12, Rod (SS)" and before "3003-H14, Rodc(SS)". Which I find nice that it's not re jumbling them around. Although I kinda wish it would expose the material ID somewhere (even obscure on some tab) just for tracking purposes I guess.

I agree with all that you describe, from my experience.
Even Design Tables assign material exclusively by name, again even it it doesn't exist in your materials.

bnemec wrote: ↑Fri Jul 02, 2021 5:02 pm Although I kinda wish it would expose the material ID somewhere (even obscure on some tab) just for tracking purposes I guess.

There is an ID number in the material file which is just an xml file. I don't know how it's assigned or what happens if you mess with it.

jcapriotti wrote: ↑Tue Jul 06, 2021 12:26 pm There is an ID number in the material file which is just an xml file. I don't know how it's assigned or what happens if you mess with it.

image.png

After posting last week I started wondering if it wasn't some text or sqlite file. I saw that ID number in the definition, why not use that then instead of the material name? I'm guessing evolution, name came before ID, some function needed ID so it was added but it was decided to not change the code that selects the material for the part to use the ID instead of the name. Or, it was never considered.

Either way I think we've established that even though the material catalog can handle renaming a material, Solidworks doesn't support it unless that file is open. Which is silly to think that is considered intended use, that one would need to open EVERY FILE in the data set that uses a material if the name needs to be changed. If the model would just remember which material to use by the catalog name and ID instead of name this would not be a problem.

bnemec wrote: ↑Tue Jul 06, 2021 12:48 pm Which is silly to think that is considered intended use, that one would need to open EVERY FILE in the data set that uses a material if the name needs to be changed.

What would you expect from a software that if you "save as" a file that it replaces that part in every file that it is currently in but does not effect any of the ones that are closed at all?

SW is, less than robust, putting it politely, on how it deals with file structure, relationships etc.

Now I'm not sure what the ID is for. Renaming the material gives it a new ID so its not persistent. Renaming a material and opening a file that was assign that material just goes to the top of the list when it cant find it by name.

MJuric wrote: ↑Tue Jul 06, 2021 1:16 pm What would you expect from a software that if you "save as" a file that it replaces that part in every file that it is currently in but does not effect any of the ones that are closed at all?

SW is, less than robust, putting it politely, on how it deals with file structure, relationships etc.

I'm expecting less and less every day from all CAD packages. Solid Edge did the same thing, I'm sure that was some feature that some bigger customer wanted. Then a while back they added a dialog that would ask how you wanted to "Save As". I think three options, one for update all open where used to the new file, one was not update any open parents and I don't recall the other. I just memorized which one to use because the wording of the options in the dialog were clearly done by a programmer that doesn't use the software that much, it was borderline cryptic.
This would bite us regularly before PDM, the engineers had write permissions to all the files and most of them didn't understand that just because a file wasn't show in a viewport that SE didn't have it loaded... So many updates made unknowing. To make matters worse, probably >80% of our new files are from SaveAs so it's a daily practice.
Now with PDM it's different struggle, instead of "I didn't change that assembly, I didn't even have it open!" to "I had that all done already, Solidworks lost it, I already did that change." Well, did you have it checked out?

jcapriotti wrote: ↑Tue Jul 06, 2021 2:18 pm Now I'm not sure what the ID is for. Renaming the material gives it a new ID so its not persistent.

I didn't even think to test that. Shame on me for trusting software to be set up in a logical manor. Exactly, what is the point of having an ID if it changes?

jcapriotti wrote: ↑Tue Jul 06, 2021 2:18 pm Renaming a material and opening a file that was assign that material just goes to the top of the list when it cant find it by name.

This is exactly what I am seeing and it makes me a bit uneasy as I know I'll get calls and emails about it EVEN IF I send out a pictogram email where I attempt to explain what to do and why it happens.

What is the name of the batch processing software out of Australia. It used to be free and then they started charging for it a few years ago. Would that work for renaming the material in the appropriate files?

Central Innovation - #Task

https://centralinnovation.com/solidwork ... s/task-v2/

bnemec wrote: ↑Wed Jul 07, 2021 9:16 am I'm expecting less and less every day from all CAD packages. Solid Edge did the same thing, I'm sure that was some feature that some bigger customer wanted. Then a while back they added a dialog that would ask how you wanted to "Save As". I think three options, one for update all open where used to the new file, one was not update any open parents and I don't recall the other. I just memorized which one to use because the wording of the options in the dialog were clearly done by a programmer that doesn't use the software that much, it was borderline cryptic.
This would bite us regularly before PDM, the engineers had write permissions to all the files and most of them didn't understand that just because a file wasn't show in a viewport that SE didn't have it loaded... So many updates made unknowing. To make matters worse, probably >80% of our new files are from SaveAs so it's a daily practice.
Now with PDM it's different struggle, instead of "I didn't change that assembly, I didn't even have it open!" to "I had that all done already, Solidworks lost it, I already did that change." Well, did you have it checked out?

I think this is a case of trading "Ease" for "Robust". Why in the world someone would think that saving a file as a new name and replacing it in an associated assembly that just happened to be open was a good idea is beyond me. Yeah, I get it's more work to go back into the assembly and replace the file, but that FORCES you to do it purposefully and DOESN'T allow you to do it on accident by happening to click the wrong "Save".

This also goes along with SW's horrible "Save anything anywhere and we'll make it easy on you and "Find it for you"" mentality...again, yep, faster, but really just a bad idea.

SPerman wrote: ↑Wed Jul 07, 2021 9:35 am What is the name of the batch processing software out of Australia. It used to be free and then they started charging for it a few years ago. Would that work for renaming the material in the appropriate files?

I believe you're talking about Xarial, by @artem ?

https://xarial.com/about/

Artem appears to be a Wizard of Solidworks APIs and Macros. He and Alin Vargatu have done some great SWW sessions together. I've looked at some of his work, probably missing much of what is available, but I run into complexities since the files are in PDM. Almost nothing is off the shelf at that point unless it is built to be customizable/configurable to accept what we named out workflow states and know what to do if the file is checked out etc.

edit: @SPerman I see you posted the #task link while I was typing this one. Thanks.

The material library is a collection of materials and their properties that can be _applied_ to a part. The action of applying material copies these properties from the database and pastes them to the part with no link to the material database. This is really necessary because every install of SW could potentially have a different material DB. If it were linked to the DB, and you modified your DB (change names of materials, use custom materials, etc), then you sent your files to another person, the data they see in the part would be linked to their DB and could be missing entirely, or worse, incorrect. The only way to make sure it stays correct in the part no matter where that part travels is to copy the properties from the DB and store them in the part. And only change those values when someone explicitily applies a different material.

josh wrote: ↑Sat Jul 10, 2021 11:27 pm The material library is a collection of materials and their properties that can be _applied_ to a part. The action of applying material copies these properties from the database and pastes them to the part with no link to the material database. This is really necessary because every install of SW could potentially have a different material DB. If it were linked to the DB, and you modified your DB (change names of materials, use custom materials, etc), then you sent your files to another person, the data they see in the part would be linked to their DB and could be missing entirely, or worse, incorrect. The only way to make sure it stays correct in the part no matter where that part travels is to copy the properties from the DB and store them in the part. And only change those values when someone explicitily applies a different material.

NOW that makes sense.

Edit 1:
The above is also sort of true for custom shapes for the weldments. The shape is copied/or/imbedded into the file it is used in, so others can open it and it will be there. BUT if you get this file from someone else and if you want to use that shape in another sketch in that file and you do not have that shape, in your weldment profiles, on your machine, can you use that shape??? I do not think so. Even if the person you got the file from did a proper Pack-N-Go… Pack-N-Go will not put in the package it packs the weldment profiles used.

Edit 2:
It is also true for a customized hole call out. ie the “calloutformat.txt” file when customized and used via the wizard to call out a hole in a drawing it will place the customized hole callout in the drawing BUT if you receive the drawing from someone who has done this and wish to place a similar hole call out on the same drawing you need to edit the text to match the text of the similar hole.

josh wrote: ↑Sat Jul 10, 2021 11:27 pm The material library is a collection of materials and their properties that can be _applied_ to a part. The action of applying material copies these properties from the database and pastes them to the part with no link to the material database. This is really necessary because every install of SW could potentially have a different material DB. If it were linked to the DB, and you modified your DB (change names of materials, use custom materials, etc), then you sent your files to another person, the data they see in the part would be linked to their DB and could be missing entirely, or worse, incorrect. The only way to make sure it stays correct in the part no matter where that part travels is to copy the properties from the DB and store them in the part. And only change those values when someone explicitily applies a different material.

Thanks Josh, that does make sense. There are other ways to implement materials that would keep a link to the database and not completely fail when the file is sent elsewhere. A well polished solution would have looked into those.

Simply using a GUID for each entry would prevent mix matching of materials when file opened on another PC with different material DB that happens to have a matching ID but assigned to different material.
Checking the database on file open for matching GUID would update the properties stored in file if one exists, if not then don't update. Or am I over simplifying things?

bnemec wrote: ↑Wed Jul 14, 2021 10:02 am
Checking the database on file open for matching GUID would update the properties stored in file if one exists, if not then don't update. Or am I over simplifying things?

Probably more like overcomplicating them. The use case for editing the properties of a material in the DB and then wanting all the files using that material to automatically update is probably pretty small. And there's a fair chance that folks who do edit their materials DB don't necessarily want older stuff auto-updating either. Might require an ECN or drawing revision or something. So then you have to add a "don't auto-update" option for those people, then explain how it all works to people who picked the wrong option....

Then you have the possibility within the same company of, say, using eDrawings to open the file. eDrawings doesn't have the material database. So Jimbo in the shop opens the drawing in eDrawings and sees different info from Joeblow in the engineering department? Ok, now we need a dialog box when you open: "do you want to update the material property values from the material DB?".... Also need to be able to "don't show again"...

Not saying these issues can't be overcome, but it's a lot of complexity added for what I would imagine is a small actual use case. OTOH, it's not difficult to write a batch processing macro to update material properties on all files on the server or something.

josh wrote: ↑Wed Jul 14, 2021 11:37 am Probably more like overcomplicating them. The use case for editing the properties of a material in the DB and then wanting all the files using that material to automatically update is probably pretty small. And there's a fair chance that folks who do edit their materials DB don't necessarily want older stuff auto-updating either. Might require an ECN or drawing revision or something. So then you have to add a "don't auto-update" option for those people, then explain how it all works to people who picked the wrong option....

Then you have the possibility within the same company of, say, using eDrawings to open the file. eDrawings doesn't have the material database. So Jimbo in the shop opens the drawing in eDrawings and sees different info from Joeblow in the engineering department? Ok, now we need a dialog box when you open: "do you want to update the material property values from the material DB?".... Also need to be able to "don't show again"...

Not saying these issues can't be overcome, but it's a lot of complexity added for what I would imagine is a small actual use case. OTOH, it's not difficult to write a batch processing macro to update material properties on all files on the server or something.

Those are all good points. The longer I do this the more I realize just how much of our regular day to day is made up of "small use cases" when viewed from a outside, macro perspective.

bnemec wrote: ↑Wed Jul 14, 2021 1:52 pm Those are all good points. The longer I do this the more I realize just how much of our regular day to day is made up of "small use cases" when viewed from a outside, macro perspective.

One use case I can think of is when you are building the company specific material database and you add custom properties to the material to use in downstream applications. This could be in flux and incomplete. You have to reapply the material to push it into the model. Maybe a macro could do this, though you would have to remember to run it.

jcapriotti wrote: ↑Wed Jul 14, 2021 2:22 pm One use case I can think of is when you are building the company specific material database and you add custom properties to the material to use in downstream applications. This could be in flux and incomplete. You have to reapply the material to push it into the model. Maybe a macro could do this, though you would have to remember to run it.

Yes, that's exactly what we're up against. The thickheaded CAD Admin didn't have all the SW stuff set up properly, including a perfectly organized material list. So lots of catchup work.

bnemec wrote: ↑Wed Jul 14, 2021 2:38 pm Yes, that's exactly what we're up against. The thickheaded CAD Admin didn't have all the SW stuff set up properly, including a perfectly organized material list. So lots of catchup work.

lol...I'm pretty thick headed as well .........mostly because we didn't intend to use the library in that way at first. For the last 20 years we just used the material library to set a material density so the weight would be accurate, thus the default Solidworks list was enough. Only recently have we begun to use it for more and of course 20 years of legacy files don't have this information.