I am writing to you to get your different opinions on a vast subject.... "Project Management in EPDM". I set up EPDM and we have been running with it for 5 years now with a link with our ERP PMI. The company has evolved enormously and we want to further optimize our technical data management.
We have 3 main problems :
Customer project management (Keep track of changes and a long-term history without burdening designers)
Management of off-the-shelf components (create a clear and easy-to-use library)
Reuse of existing projects (wasting the minimum amount of time when copying projects)
- How do you manage your customer projects composed of standard sub-assemblies and tailor-made designs?
- Digging a little deeper into the admin tool, I noticed an Article section. No matter how hard I look, I find very little information about this EPDM ARTICLE function. Can this be a way to manage standard components or projects ?
- Today, duplicating a project takes us a lot of time because we have to go through all the data cards to update them, it's extremely time-consuming !
There you go, lots of questions and I hope lots of answers and opinions on the subject !
I advise you to ask @Benoit.LF and @flegendre, they are 2 Lynkoa users who have implemented ePDM for a few years in a company using standards but also client configurations.
The first question is very, very broad. One way to proceed between standard and special assemblies is to place the standards in a dedicated file and the special assemblies in the business file. The numbering is generally different between these 2 elements so that they are quickly identifiable. For business assemblies, they are only open with components in "epoch" versions and not the latest version. This gives us a real picture of what the machine is like at the customer's site. (a solution that may have its limits in certain specific cases, but we will come back to this if necessary). Tell me if I am drifting from the meaning of your question! :)
We were not using the EPDM item function. The article number was the name of the file, which could only be unique. I think it's the easiest way to manage this way, UNLESS you manage several article numbers on the same file, using configuratiosn for example. Namely, what you use in terms of bills of materials.
As for duplicating a project, I think that a good part of the optimization work is to be done on the configuration of the data maps. From the map, you can for example "reset" the index data, and redefine the data of the index A (Name: designer making the copy, date: today,...) when copying the project. This is one of the basic functions of EPDM that you can see when you do a simple "save-as" of a file in the vault. Values change automatically according to the settings. To see if you reset other data.
Thank you @Benoit.LF: Indeed it's quite broad, that's why I need help. We have a bit of this way of working today a CLIENT file and a STANDARD file, with two specific numbering to differentiate them. On the other hand, we are in "Use the latest version on the whole vault" and we manage in // an EXCEL file where we note the index of the CLIENT set with the date.... It's this way of working that I find not optimal. What can be the limits you mention?
We also use a unique reference per file, and do not use configurations.
Regarding the copy part of the project, I'm afraid I don't understand what you're saying... When you talk about optimizing and setting up data maps, are you talking about "defaults" and the "replace default" option in the data map editor? On our side, when we copy a project, we have to review its destination folder and therefore its numbering (the recording folder determines the beginning of the reference), initialize the indices). The reference of a component is determined by its location in the trunk and 3 numbers defined by the designer.
So, opening the business assemblies in "latest version", I agree, it doesn't seem to be the most judicious. A business assembly being an element that has become real, in my opinion the CAD must correspond to it. Especially if you do retrofits! But it depends on your way of working, and in particular what is the limit of evolution of an article that you have set yourself before creating a new one: is adding a hole for a cable passage an important evolution and requires a change of number or a part that was a simple cube and became a Swiss cheese over the course of revisions is a possibility in your company. If the changes are necessarily minor (i.e. where to place the cursor), opening in the latest version is possible. If not, I find it risky. And it's a shame to manage an Excel file when you have a system to do it for you without error.
The limitation I mention is the disadvantage of an advantage of EPDM: in your local cache, you only have one version of each file. Let's take an example, if in your business assembly you use a standard assembly and a few years later, during a retrofit, you add a second part with the same number and having evolved, you will not be able to have a representation of reality on your CAD. Either your 2 elements will be in the old version, or they will be in the new version.
For the article number, I would then stay on the use of the file name.
For optimization, it' s indeed "defaults" and the "replaces default" option I was talking about. You know them, that's perfect, it's not the case for everyone. The initialization of the indices will be done by this means. As for renaming files and changing their folder, do you use the "Transform/Replace" button when you are in the tree copy window? It allows for pretty much the same options as SolidWorks take-home composition, which is where you can bulk edit a codification fragment or folder path.
It's hard to say about the evolutions, we assume that a clue on a part guarantees backwards compatibility and that it can be mounted instead. If the evolution is too great, we change the reference. If I have understood correctly with the history of the local cache, it is not possible to eventually have in a business assembly part A with index 01 and this same part A with index 02 ?
I discovered the real usefulness of these " replace the default " and " default values" functions a short time ago when copying an element. I also use the tree copy but the " Transform/Replace " functions do not allow me to access bulk changes of variables on data cards. I can " only " change the name of the file but without changing its data map.
Except for us, the reference entered on the data card determines the name of the file and not the other way around and at each archive the variable REFERENCE becomes the name of the file via a DISPATCH.
Utilities present in MyCadTools or MyPdmTools could not meet this need for mass data map modification?
Yes, it's usually the rule of "backward compatibility" that prevails, but in some cases it has its limits, especially if you open everything in the latest versions: "Here, I have a big hole to pass my cables for retrofitting" and finally "Oh no luck, there's no hole, I have the A index of the part... Michel, bring the blowtorch back, we'll do a touch-up! :/". I'm exaggerating the line a little, it's true! :)
That's right, exhibit A can only be displayed at index 01 or 02 (or more precisely in its equivalent version) but not both.
I understand your difficulties better. You are operating in the opposite way to what is usually done. The MyCADTools tool is BatchProperties, coupled with a MyPDMtools license to work under EPDM. (see image). Can you give us a little more detail about your codification to possibly propose a method?
You're welcome for the feedback, the topics of methodology and EPDM interest me greatly! :-)
I like your example because that's clearly what's happening, in a slightly less " rough " mode ;-), we're more forest than blowtorch at home but the idea is there.
On our side, the REFERENCE of a .sldprt or .sldasm element is the concatenation of several variables :
PREFIXE_DOSSIER: 0000 to 9999 (auto-generated based on record)
PREFIXE_SOUSDOSSIER: 00 to 99 (auto-generated based on folder)
TYPE_DE_DOC: E or M (auto-generated depending on the extension)
No. _CHRONO : 000 to 999 (No. defined by the draftsman)
When the user registers his part in the trunk (example in the 000099 folder) for the first time, a temporary serial number is given (e.g. abcdefg.slprt), the data card opens, he enters his CHRONO number (example 123) and then archives the part. The Dispatch launches and " abcdefg.slprt " becomes " 000099M123.slprt ".
This dispatch is executed at each archive, so if you modify the N°CHRONO to better order your design file for example, the reference changes again. (provided that you are in a workflow state that allows this).
The examples are always clearer! I've never had the case of taking out the blowtorch either! :)
In your case, insofar as your folder tree is already existing, if during the tree copy you indicate the right folder for the destination of the parts, there must be a possibility to automatically retrieve the PREFIXE_DOSSIER and PREFIXE_SOUSDOSSIER values (I put the conditional, I do this from memory and it is almost 3 years old!). Normally, you can retrieve a property of the parent folder. As for the timer, you won't cut it, it will remain a manual intervention unless you start developing a new dispatch.
I find your systematic renaming approach very interesting.
Indeed in the new data map (of the copied part) I have the new PREFIXE_DOSSIER and PREFIXE_SOUSDOSSIER but as REFERENCE is the concatenation of several variables, it only updates if I manipulate one of these variables (even if it means just making a space and deleting it, that's enough to force the update of REFERENCE)
It seems to me that we had this problem, we got the name of the file without extension as a reference, and we had to add a command by right-clicking "Update reference" via a dispatch.
So we drifted a little from the questions at the beginning! :)
Yes Aurélien Fives, you can do it in the workflow but from experience I avoid it because in terms of performance as soon as the Dispatch is too large it's not great.
In general I avoid Dispatch, 1 dispatch line = a few milliseconds X the number of lines x the number of files = big slowdown.
I had up to 25 seconds per file for a dispatch... Suffice to say that when it was executed on many files it was not very responsive... Especially since there is no message when the dispatch ends.
Ah, very interesting! I have already done a small introductory training of the EPDM administration, I think this question will come during my next stage of training:)