My company wants to start using PDM Workgroup. They have been saving there SW files in windows up to this point, and have MANY files which contain unique content, BUT have the same file name. They were able to get away with this in the windows enviroment, but PDM Workgroup will not allow multiple files to have the same name. Their "work around" to this is to make ALL .sldprt files "virtual components". I don't like this idea, because we will loose pretty much ALL of PDM's functionallity for these files. They don't care about that right now, they just want to get the files into the vault. Does anyone foresee any other problems this might create? I am trying to convince them NOT to do this, help!!!!
Eng-Tips is the largest engineering community on the Internet
Intelligent Work Forums for Engineering Professionals
-
Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Getting mutiple files with the same name into PDM Workgroup vault 7
- Thread starter SWUSER71
- Start date
-
2
- #2
When you say Virtual Components........DO you mean all the parts will be in Assy.???
What about drawings? Do they have unique names?
If yes, What about the revision control on Virtual components?
The best way would be to Change the names of files in SWX Explorer.........
What about drawings? Do they have unique names?
If yes, What about the revision control on Virtual components?
The best way would be to Change the names of files in SWX Explorer.........
- Thread starter
- #3
Yes, all part files will be internal to the assemblies.
They don't seem to care about revision control or search capabillites for their existing files. They are looking for a quick fix to get the files into the vault (they don't want to spend "waste" time renaming the files (a few thousand).
Their solution:
make all existing part files "virtual"
check into the vault
when a revision or "save as" is done, save virtual components as external files
then clean up any issues for the new files or next revision.
I am afraid that we may encounter some unforeseable problems in the future by making ALL .sldprt files virtual, just to get them into the vault.
They don't seem to care about revision control or search capabillites for their existing files. They are looking for a quick fix to get the files into the vault (they don't want to spend "waste" time renaming the files (a few thousand).
Their solution:
make all existing part files "virtual"
check into the vault
when a revision or "save as" is done, save virtual components as external files
then clean up any issues for the new files or next revision.
I am afraid that we may encounter some unforeseable problems in the future by making ALL .sldprt files virtual, just to get them into the vault.
-
2
- #4
Sounds like another company where purchasing/marketing runs engineering.
You can't have files of the same name in PDMW, or in the Windows environment in the same folder.
My suggest is to name each file their respective P/Ns.
Do it half-*ss now, pay for it later.
Chris
SolidWorks 10 SP4.0
ctopher's home
SolidWorks Legion
You can't have files of the same name in PDMW, or in the Windows environment in the same folder.
My suggest is to name each file their respective P/Ns.
Do it half-*ss now, pay for it later.
Chris
SolidWorks 10 SP4.0
ctopher's home
SolidWorks Legion
In my experience it will take almost same amount of time for both options.......
Because only way I know of making a file virtual is to open assy.but he renaing can be done in explorer at much faster rate.
Do a comparison on both methods & show them the time difference & let them decide.....
I know that some people like to see a gud business case in even havin a WIFE or girlfriend......So in that case give them a comparison of.....okay I quit
Because only way I know of making a file virtual is to open assy.but he renaing can be done in explorer at much faster rate.
Do a comparison on both methods & show them the time difference & let them decide.....
I know that some people like to see a gud business case in even havin a WIFE or girlfriend......So in that case give them a comparison of.....okay I quit
- Thread starter
- #6
I've tried to tell them that. Garbage in garbage out, right?
It's a matter of, the people making the decisions don't use the programs. I need concrete reasons to convince them to not do this... they are not listening to "it's not how the program is intended to work".
I was hoping someone could tell me of some problems which might arise from this method.
I'm also trying to change how they use SW in itself. They have created "work arounds" because no one really knew how to use SW (and the few who did alittle, did not want to speak up).
**they DON'T use toolbox items (they redraw everything, multiple times, so they can add properties to the file, no one knew how to do this with toolbox items, so a "work around" was created.
** they create some of their assemblies, in part files, because that's the only way they can get FEA to work
**they don't insert model items for dimensions, so they fake a foreshortened dimension.
**they create a sketch of points, locate them with dims, then go to hole wizard and add relations of the points in hole wizard to the points in the sketch. (rather than dimensioning the points in hole wizard!!!)
need I say more?
It's a matter of, the people making the decisions don't use the programs. I need concrete reasons to convince them to not do this... they are not listening to "it's not how the program is intended to work".
I was hoping someone could tell me of some problems which might arise from this method.
I'm also trying to change how they use SW in itself. They have created "work arounds" because no one really knew how to use SW (and the few who did alittle, did not want to speak up).
**they DON'T use toolbox items (they redraw everything, multiple times, so they can add properties to the file, no one knew how to do this with toolbox items, so a "work around" was created.
** they create some of their assemblies, in part files, because that's the only way they can get FEA to work
**they don't insert model items for dimensions, so they fake a foreshortened dimension.
**they create a sketch of points, locate them with dims, then go to hole wizard and add relations of the points in hole wizard to the points in the sketch. (rather than dimensioning the points in hole wizard!!!)
need I say more?
- Thread starter
- #7
Time for company training.
Maybe these can be sent to management?
Chris
SolidWorks 10 SP4.0
ctopher's home
SolidWorks Legion
Maybe these can be sent to management?
Chris
SolidWorks 10 SP4.0
ctopher's home
SolidWorks Legion
-
2
- #9
Depending on the version of SW you are running you could also run into some serious technical issue with the vault and Virtual Parts. I think newer versions of the vault support virtual components, at least for check in, but I remember having serious issue with the lose of data for virtual components that were checked in. People tend to forget that a Virtual Part is not actually virtual, it just resides in a temp directory in Windows and with some effort you can find these "virtual files". There's your fun fact for the day. This plan of your management's is just bad 360°. Do the work right upfront and get things loaded into the vault correctly. Fixing it once it's in the vault is a royal PITA. And that's coming from the guy that implemented our vault.
Joe Hasik,
CSWP/SMTL/MTLS
SW 10 x64, SP 3.0
Dell T3400
Intel Core2 Quad
Q6700 2.66 GHz
3.93 GB RAM
NVIDIA Quadro FX 4600
Joe Hasik,
CSWP/SMTL/MTLS
SW 10 x64, SP 3.0
Dell T3400
Intel Core2 Quad
Q6700 2.66 GHz
3.93 GB RAM
NVIDIA Quadro FX 4600
-
1
- #10
While situations differ, making the file names unique by including the part number in the name is most likely the best solution. The part number can be either the whole name, a prefix or a suffix. Using the part number as a suffix seems to be most palatable to people who were only using a description as the name. They want to look for the file by that description and with the part number as a suffix, the files will be ordered by description.
This renaming can be done prior to checking the files into the vault using SolidWorks Explorer, or from within the vault. If done within the vault, you would check in one folder's worth of files, rename the files to include the part number and move on to the next folder.
The most time consuming part of this effort will likely be determining the part number for each file.
I would expect that making the parts virtual so that they only exist within the assembly will break all of the drawings because they will be unable to find the referenced model files. It might be possible to add fixing that into the proposed macro, but that creating that macro looks like it might take as much time as renaming the files.
What is the value over leaving them in Windows folders of putting the files into the vault in such a roundabout (other less polite adjectives come to mind) manner? It seems to me like what is being proposed will involve expending effort to reduce the usability / usefulness of your CAD data. If you do not have time to do it in a manner that provides value, why bother doing it?
Present 3 options to management:
[ol][li]Making the parts virtual. Significant time to create macro. Does not work well with drawings. REDUCES the value of the CAD data.[/li]
[li]Adding the part number to the file names. Will take a about the same amount of time as option 1. Lower risk. INCREASES the value of the CAD data. The right thing to do.[/li]
[li]Leave the current CAD files in Windows folders, and add part numbers to file names on projects going forward, which are then checked into the vault. Lowest effort. Incremental route to option 2.
[/li][/ol]
If you are lucky they will go along with either option 2 or 3. Good luck.
Eric
This renaming can be done prior to checking the files into the vault using SolidWorks Explorer, or from within the vault. If done within the vault, you would check in one folder's worth of files, rename the files to include the part number and move on to the next folder.
The most time consuming part of this effort will likely be determining the part number for each file.
I would expect that making the parts virtual so that they only exist within the assembly will break all of the drawings because they will be unable to find the referenced model files. It might be possible to add fixing that into the proposed macro, but that creating that macro looks like it might take as much time as renaming the files.
What is the value over leaving them in Windows folders of putting the files into the vault in such a roundabout (other less polite adjectives come to mind) manner? It seems to me like what is being proposed will involve expending effort to reduce the usability / usefulness of your CAD data. If you do not have time to do it in a manner that provides value, why bother doing it?
Present 3 options to management:
[ol][li]Making the parts virtual. Significant time to create macro. Does not work well with drawings. REDUCES the value of the CAD data.[/li]
[li]Adding the part number to the file names. Will take a about the same amount of time as option 1. Lower risk. INCREASES the value of the CAD data. The right thing to do.[/li]
[li]Leave the current CAD files in Windows folders, and add part numbers to file names on projects going forward, which are then checked into the vault. Lowest effort. Incremental route to option 2.
[/li][/ol]
If you are lucky they will go along with either option 2 or 3. Good luck.
Eric
Tell them it is windows based in how it functions. The entire vault functions as one windows folder, regardless to how the files within it are organized. Just like windows, WPDM cannot have more than one file with the same name. This is not a matter of choice. It is a fact.
File name conventions are the responsibility of the Engineering department to meet engineering needs. It is a matter directly relates to design intent, as file structure itself is part of the preserved data. As such, multiple files with the same name will (not "can", but WILL) create conflict and confusion in the modelling process. SolidWorks looks at 13 locations for a file before it opens it. The way to ensure that it opens the correct one is to name it with a unique name that only exists in one location on the user's local drive (when downloaded from the vault).
Matt Lorono
Lorono's SolidWorks Resources & SolidWorks Legion
http://groups.yahoo.com/group/solidworks & http://twitter.com/fcsuper
File name conventions are the responsibility of the Engineering department to meet engineering needs. It is a matter directly relates to design intent, as file structure itself is part of the preserved data. As such, multiple files with the same name will (not "can", but WILL) create conflict and confusion in the modelling process. SolidWorks looks at 13 locations for a file before it opens it. The way to ensure that it opens the correct one is to name it with a unique name that only exists in one location on the user's local drive (when downloaded from the vault).
Matt Lorono
Lorono's SolidWorks Resources & SolidWorks Legion
http://groups.yahoo.com/group/solidworks & http://twitter.com/fcsuper
- Thread starter
- #12
Thanks for all the help!!!
This is what I have come up with and have sent to management, wait and see I guess...
These are my concerns if we move forward with the proposed method of making the files "virtual" in order to check them into PDM Workgroup.
The obvious fact of why not to make a large portion of our .sldprt files virtual components (or all of the .sldprt files as suggested) is that virtual components will lose the functionality of a majority of the features PDM Workgroup provides.
After further research I have found that making all .sldprt files virtual (or even a large number of them) becomes an issue for SolidWorks performance wise, even if PDM was taken out of the equation.
Making components virtual is intended for use with minimal files, it is not intended as a way to manage your files in mass. When a component is made virtual it increases the file size significantly. For large assemblies this becomes a huge issue. Large files take a long time to process and open even with external components. Making the components virtual (thus adding to the file size) increases this process and leads to the integrity degradation of the assembly file, which will lead to corrupt files, then leading to loss of data.
There is also the issue of components being “out of context” with the assembly after doing a “save-as” and making the virtual components external again. This does not always go so smoothly and then every reference/link to every component will have to be manually re-established.
Don’t forget that if we make a .sldprt virtual and it has it’s own drawing, there are no references/links between the component and the drawing anymore. This will make the drawing worthless at this point.
During my research I have found that most people are using virtual components for components which are not necessarily critical to the assembly and using them in small numbers within an assembly, such as we are using them for weld beads.
I think that to avoid major headaches in the future our best solution is one of the following:
(1) Do some much needed housecleaning of the current situation before moving forward by rename the files which have multiple instances. Then, proceed to check files into the PDM Workgroup vault.
(2) Leave the existing files in the existing windows environment and treat them as an archival of old projects. As needed, pull a file for revision or “save as”, clean up any issues to the new standards, then check the new projects into the PDM Workgroup vault.
This is what I have come up with and have sent to management, wait and see I guess...
These are my concerns if we move forward with the proposed method of making the files "virtual" in order to check them into PDM Workgroup.
The obvious fact of why not to make a large portion of our .sldprt files virtual components (or all of the .sldprt files as suggested) is that virtual components will lose the functionality of a majority of the features PDM Workgroup provides.
After further research I have found that making all .sldprt files virtual (or even a large number of them) becomes an issue for SolidWorks performance wise, even if PDM was taken out of the equation.
Making components virtual is intended for use with minimal files, it is not intended as a way to manage your files in mass. When a component is made virtual it increases the file size significantly. For large assemblies this becomes a huge issue. Large files take a long time to process and open even with external components. Making the components virtual (thus adding to the file size) increases this process and leads to the integrity degradation of the assembly file, which will lead to corrupt files, then leading to loss of data.
There is also the issue of components being “out of context” with the assembly after doing a “save-as” and making the virtual components external again. This does not always go so smoothly and then every reference/link to every component will have to be manually re-established.
Don’t forget that if we make a .sldprt virtual and it has it’s own drawing, there are no references/links between the component and the drawing anymore. This will make the drawing worthless at this point.
During my research I have found that most people are using virtual components for components which are not necessarily critical to the assembly and using them in small numbers within an assembly, such as we are using them for weld beads.
I think that to avoid major headaches in the future our best solution is one of the following:
(1) Do some much needed housecleaning of the current situation before moving forward by rename the files which have multiple instances. Then, proceed to check files into the PDM Workgroup vault.
(2) Leave the existing files in the existing windows environment and treat them as an archival of old projects. As needed, pull a file for revision or “save as”, clean up any issues to the new standards, then check the new projects into the PDM Workgroup vault.
@SWUSER71-
You say the "they" don't want to waste time renaming files. I'm not sure who "they" are, but the time they save now won't be a drop in the bucket to the time spent cleaning up all the crap that will be coming. As is typical of many in management (I'm assuming that "they" refers to management), who have no clue about the 'how' of things, they are content to sweep it all under the carpet and deal with it as it pops out. The problem with this when dealing with CAD is the problem can quickly propagate through numerous files, be they parts, assemblies or drawings.
By following their instructions, and dumping a bunch of non-viable files into your PDM system, you'd only be creating an unstable foundation on which to build. Eventually, it'll all come tumbling down and the time you didn't "waste" now would be minuscule compared to the time needed to clean up the mess that was, ultimately, created by those who shouldn't be making the decision on the how.
I wish you luck. I certainly hope you don't end up with a big "I told you so".
Jeff Mirisola, CSWP
Design Manager/Senior Designer
M9 Defense
My Blog
You say the "they" don't want to waste time renaming files. I'm not sure who "they" are, but the time they save now won't be a drop in the bucket to the time spent cleaning up all the crap that will be coming. As is typical of many in management (I'm assuming that "they" refers to management), who have no clue about the 'how' of things, they are content to sweep it all under the carpet and deal with it as it pops out. The problem with this when dealing with CAD is the problem can quickly propagate through numerous files, be they parts, assemblies or drawings.
By following their instructions, and dumping a bunch of non-viable files into your PDM system, you'd only be creating an unstable foundation on which to build. Eventually, it'll all come tumbling down and the time you didn't "waste" now would be minuscule compared to the time needed to clean up the mess that was, ultimately, created by those who shouldn't be making the decision on the how.
I wish you luck. I certainly hope you don't end up with a big "I told you so".
Jeff Mirisola, CSWP
Design Manager/Senior Designer
M9 Defense
My Blog
- Thread starter
- #14
good news! we are moving forward with option #2
(2) Leave the existing files in the existing windows environment and treat them as an archival of old projects. As needed, pull a file for revision or "save as", clean up any issues to the new standards, then check the new projects into the PDM Workgroup vault.
(2) Leave the existing files in the existing windows environment and treat them as an archival of old projects. As needed, pull a file for revision or "save as", clean up any issues to the new standards, then check the new projects into the PDM Workgroup vault.
rgrayclamps
Mechanical
Hi, SWUSER71:
I am glad that you are heading in the right direction. We did the exact same thing many years ago. Those documents are considered legacy documents.
As Joe Hasik mentioned, virtual parts or sub-assemblies are local to one's machine. They just reside in a temp directory in Windows. They have short life. They are not physically imbedded in your assemblies. If you clean your temp folder, your assemblies won't be able to reference them. I am not sure if one can make "virtual parts" reside on a network. Also, there is no such thing as "Virtual Drawing" that I know of.
Virtual parts or sub-assemblies are intended for quick concepts.
Best regards,
Alex
I am glad that you are heading in the right direction. We did the exact same thing many years ago. Those documents are considered legacy documents.
As Joe Hasik mentioned, virtual parts or sub-assemblies are local to one's machine. They just reside in a temp directory in Windows. They have short life. They are not physically imbedded in your assemblies. If you clean your temp folder, your assemblies won't be able to reference them. I am not sure if one can make "virtual parts" reside on a network. Also, there is no such thing as "Virtual Drawing" that I know of.
Virtual parts or sub-assemblies are intended for quick concepts.
Best regards,
Alex
CorBlimeyLimey
Mechanical
DeckerDesign said:
rgrayclamps said:
Sorry guys, I have to completely disagree with you. While VC's are initially created in a temp folder, they are indeed stored within an assy when the assy is saved.
For proof, please open the attached simple assy comprised of three VC's.
CorBlimeyLimey
Mechanical
See also the first line at
CBL,
You've got me there, but I'm not entirely certain that this is universal behavior for VC's. I recall the same behavior Alex mentioned above in earlier version of the software, most notably when the VC's were first introduced. There were serious issues with how they played with the Vault and values in temp directories changing, resulting in a total loss of the VC. I had this happen a handful of times, and was never able to confirm if it was expected behavior of the way VC's were coded at the time or just another bug in the software. SWUSER71 doesn't mention his version of the software. given that he can use VC's narrows down the choices, I thought it best to play safe and give him the worst case scenario. Also not sure how well this concept works on larger, more complicated assemblies. Too many things can be demo'd to work great in SW provided you keep features simple, quick, and dirty. Part of why making the move to the next major release is always such a headache.
</rant>
Joe Hasik,
CSWP/SMTL/MTLS
SW 10 x64, SP 3.0
Dell T3400
Intel Core2 Quad
Q6700 2.66 GHz
3.93 GB RAM
NVIDIA Quadro FX 4600
You've got me there, but I'm not entirely certain that this is universal behavior for VC's. I recall the same behavior Alex mentioned above in earlier version of the software, most notably when the VC's were first introduced. There were serious issues with how they played with the Vault and values in temp directories changing, resulting in a total loss of the VC. I had this happen a handful of times, and was never able to confirm if it was expected behavior of the way VC's were coded at the time or just another bug in the software. SWUSER71 doesn't mention his version of the software. given that he can use VC's narrows down the choices, I thought it best to play safe and give him the worst case scenario. Also not sure how well this concept works on larger, more complicated assemblies. Too many things can be demo'd to work great in SW provided you keep features simple, quick, and dirty. Part of why making the move to the next major release is always such a headache.
</rant>
Joe Hasik,
CSWP/SMTL/MTLS
SW 10 x64, SP 3.0
Dell T3400
Intel Core2 Quad
Q6700 2.66 GHz
3.93 GB RAM
NVIDIA Quadro FX 4600
rgrayclamps
Mechanical
Hi, CorBlimeyLimey:
Thanks for the link!
I knew that virtual components are supposed to be saved internally in the assembly file in which they are created, instead of in a separate part file.
But, mine were saved in temp folder. I have always been wondering why they were saved in the temp folder. I am still using 08.
Do you have control over location of virtual parts with 2010?
I do not use virtual parts or sub-asemblies as they are not reusable.
Best regards,
Alex
Thanks for the link!
I knew that virtual components are supposed to be saved internally in the assembly file in which they are created, instead of in a separate part file.
But, mine were saved in temp folder. I have always been wondering why they were saved in the temp folder. I am still using 08.
Do you have control over location of virtual parts with 2010?
I do not use virtual parts or sub-asemblies as they are not reusable.
Best regards,
Alex
- Status
Similar threads
- Locked
- Question
- Locked
- Question