#361408
I am having a problem with parts losing their MXM material assignments when they are inserted into an assembly. In trying to determine what was happening I discovered that when I bring parts into a new assembly the materials assigned to the parts do not show up in the material list. When the assembly is saved Solidworks updates the parts at which time the material assignments may be lost.

The problem is intermittent but after some experimentation I have stumbled upon a sequence that, while not a normal workflow, will reproduce the problem at will (on my computer, anyway):

1. Create a new part and assign an MXM material to it. Check with Fire. Save and close the part (closing the file is important!).
2. Create a new assembly and insert the part. Open the Maxwell plugin and observe that there are no materials in the material list.
3. Run fire and let it run to completion. Everything in the Fire render will be gray.
4. Save and close the assembly.

If I now reopen the part, the material originally assigned appears in the Material list, but the plugin's Object Properties shows that there are no materials assigned either to the body or to any of the faces. If I run Fire it renders gray. The same is true with the assembly.

I have tried reinstalling the plugin but that did not fix the problem. I hope you can reproduce it at your end.

Windows 7 x64/16GB RAM/Solidworks 2012
#361409
Oh, that's lovely...yes, I see it here too. I'll see what's going on -- in the meantime, you should theoretically be okay if you swap around your steps 3 & 4. Meaning, after inserting, save, close, re-open...you should see your materials being pulled into the assembly then, and their assignments should remain undisturbed.
#361434
Hi JD,

Yeah, its a good one alright. The sequence I described is not my normal workflow, it is just one that always generates the failure. I first ran into the problem after I brought two large sub-assemblies into a new assembly, arranged them a bit and ran Fire. When everything rendered gray I knew something was wrong, but I saved the assembly not thinking it would affect the sub-assemblies or their parts. It wasn't until I re-opend one of the part files that I discovered that all the materials were gone. Luckily I had backups for everything.

Don
#361445
Yes, but the question is 'why?'. I applied materials to the parts, not to the assembly. When I insert the parts into an assembly the materials are still applied. I know this because if I save the assembly, close and re-open it, the materials are there. It is only if I run Fire before saving the assembly that the materials are lost. So how did the materials get removed from the parts, they are independent files?

What has me concerned is the idea that parts can be modified at the assembly level by the plugin. In my opinion that should never be allowed.
#361447
What has me concerned is the idea that parts can be modified at the assembly level by the plugin. In my opinion that should never be allowed.
There is no such distinction between editing a part while working with it in an assembly, or with its .sldprt file open; parts in an assembly are live instances of their part files. When you hit Save, you are saving the assembly, and any changes to .sldprts that have been made. So there's really no question of it being allowed or not, it's fundamental to how SW works with data.

As to the question of why, it is because the plugin is not aware that you have inserted the part into the assembly; it has not, therefore, loaded the part's data into the session, and this has resulted in invalid material references being found and removed during traversal for export to Maxwell Fire. That is just some bookkeeping the plugin does, for various reasons. Were the data loaded, as it is when you open the assembly, this could not present a problem.

So far my only option was to ungroup (my group wa[…]

Thanks Miguel I know 5.2+ is a big development hi[…]

SketchUp 2021 Update

Hi Alberto, Many thanks for taking the time to ma[…]

Let's talk about Maxwell 5.2

Features are closed and tested, we are testing p[…]