Part file schizophrenia within an assembly

[DDoerschuk]

I'm using 32-bit AD Expert 2011 (still; we're finishing a project before upgrading to 2012) on XP SP3 with M-Files 7.0 running locally on the same computer as AD.

In an assembly called Machine, we've inserted a part called Nut. Works fine. Now, we insert a part called Bolt. The image in the assembly window is another Nut, not Bolt.

1. The Design Explorer window for the Machine assembly claims that we added another Nut, not a Bolt.
2. The M-Files Explorer shows Nut.AD_PRT and Bolt.AD_PRT correctly, with different ID numbers.
3. Opening the individual part files from the M-Files Explorer shows the correct Nut and Bolt design images, as expected.
4. Copying the Bolt.AD_PRT over to the regular Windows file system (NTFS) and then importing a Bolt into the Machine assembly works fine.
5. Once this goes wrong, I can repeatedly add Bolts, and only Nuts will show up. Shut down the system and reboot the computer --- the problem remains unchanged.

I've had this scenario happen twice now during this project with different parts and assemblies. The first time required a lot of rebuilding parts from scratch to make it go away (almost certainly 99% of the work I did to correct the problem had no impact).

M-Files has always worked well for me, and in truth, I can't say that I have really pinpointed whether it is AD or M-Files that is at fault here.

Any assistance will be very much appreciated!

Thanks,
Dave

 

[DavidJ]

Re: Part file shizophrenia within an assembly

This doesn't sound quite usual, but here are some pointers to maybe help narrow down the problem...

1. Are you aware that (within windows) changing the name of an Alibre part file can cause huge problems - it's important to use 'Save As' from inside Alibre to rename files.

2. On the other hand - re-naming inside M-Files doesn't usually have these issues as the 'name' is just a piece of metadata and isn't important - plus all files reside in one folder.

Your problem sounds very much like 1, which we regularly see newbies here report . Given your post count, and the fact you're using M-Files I'm assuming you aren't a newbie... can you give us any additional clues.

Where did the parts come from, have any been re-named or used as the basis for other parts...?

 

[DDoerschuk]

Re: Part file shizophrenia within an assembly

Hello DavidJ, thanks for responding!

This doesn't sound quite usual, but here are some pointers to maybe help narrow down the problem...

1. Are you aware that (within windows) changing the name of an Alibre part file can cause huge problems - it's important to use 'Save As' from inside Alibre to rename files.

2. On the other hand - re-naming inside M-Files doesn't usually have these issues as the 'name' is just a piece of metadata and isn't important - plus all files reside in one folder.

I'm using M-Files exclusively, and my understanding is that renaming a file within the M-Files Explorer is always legal, whether using: F2, the Properties screen, or the "rename" selection on the right-click context menu. Also, I believe that if you wanted to, you could navigate a Windows Explorer instance over to M: and drill down, then rename the file from within Windows Explorer. Some command line shells may also work, but most can't "see" into the M:\ root. Command.com and 4NT both don't work with M-Files.

As you point out, 'name' is just metadata in M-Files. The sacrosanct object is the ID number, and I don't think there's really a way to damage things by renaming as long as the file itself is being managed by M-Files.

Your problem sounds very much like 1, which we regularly see newbies here report . Given your post count, and the fact you're using M-Files I'm assuming you aren't a newbie... can you give us any additional clues.

Where did the parts come from, have any been re-named or used as the basis for other parts...?

I've been using AD Expert for around 6 years, so I've had plenty of time to make mistakes. :lol: To create a new part, I've used these methods:
1. Select the "new part" button in an existing part or assembly window.
2. Do a "save as" from within a part window
3. From within the M-Files Explorer:
---A) Select "Copy As" from the right-click context menu
---B) Copy and paste the file with ^C and ^V

I thought all of these were valid as long as we're using M-Files. Certainly I've been using them all for quite some time without ill effect, but that's really not conclusive, of course.

Given that I can open M-Files Explorer and double click on either Nut.AD_PRT or Bolt.AD_PRT and have the correct Nut or Bolt, respectively, show up in the AD Editor, it seems like M-Files is working correctly since the Assembly complex exists within AD, not M-Files.

