SOLIDWORKS Enterprise PDM Best Practice: Non Revision Changes

When working with design documents, 9 times out of 10 the designer wants to make sure that any changes they make are recorded via revisions. Enterprise PDM does a fantastic job of doing this for us by automating the revisions through the workflows that we have set up. We release files for physical production, and when changes need to be made, we send them to a different state, make the changes and re-release them. Viola, new revision! However, what happens when we need to modify something simple on a released file? Say… a typo or new dimension? We don’t really want to create a new revision for the part or assembly just for a minor change as that would add a lot more confusion and take up more virtual real-estate than necessary. Enter the minor revision workflow loop!

The minor revision workflow loop is a great way for certified users to pull a file out of the released or production state to make those little changes that don’t actually affect the form, fit or function of the part. Also, it can be added to your workflow at any point in time without affecting your existing states and transitions. Below is an image of a standard CAD Workflow complete with a standard revision loop:

ENOVIA

Although this is perfect for most circumstances, if a file is released, the only two ways to make a minor change is to A) Send it through the “Request change” transition and create a new revision of that file, or B) Give a user the permission to check out the file while it is in the “Released” state. Option A isn’t a very efficient solution and option B is quite obviously dangerous! So the best way for us to tackle this situation is to create another loop coming from the “Released” state. Below is an image of my workflow, now complete with the minor revision loop:

ENOVIA

Now we have two options when a change is required on a file that has already been released; “Request change” and “Make a Minor Drawing Change”. Obviously the wording of the transitions may be a little different, but the effect is still the same. With this loop, we can move files to the new “Minor Change in Progress” where the users have permission to check the files out, then release them back into production. The main difference being in the transition going back to the “Released” state. When a file goes through the “Request change” loop, as it comes back around and get’s re-released through the “Change Approved” transition, the internal revision and “Revision” variable are updated with the new revision number or letter. However, when a file goes through the “Make a Minor Drawing Change” loop, as it is re-released through the “Minor Changes Complete” transition, those actions to not occur. See the difference between the two transition actions in the images below:

ENOVIA

ENOVIA

So there we have it. One loop to make a true revision change, and another simply to correct some minor mistakes. Notice how both transitions still contain the “Create PDF” action? That will ensure that no matter how you change a drawing, a new PDF will always be created once it has been re-released. For a little added security, you can also set up some conditions to only allow SOLIDWORKS drawing files through, or authentication to force users to enter their passwords before the transition, just to make them think a little!

ENOVIA

If you need more assistance or have questions, please contact Inflow Technology Support at 888-285-2285 or at support@inflow-tech.com

Derek Lawson – PLM Consultant

4 comments on “SOLIDWORKS Enterprise PDM Best Practice: Non Revision Changes

  1. How do you address the the files revision and file version being out of sync? If you put the loop in that you suggest, and change a released file without incrementing the revision the rev/version will be out of sync and the “Local version” attribute will read as “No Revision”.
    Do you have a method of automatically syncing these 2 values together after the change?
    Thanks
    Brent Hannah

  2. Alan,
    In most scenarios we would recommend that both the model and the assembly be updated to maintain consistency and control. However, that may not be the case with all manufacturers. There are some companies who may not choose to revise the actual models, only the drawings, which is understandable as the geometry is only a reference for the drawing to use. The drawing is the actual product being sent to the manufacturers. With that being said, it can really be done either way. It simply depends on your design process.

  3. Brent,
    Thank you for the feedback and the excellent question! That is actually a common issue that tends to add confusion to the process. To answer this properly, we must look at a few other aspects of how things are going to be controlled and why they actually matter.
    The first matter to discuss is obviously why we even need to keep those in sync. Enterprise PDM classifies files in two categories: Released Versions and Working Versions. You may notice the permission “Show working versions of files” under a groups folder permissions. Any file that does not have a revision assigned to it is considered a Working Version and may not be able to be seen by certain groups if that permission is not set. The only way to set a revision is to increment it manually or have it incremented during the transition, and we’ll want to do exactly that. When the file is sent back to the released state the revision does in fact need to be incremented again… but by 0.
    The second matter to discuss is how we increment the revision the revisions. The transition must have an action set up like the others so that the files that are passing through it to have their revisions incremented, thus making them Released Versions that everyone can see. However, the amount in which we increment it can be set in two different places: The transition OR the state that the file is going to. In most cases this is set in the state and that means that all transitions going to that state will have their revisions incremented by whatever number has been set, usually it is “1”. Since we now have a transition going into that state that we DO NOT want to increment by 1, we will need to change how that value is defined.
    So to answer your question, you may need to modify a little more of your workflow. First, open the “Released” state (or whatever you may have called it) and go to the “Revision Number” and ensure that the “Increment by” value is set to “0” or nothing. You will then have to go into the other transitions going into this state, click on their “Revision Numbers” tab and make sure that the value is set to “1”. Finally, open the “Minor Change Complete” transition, click on the “Revision Numbers” tab and ensure that the “Increment by” value is “0” or nothing. Then add a new action to that transition to Increment the Revision, but since the “Increment by” value is set to “0”, the revision will stay where it is at.
    Essentially what we are now doing is telling all of the transitions that are going into the “Released” state to assign a revision to the files passing through, but we are controlling which revision it should be going to based on the number it is set to increment by in the transition itself.
    I hope this helps!

Leave a Reply