Our company has been working with a developer to create an add-in within Solid Edge that will export the parts list from an assembly, and save it to an xml file. Then, using a widget inside our ERP software, we can import the data directly. We’ve found that there are occasions where the add-in crashes and doesn’t export anything. After quite a bit of digging into this I’ve discovered that Solid Edge has somehow added some “phantom” parts into the assembly. These parts don’t usually show up in a parts list inside the draft file, although I have had an instance where they did. I’ve found that they show in the assembly database if you use the Solid Edge Spy utility by Jason Newell. They’re listed under: Application\ActiveDocument\Occurences\. I’ve attached a screen capture where I opened the assembly read-only and deleted everything. You can see in the Spy that there still some “phantom” occurrences that should not be there. If I actually saved the assembly like this, and re-opened it. All 10 instances would simply say “SolidEdgeAssembly.Occurrence” like numbers 9 &10.
We currently use ST7 MP 11. Some of the assemblies that have displayed this problem were created using ST7 templates, and others were from ST6.
These are average assemblies consisting of approximately:
60 unique parts
500 total parts
8 unique assemblies
40 total assemblies
I have submitted this to GTAC but they were unable to remove the phantom occurrences. These problematic assemblies cannot take advantage of our automated add-in so they have to be loaded manually which is time consuming, and prone to error.
So I would like to ask if a few of you out there could do a simple test for me? Pull up one or two similar sized assemblies READ-ONLY and remove all the parts and sub-assemblies. Then use Jason’s Spy utility and see if you still have any residual occurrences.
I appreciate any help,
No family of assemblies, no family of parts. Have a bunch of interpart copies. Use rectangular patterns within the part files whenever possible, but there a few pattern-along-a-curve too.
No interpart links present according to Spy. Did notice something else though. I had deleted all the sketches, section views, and extra reference planes. But according to the Spy, there are also 4 un-accounted for planes.
The reason I ask about FOA is because we've noticed lingering links when we delete a component from FOA. They won't show up in Solid Edge anywhere, but they will show up in RevMan, usually as a broken link.
What we end up having to do is create a new part with the exact same filename. Make sure RevMan recognizes the link. Then open Solid Edge and see if we can find it. If not, we insert the part into the assembly. Save, Close, Re-open, and delete the part again. This sometimes corrects the issue. If we don't have a part to resolve the link, there is no chance to fix the issue. We can't delete broken links. That's why we create a new part with the exact filename. It doesn't have to have any geometry or be mated in the assembly. The link just needs to be resolved.
It happens most often in FOA because we'll end up deleting the part completely, but not have "apply edits to all members" checked, so the FOA member remembers the link to the file and the operation to delete it. So, the link is there, even through the part is not, just so Solid Edge can delete the part every time the file is opened. Cleaning up FOA is enough effort that we continually re-evaluate its usefulness compared to making seperate assembly files.
I had similary situation, but in my case there wos set an alternative parts (in replace part menu find define alternative component) to some components in assemblie (in path finder cant see them but in revision manager (designe manager) there where visible).
So still no luck trying to remove these bogus occurrences. I did however get the bright idea that if you can't beat em, join em. So I used Jason Newell's Spy for Solid Edge, and was able to change the property of these bogus occurrences to not show in the BOM. Now our utility passes over them and moves on without crashing. Hats off to Jason for creating an awsome tool that allows us to do surgery on a file to make it usable again!
Oh, and for the record, I fixed the two current assemblies I have that exhibit this issue. And when I updated the assembly draft files, I did notice the quantities changed that were related to the bogus occurrences. So each of them actually DID show up erroniously in the parts list.
So has anyone else been able to try the "test" on one of your own assemblies?