A) Is there a consistency check that I can run on M-Files, possibly including the Alibre-side of the equation as well? Within M-Files I'm using the default native Firebird engine, not the optional MS-SQL Server.

B) Should I look at the "relationships" listed for each file in the M-Files Explorer? I noticed that in Machine.AD_ASM's relationships there is a "Relationship To This Object" for a file named Plenum.AD_ASM. However, when I look at the relationships listed for the Plenum-AD_ASM file, there is no corresponding entry to Machine.AD_ASM. I don't even know if that's a problem, but it did seem odd. Is there a tool for executing a consistency check on the relationship lists?

Thank you very much.
Dave

 

[DavidJ]

Re: Part file shizophrenia within an assembly

Anything involving a 'copy' MIGHT cause problems in Alibre as it internally uses things other than the file name - hopefully that shouldn't be an issue when using M-Files.

I can't see why 'nut' would be derived from a copy of 'bolt' or vice versa, so maybe this isn't the problem that others regularly get where in an assembly parts get mixed up.

Ctrl+C and Ctrl+V definitely cause huge problems within Windows Explorer, I would be cautious of use in M-Files (butI haven't played with that) - again can't see that nut would be produced from a copy of bolt....

Are you able to post the files here at all?

 

[bigseb]

Re: Part file shizophrenia within an assembly

Are you by any chance doing this: you create 'bolt' and save it. Then you save the same file as 'nut' but delete the geometry/features you don't need and keep whatever you may need for the nut? I do this a lot with inserts and cavity plates that have uneven splitlines, keeping the geometry so that the splitlines match perfectly. While I haven't had any problems with assemblies I notice that in Keyshot when I assign a material to one cavity plate the other will also be assigned that material. The only link between the two plates is that they are essentially derived from the same file... :?

 

[Lew_Merrick]

Dave,

Quite some time back, I found that if I did not load a part file into Alibre separately first there would sometimes be a mis-view such as you describe. I now have the habit of loading a part file first before inserting it into an assembly so thoroughly that I do it as a matter of course and have not had that problem arise since I began working in this manner. Now, mind you, I do not use Vault or M-Files. Such things (as I recall) would happen more as I reached the memory limit of the system more than at any other time (and maybe even exclusively at such nearly out of memory times). ???

 

[DDoerschuk]

Thank you very much for your answers. I've been working on this problem non-stop, and am making some progress. I've been alternating checking in all files with checking them out, and logging out and back in to M-Files, and walking down the trees of subassemblies executing "regenerate assembly" commands. Kind of surprisingly, all this seems to make things run a bit better.

I believe Sebastian is correct, and AD is actually maintaining some linked lists within itself that are separate from identical data contained in the M-files metadata. This may well be a holdover from the programming for AD using the Windows File System which doesn't natively support relationships or version control...so AD had to at least maintain relationships itself.

Some of the artifacts of the problem have been surprising: currently, for instance, the M-Files file name of the top-most assembly file in the project does not match the file name written on the upper windows' bar in the editing window. Go figure? In fact, the name displayed at the uppermost edge of the window is from a file that was deleted several days ago.

I have a couple questions, if that's OK:

1. I still can't "copy all as" from within the top-most assembly file; it consistently bombs with an error message about incomplete metafile data and advises me to look at the M-Files Log File for details. I can't find it. I feel like a moron. Where is the log file located?

2. Several files have relationships listed that should not exist. Is it a legal move to adjust the relationships lists by hand?

3. Are there any consistency-check tools for M-Files or AD? Something that would walk the linked lists and verify sanity, reporting problems to the console?

Thank you all again for your insights and assistance!
Dave

 

[DavidJ]

1. When saving files to M-Files, any required metadata wil need to be completed. The M-Files Log is accessible for each Vault from the Server Admin Tools (see image).

2. The relationships are populated by Alibre Design (mainly), some may be done natively by M-Files. I'm not sure if there are unfortunate consequences from editing manually. Can you give an example of the relationships 'that should not exist' - it might give some clues.


3. Not aware of anything...

 

[DDoerschuk]

Thank you for the answers, DavidJ!

Regarding the relationships that should not exist (at least, I don't think they should) here is an example:

Looking at Assembly_P's relationships:
Relationships From This Object (4)

• Project_1 Description: Project
  Part_1 Description: Constituent
  Part_2 Description: Constituent
  Part_3 Description: Constituent

Relationships To This Object (2)

• Assembly_Top <---- This is the Top-Most assembly, AssemblyP has been inserted into AssemblyTop
  Assembly_W <----- I don't think this is correct, see comments below.

Many versions back, if I remember right, Assembly_W did contain Assembly_P, but it hasn't for a long time. Why does the relationships list for Assembly_P still contain a pointer to Assembly_W?

If we look at the relationships list for Assembly_W, it contains no reference at all to Assembly_P. In terms of the "reality" of the design, this is correct. It is Assembly_P's reference to Assembly_W that seems to not reflect the actual design.

Is this something that I should manually fix? Does it even really matter? It certainly seems like a broken linked list to me, but I may be missing something.

Moving over to the failed "Save All As" problem (and I have a feeling these two problems may be related) here is what I've documented:

• Tried to "Save All As" to an empty project, replacing only the project name and the revision number
  "Save All As" crashed on creating one of the part files: "Size 1 Stator, Main Bearing with Mount", and suggested looking at the file's metadata
  Couldn't find anything wrong or incomplete with the part file's metadata
  Tried to "Save As" only the one file: "Size 1 Stator, Main Bearing with Mount"
  "Save As" performed correctly, new copy of file is good, however, Alibre.log shows an error: EXCEPTION COPYINGCUSTOM_ITEM_PROP_DATA - already exists. (Exception from HRESULT: 0x80030050 (STG_E_FILEALREADYEXISTS))

I've attached a file showing the Alibre.log file interspersed with screen saves showing the configurations and commands used.

I'm really sorry this is dragging on so long. Thank you all very much for sticking with me and looking for a solution!
Dave

 

[DavidJ]

Have taken a quick look - my first thought is that perhaps you should have selected 'overwrite existing values' checkbox - however I'm not totally confident of that.

Are you wanting to 'save all as' because you plan to modify these for a new project ?

If only needed to have these connected to another project, then you can connect to multiple projects in M-Files, without creating copies.

The 'bad relationship' sounds like either a failed operation that should have removed it, or coding that that doesn't correctly handle the circumstances around removal of relationships as designs change. I'd be tempted to remove it manually, and report the occurence to Alibre support (in case there is some weakness in the coding).

 

[DDoerschuk]

Thank you for your reply, DavidJ.

Have taken a quick look - my first thought is that perhaps you should have selected 'overwrite existing values' checkbox - however I'm not totally confident of that.

I re-ran the "Copy All As" function with the "overwrite existing values" checked. Bad luck, though: same error message window, and an extremely similar scenario in the alibre.log file. Certain worth a try.

Are you wanting to 'save all as' because you plan to modify these for a new project ?

If only needed to have these connected to another project, then you can connect to multiple projects in M-Files, without creating copies.

We've got a new, similar-but-different project that I need to scavenge parts for. Also, I'm now really worried that something in the Vault's file system has a broken link(s) and needs repair (think unix's i-node chains and fsck() etc., or even MS-DOS's "chkdsk.com.)

The 'bad relationship' sounds like either a failed operation that should have removed it, or coding that that doesn't correctly handle the circumstances around removal of relationships as designs change. I'd be tempted to remove it manually, and report the occurrence to Alibre support (in case there is some weakness in the coding).

I'm going to contact Alibre support and report it as you suggest. I will update this thread with their comments.

Thank you all for the help! The files for this project are now at least usable again (take a look back at the original post!) and I'm very grateful for your time and expertise.

Dave

 

[DavidJ]

There are 'Verify & Repair' tools in the M-Files Server Admin. These check/fix some things internal to M-Files (not sure what). Can't do any harm to run the tools, but it'll unlikely fix anything that Alibre has set.