When clients are considering the move to SolidWorks Enterprise PDM one of the questions I am always asked is “What do we do with our legacy data?”
Unfortunately there is not one universal, all encompassing answer to that question as it’s highly variable depending on each client’s situation. There are however a few common situations that I would like to talk about in my next 3 posts over the coming weeks. These situations are: people moving from a network based folder structure, people moving from SolidWorks Workgroup PDM and people moving from another PDM tool. In the SolidWorks user base, over 70% of companies are running without a PDM system, so it makes sense to talk about folder structure based migration first.
If you are running on a network based folder structure you likely realize that revision control, permission control and backups are important but you are still controlling these processes in a very manual fashion. The majority of companies are using some sort of revision indicator in either the file name (e.g. Bracket_A.sldprt) or the folder name (e.g. U-Joint Assembly_RevC) as a means of keeping revision history. If you are reading this article you likely are already aware of the problems this can cause so I will leave that discussion for another day and tell you there are 5 main things to be concerned with when preparing this type of data to be moved into a PDM system.
1) File names – If you are one of those companies who are storing files with revision data in the file name, good for you. That is the first step to trying to get your data under control HOWEVER this does not fly in a PDM system. Because PDM systems take 1 file and store multiple revisions of it using a database, all those files must have the SAME FILE NAME. If you have Bracket_A.sldprt and Bracket_B.sldprt the PDM system will see those as TWO UNIQUE FILES instead of 2 revisions to the same file. One of the major tasks at hand will be cleaning up your file names for the migration process. Don’t be too scared of this though because it may be advantageous when moving your files over. It is certainly possible that a script can be written to rename the files and write the revision information into the file’s metadata.
2) Duplicate Files – I can almost guarantee that if you are a SolidWorks user in a collaborative environment using a network based folder structure that you have duplicate files floating around. These files can cause huge problems when trying to migrate into a new PDM system because of the way SolidWorks stores reference path data in the header of the files. Say for example that Bob was the last user to work on U-joint.sldasm. He added the file handle.sldprt to that assembly and lucky for him handle.sldprt already existed from a previous project so he just copied that file to his local machine and added it to the assembly. When he saved the assembly and copied it back to the server, he forgot to move handle.sldprt back as well so in the header of the assembly it refers to Bob’s local hard drive as the location of that file. A few months later, Bob makes a change to handle.sldprt on his local machine, forgetting that he copied it from the server and it’s used in other assemblies and this time he does copy it back to the server, although in a different folder. Now you have multiple problems:
- When you move U-joint.sldasm and it sub-components to the new PDM tool, it is looking for handle.sldprt on Bob’s local hard drive which can’t be accessed so you get an error
- You have two files on the server named handle.sldprt PLUS a file on Bob’s hard drive with the same name, which is the newer file? Do all assemblies use the newest version or does each assembly refer to a different version?
Cleanup of these duplicate file names is crucial to having complete and accurate data in your new PDM system.
3) Missing references – Much like the example used above, files can easily be removed from the server to a local hard drive and then forgotten about and deleted. This causes huge problems down the road when migrating into a PDM tool because you could be missing crucial pieces of information for an assembly to define itself. For example, if you have an assembly which uses a base and all components are mated to that base, if you lose the base file none of your components have any mates and the assembly falls apart.
4) Folder Structure – When moving into a PDM system like SolidWorks Enterprise PDM, it is very easy to take an existing folder structure and duplicate it in the PDM system by simply dragging and dropping. While this could be a great method, you must consider the naming conventions used in the current folder structure. For example, if you used the method of controlling revisions by added revision information to folder names then you wouldn’t want to copy all of those folders over to the new PDM tool because, just like situation 1, it would treat the files within those folders as unique files and not revisions of a single file.
5) MetaData – For those who don’t know, metadata is information about a file. A huge advantage of a PDM system is being able to store file metadata in a single location so that searching and reporting on that metadata is extremely efficient. While metadata can be added to the PDM system at any point, this metadata may be used as a part of the migration process to determine things like revisions or file locations so it’s important to understand what metadata is being used and if that metadata is up to date.
Of course there is a lot more to consider but this information should give you a basis of what to look out for when considering a move. There are tools out there right now, such as this free tool by RazorLeaf which can help you check for missing references and duplicate file names so this isn’t such a painful task.
Tune in next time for Part 2 which will discuss considerations when moving from SolidWorks Workgroup PDM to SolidWorks Enterprise PDM.
Thank you for this interesting post. However I couldn’t get a good feel of a good method of what TO DO when considering a move to PDM. We presently we do not have PDM but our group envisions buying it in the near future. We have a nearly finished drawing package of our machine, lets call it Machine_A. We are at a point where we are ready to begin Rev 2 of Machine_A, as well as Machine_B. But we are not sure how to structure our file system so that it will easily migrate to PDM once we purchase it. Rev 2 and Machine_B will use many of the same parts of Machine A, but there will be new parts and revisions. Machine B’s new parts shouldn’t present a problem, because it is a new machine name, but how should we handle Machine_A Rev 2’s revised parts?
Hey Oliver,
This is an interesting question and there are a couple ways you could handle it. For the revised parts in Machine_A, you could create a new folder (with Rev 2 name) and store the revised files there and keep their current names. This could become confusing for your engineers however and the chance to use parts from the wrong folder (revision) becomes very high. Having the same file names will ultimately make the migration into PDM easier however.
Your other option would be to create a Rev 2 folder and do a pack and go of rev A but only move the files you wish to modify. In the pack and go options, you can add a suffix for _Rev B or something similar to those files and that way, the Rev B top assembly will reference the Rev B parts and there will be less chance of reference confusion. This now makes the migration into PDM a bit harder as you must clean up the files names during the migration and that could certainly lead to reference issues.
Since writing this article, there have been some tools developed that can do renames and re-referencing en masse for a migration into Enterprise PDM which makes option 2 much more attractive for the time being as it would reduce the possible reference issues you might have other-wise.
Feel free to give us a call and ask for me and we can chat about your situation more in depth if you like.
Thanks,
John