6 Replies Latest reply on Aug 8, 2011 8:24 AM by Tim Read

    Exploring alternate designs

    Tim Read

      Hello All,

       

      Question: What is the best way to handle alternate design modifications (part already in Production) within an EPDM environment?

       

      Options:

      • Create copies with new part numbers - replace the original file with the selected modified design.
      • Copy the file outside of EPDM and create multiple copies outside the vault - replace the original file with the selected modified design.
      • Create multiple versions with differing designs (leapfrogging) - checking out final version then 'getting' the selected version.

       

      Any better ideas? I don't like an of the above, that's why I am posting the question here...

       

      Thanks,

      Tim

        • Re: Exploring alternate designs
          Rod Levin

          Tim,

          Another alternative is to create a separate "Experimental" part numbering system. This is definitely old school, but my former company had an old accountant's ledger that you would write the next sequential number, a description, project, etc. You would use this number until a final decision is made as to which alternative is to move into production.

           

          I am not suggesting that you find an old ledger, but a similar process could be created in Enterprise. We had many departments, so each had their own prefix. I think ours was EXD-#####.

           

          Regards,

          Rod Levin.

          • Re: Exploring alternate designs
            Jason Capriotti

            We are faced with the same dilemma. A new design might require using existing parts but they may need to be modified for the new design. The new design might be a year or two in the making before its finally released. These modified parts can't just be checked out and changed as all the existing production assemblies would show the "what if" changes that are occuring to the existing part as its being redesigned. The part also may under ECO changes as the existing designs are further refined for manufacturing and field changes.

             

            The users currently work outside the system. We haven't yet implemented the practice but we are considering just having them copy the production file to their project and work on it there. Then when is finally reasy for release, we'll have to validate that the original hasn't ungone a revision or change since the copy was created, then just over write the production copy with it. I think this is better than them working outside the system and have some files in and some out.

            • Re: Exploring alternate designs
              Jeff Sweeney

              That is a tough one. I haven't found any solution I love. The one I recommend is to remove the read only flag as described here:(http://www.3dvision.com/wordpress/index.php/2010/12/27/what-if-workflow-workaround/)

               

              Though if you have a design cycle as long as Jason Capriotti mentions (one or two years) I wouldn't do it...that is a long time without backups.

                • Re: Exploring alternate designs
                  Tim Read

                  Nice info but...

                   

                  This would be worse for us than working outside the vault. Working outside the vault the files can be stored on a network drive which is backed up. Working this way would mean working in the local vault (On the C:\ drive) and it is not backed up... It also does not cater for multiple concurrent "what if" scenarios.

                    • Re: Exploring alternate designs
                      Tim Read

                      Hello All,

                       

                      I have come up with a method that works for me. (Currently still testing but it's looking good!)

                       

                      • A Dispatch script prompts for a "Branch" name and then copies the file to that "Branch". (e.g. "original filename.branch.sldprt")
                      • The Dispatch script also sets the "Branch" variable on the datacard of the copied file to the Branch name. The "Branch" variable will help to control the file within the workflow and to ensure that a branched file cannot be released to Tooling or Production.
                      • The branched files will kept in the same folder as the original for now to simplify the next step...
                      • A second Dispatch script is used to copy a branched file back over the top of the original (tests will be done on filename, etc) and set the "Branch" variable back to "Main". ("Main" will never be allowed as a branch name)

                       

                      Assemblies will also be able to be branched but they will not be able to be merged back - any broken mates in the original assemblies will be fixed after merging back the changed files.

                       

                      Drawings - I have not decided on... the idea of branches is for design exploration.

                       

                      I hope others will find my investigation and process ideas helpful.

                       

                      Tim

                       

                      PS. If this all sounds a little PTCish that is because I worked with their software for more than 10 years...