Hi Everybody,
Suggestion was made to use "shared files" for SolidWorks parts within EPDM.
For things like going from a working folder to Released folder. But keeping the master file in the working folder.
Does anyone have experience using Shared Files?
As in copying a file and then "Paste as shared" into another folder
Is it a good approach?
Works good for files without references...Office documents, pdfs, dwgs, etc.
You have to be careful with SOLIDWORKS files, because references can get weird - if both shared files are used in editing. If one of the shares is intended for read only viewing with eDrawings, it probably isn't that big of a deal.
Jeff, thanks for the feedback. What did you mean by references can get weird if both shared files are used in editing? Do you mean if I modify one file in one folder this week, adding features and such, and then continue modifying the shared copy in a different folder later, it will somehow go badly?
HI, I think an excellent approach work with shared files, search tools can help you find the files if you want to delete them and is a great way to get around cases where it is necessary to look at the files in the same folder similar to what happens in the windows.
The EPDM manages very well the references and does not generate inconsistencies repeated files.
I recommend and if you have any doubts may report I help with the cases I've worked on.
I hope you have been able to give you more confidence.
Remembering to have a test environment is always valid, so able to address all possible difficulties.
Best Regards.
We have only shared "read-only" files, typically PDF files with no check out rights, between folders. Users tend to think a file in a folder is unique since that is how it works in Windows Explorer. Many don't understand that when they edit a file in a folder, it affects files in other folders (because it is actually the same file).
Hi Chris B,
Have you made any progress or decisions with your shared copies? Are you still going ahead with a Product Development (WIP) area and a copied file in the Released Area?
I've struggled with the same problem of keeping Released files scattered across the vault, or pulling them into a structured Release area. I was just curious what decisions you may have made.
Greg,
Hi Greg,
No decision yet. Worried about what's been posted about shared copies on this forum. So far no one has said shared copies work really well for what we're trying to do.
Jefferson made a good point to test their functionality in a test environment. Concerned our test environment may not reveal all the problems associated with shared files . And that we'll use them and later find big problems with the Vault which we've so painstakingly cleaned and reorganized.
Would seem better to avoid them completely for SolidWorks files, as Michael alluded to above.
I will do some testing, but these quotes below don't give me much confidence to proceed with them. (Taken from other forum posts)
“Although it is possible to paste shared SolidWorks assemblies, it is not recommended as it can create problems with check in and check-out.”
“Shared files is great for nonCAD files, be careful with CAD files, they can make a mess of your references. From my experience, most companies forbid sharing CAD files.”
“I don't know any EPDM admins who recommend using paste shared with CAD data due to references and deep problems that can occur.”
Yes, I would agree with the comments. Regarding references, if you have an assembly in the Development area, its going to have a whole set of OS file path references to all its child parts (also in the Development area). When you open that same (shared file) in your Release area, all those references will still be pointing to your Development files. If you change them to the Release area, then the file back in the development area is all wrong. Hence the mess.
I don't have a deep enough knowledge of Solidworks references to know if they are absolute, relative, or when exactly EPDM manipulates them. And, I have the added complexity of Inventor, so I'm probably just going to stay away. I'm going to let my Released files remain in their project folders for now and let EPDM do its search magic. At our company, its the PDFs & DXFs that are the manufacturing files anyway.
If your shared-copy will only ever be read-only and never checked-out, you will be good. Someone once told me the only good reason for a shared file is when its imperative to have the same file locally in multiple directories... like a config, ini, logo, readme, or something. I think I would tend to agree.
Greg,
Chris,
Did you ever figure out a resolution to this issue. I am in much the same boat. Essentially, I have a 'Master Folder' that is supposed to house all parts, assemblies, drawings and PDF's. When a change needs to be made, we create an ECO, which is in its own directory. Placing the files into the ECO folder to work on them, and then when files are released, they go back to the 'Master Folder'. It seems like the Paste Shared is the best method to do this, but it appears that there is a lot of uncertainty of doing this.
Does anyone have any other workflow suggestions if this does not seem like a viable option? Jeff Sweeney Michael Dekoning Jefferson Oliveira G Silva
Thanks in advance,
Hi Jason. We did not find a resolution yet, other than to avoid shared SolidWorks files at all costs.
Thanks for the quick reply. I am baffled as to what to do. Surely it would be possible to write some add-ins or dispatch that could handle, but I have yet to see anything that even slightly resembles our situations.
I think Sweeney said it well:
"Works good for files without references...Office documents, pdfs, dwgs, etc."
However, I have not tried Paste as Shared for myself, didn't seem worth it.
As far as ECO process - there are many ways to handle showing which files are involved in a given ECO. I recommend tagging them with an ECO number variable, and then they all come up in a search. It is superior in many ways to Paste As Reference (though I seem to be in a minority on this subject). Many Admins have made Paste as Ref work for them, so that the ECO document is treated as the parent of the SolidWorks files being modified.
See also: Re: Automate "Paste As Reference"
I will keep beating this drum until I learn a better way.
Brian,
So in regards to your ECO# tags, is this something that a part or assembly will have multiple tags associated as the files go through multiple ECO's? Are the ECO variables used behind the scenes only? Meaning the variable is present, but not in the file name or something like that.
To help me understand, I have attached a quick drawing. (Faster than me trying to do a pretty diagram). I guess I want to be sure I understand how you would perform the circle of life. The thing that makes this 'tricky' to me, is that if there is a referenced file, how does EPDM handle this? Will it only use the reference at all times? What if I DO want to make changes to the referenced file in this process?
Thank you all for your help. I apologize if I am using the incorrect terminology or thinking processes, but that is why I am here...
Jason Owens wrote:
Brian,
So in regards to your ECO# tags, is this something that a part or assembly will have multiple tags associated as the files go through multiple ECO's? Are the ECO variables used behind the scenes only? Meaning the variable is present, but not in the file name or something like that.
Jason,
I have to be quick right now. The ECO variable is one of many data card variables you would have (material, title, author... etc). All card variables are searchable. No need to change the filename to tag it. Yes PDM makes renaming and moving files easier, but it is still not something you want to do all the time. Errors in SolidWorks references are still possible.
I put in ECO as a version free (VF) variable (does not require check-out, check-in) - on all files being changed as part of the EC. And then every time it is released the VF is written to a standard variable, and there you have history. Select "All Versions" in a search and you can find all the files in an old ECO (using "Released ECO" field). Otherwise you won't find old stuff, only the version currently visible on the data card.
Relevant Part of Search Card shown below.
That's a start. Hope that helps.
Brian,
Much appreciated. I have a small understanding of what you are speaking of. I will try some similar settings and see what happens. I think the part that I am not sure of, is how you still get the files in both ECO locations and 'Master Folder' locations. I guess you could say that the Master Folder (in my case) is only accessible by managers. The manager would need to give an approval to create the ECO, which would then put the files in the ECO directory where engineers or CAD folks can access and make design changes. Once complete, the managers will approve and put the files back into the Master Folder location.
Your info helps me understand some things I did not know before (VF) that helps me talk the talk.
More here 2014 SOLIDWORKS PDM Help - Version Free Variables
What you are talking about (manager approving the ECO work at the start) is usually accomplished with States. Look up more about "workflows". Re: Grade my workflow
Manager changes state to Edit (or WIP, or whatever you want to call it) - but the files don't actually move anywhere, they just have a different label and permissions on them.
Also be careful about locking down permissions too much. The more security you have the more Admins (or managers, depending how you set group permissions) will be busy doing things that other users could do for themselves if allowed (depends on level of trust, size of group, and what regulations you must follow). Good habits and a good culture can replace many of the PDM controls that are sometimes overused.
I think this is ultimately what my question was all along. How do I make the workflow take a file from the master folder, move it to a ECO folder, do all of the work in the ECO folder (while the original unchanged documents in the master folder are still accessible by manufacturing), then once released, goes back into the Master folder where the files are rev bumped and history is maintained.
I have the ECO workflow itself nailed down, its the getting the files from the Master folder to the ECO folder, then back to the Master folder upon release.
Why do you insist on moving the files? No offense intended - I'm not sure if you have special requirements (every company is different) or if you are just unfamiliar with EPDM.
Normally in that situation the manufacturing guys can be set to only see the released revision - at most they would know that the file is being worked on, but they would not have access to the versions/changes that are not finalized. So again that is done with permissions and states rather than moving files.
No offense taken. I am not actually dead set on moving files, I think I am trying to figure out if there is an ECO that gets created, how can you quickly link/see/know what specific files that ECO was used to change. I have assemblies where files may be located in different Master sub folders, so to quickly see what files that ECO is touching, without having to do a 'search' is why I lean that way. I understand the permissions about who can read, write, in different states etc etc. My goal is to try and quickly determine what files are needing to be 'edited' in the ECO, when there isnt a staple answer of 'all files in this folder only' are to be changed. I am sure my communication skills are not terribly accurate, but the big picture is to help not only management, but new users to EPDM to understand its workflow. We are a small staff, with easily 25 to 30 projects going on at the same time. It gets super confusing when users cant stay focused on one project from start to finish.
Hopefully I do not sound like I am being difficult, I think I just need to 'see' the steps that others are taken to control this data.
As a FYI, part of the reason that I need to quickly know all files that are touched in each ECO is we are regulated by the FDA. As a result, and any second, I have to give account to every document related to every change and why. This may or may not help see into the window of my requirements/needs.
I appreciate all of your time, regardless.
Try taking a look at using the EPDM Items. They have their own cards, workflows, versions/revisions and metadata. I have a vault that uses items as document bucket. My item is just a standard serial number counter and uses a variable for the "part number" called "Item Number". We attach all documents associated to that part number to the EPDM item (know as our Item Container or IC). We can now access all document related to a specific part number. It's a great tool for collecting all sorts of information. We use this as a backbone and then our CRM tool uses API to collect, filter and display documents inside the CRM tool for editing and building a compiled quote with documentation into a single pdf file. We also use EPDM Items for some part numbers that require certifications and serial numbers. For this we create a item that is the actual part number and then assign serial numbers to the item/part number that are based on work order and sales order. That one sounds complicated but not really.
EPDM Items is not installed in the default installation so you would need to modify your install and add it.
Ryan,
This does seem like the best suggestion for what I am trying to do. I like it! Thank you again for replying.
Just like the rest of the SW products..it's not all sunshine and roses. There are a couple GetItem API calls that have issues and are really slow! We have workarounds but they are know "critical" bugs that haven't been addressed since 2013!
But overall these work nicely.
"so to quickly see what files that ECO is touching, without having to do a 'search' is why I lean that way."
In my experience the Search is the good part, it is why the tagging method is strong. The Search Results Window acts just like a Windows Explorer folder. It pulls together every file with the EC number on the card. And then you can further filter results if you just want .slddrw or whatever.
You can run tasks, Dispatch scripts, open, check-in-out, rename, copy tree, change state... etc.
From the Contains tab you can't do any of this (one reason I don't like Paste As Reference).
The only hurdle, I think minor, is getting the EC number added to the relevant files. You are going to need to find and select them somehow, with any method. Dispatch can be used to mass add the ECO number to multiple files, as long as they are displayed in the same Folder, or in Search results (but that is a bit of Catch 22).
I am beginning to understand what you are saying. How are you giving a file multiple ECO tags if it goes through multiple ECO's. The version thing I am not fully grasping. Feel free to just point me in the right direction if there is a wiki on this specific process.
2014 SOLIDWORKS PDM Help - Versions
Versioning is fundamental to the value of any PDM system. Each released Version is called a Revision, and each Revision of a file should have a different ECO number on it. Users can get any version on demand (depending on permissions).
A Version number is tracked with a simple counter - one per check-in. A Revision is an official stamp (A, B, C, or whatever) per your change management system.
So version 31 might be on Rev C... version 40 might be Rev D...
I was going to mention, don't forget about the engineers ability to copy, move, pack & go, etc. That master folder should be readable by your engineers. You could use a template to assign an ECO number and setup the ECO folder structure, and then just have the engineers copy the files. As well, there's also an ability to execute a console style copy command from within either a transition, or a Dispatch script. Might be of assistance.
I've created tasks to perform these jobs, including keeping the references in order.
PS: Definitely not the prescribed way to use EPDM, but I'm doing things almost identically to you.
Greg,
EPDM 2014SP4
Shared Files are great, but I wouldn't make "Sharing Files" to another Folder Part of our Procedure...
Access and Visibility shouldn't be enough reason to Share a complete set of files to a different location. Instead of a Folder you can use a Search Card if you want to direct certain users to a group of files that meet your conditions. ie. You can have a Search Card called "Released" that Filters files only in that State. This is not only Fast but it gives you more control over finding what you need:
-Released Files Transition in last X number of days
-Released Files for a specific Project/Product Line
-Released Files created by a specific user
-Released Files by type (SW, PDF, Word, Excel, Pictures....)
... or combine that criteria for very specific search result...
Gents,
Thank you for your inputs. I do understand the usage and difference between versions vs revisions. I am just having troubles communicating the questions for the situations I am trying to resolve.
Shared files at first sound like a great thing, but in my experience of testing shared files, I found it didn't really help, and it added another layer of complexity to the system. For example, if you shared a file to another folder, then later wanted to delete it from the vault, you would have to go to every folder it is in and delete the file. When, some folders or workflow states don't allow deleting of files the real headache starts. If you were trying to clean up later on (deleting or moving shared files), you can't.
The search tools and the contains and where-used references seem to work quite well for finding or grouping related items. The workflows eliminate the need to have working and released folders, because you can control visibility of versions of files at each state.
So far, I've not allowed sharing of files anywhere in my company's vault.
I'm not saying don't do it. Just make sure you thoroughly test it out before deciding to use shared files.