Revision table and PDM integration

Vox populi vox dei – a famous sentence from ancient Rome. Some would dare say is happening with the design table in PDM. First of all I would like to state that we don’t believe that a revision table is sufficient to describe a drawing.

Revision table history

The revision table is a historical relict from a time when drawings were made onto paper. Back then every change, no matter how small, required a lot of effort and drafting hours. To this day there are stories from older engineers of how hundreds of drafters implemented engineering changes into drawings. Obviously today’s 3DCad systems are doing this job within  moments. A great idea to save time was to make a small table such as a drawing logbook (Raise your hand, who has been using the design journal feature in SOLIDWORKS!). Now all the changes were written into a small box. This made it pretty easy to track the changes seeing how every line took a lot of effort. From that time stems the logic that a header is top or bottom, depending on where you start from.
Today’s revision table becomes important when a product is being produced and designed simultaneously or when some partner in the process only has PDF (pretty much paper) drawings. In these cases the question “What has changed?” comes up a lot. It’s really convenient to see the strikethrough and added components, dimension changes and so on in that case.
Still, I always like to ask whether one can trust these changes that have been written into the table and unfortunately, the answer is a resounding “No”. With a revision control system it’s much easier to compare between versions, but let’s face it, this may not be available for the latest subcontractor.

Engineering change communication

When looking at problems that the previous post adressed, then one can see that there is no perfect and easy solution around. There are folks that believe a revision table will solve this problem. However in practice engineering changes must generally be communicated to all stakeholders in supply change, production, marketing and so on. This is pretty much manual work to this day, especially when it comes to questions about excessive (and now irrelevant) stock and changing the manuals.
Unfortunately there is no quick fix for this and it might be a permanent part of the engineering process. This is why I advise caution when seeing “perfect solutions” from CAD-PLM vendors.

Revision table integration

With this, SOLIDWORKS listened to the crowd and integrated a revision table into the PDM. There are even a lot of instructional videos on getting this to work. This being said, first impressions are that this is more like a quick patch or the minimum viable product (MVP) of a startup and not a product of the world’s biggest mechanical CAD vendor.

Allow me to ellaborate.

Predefined columns

The columns of a revision table are predefined. This is for cases where one needs to update a revision outside of the workflow (which in essence is agasint the meaning of a PDM system).

Now, how to add more values to the revision table?
This becomes relevant as in most cases the revision table also keeps track of who the author, the checker and approver have been, sometimes including the approval date as well. All of these values can be added to the revision table’s properties. Therefore just follow along and this it what it will look like after the drawing is released:

Everything is perfect as it should be, but what happens when the drawing gets its next revision?
To put it bluntly, your revision table will be f*d, because all non-default values related to the properties of the drawing will be cleared from the previous release.

Therefore, after adding a revision row, you can take a look at the screen and conclude that your entire history is gone and frankly, this is not how a revision table is meant to work *at all*.

But don’t give up yet!

Revision raises

The revision table is currently designed in a way that whenever something is added to a revision field then the system automatically adds a new row or converts “***” row to a real revision. However in practice, whenever a model is moved back to the “Under Editing” phase, then the new revision will be marked as such in the title block (for example B.00). This is to reduce confusion when someone compares a real revision with files still being edited. This also helps mitigate some risk should the PDM go outside the house and the supplies department sees a non-standard revision letter.

This is a long story, but it essentially means that the revision field should always be marked in the marked transaction as well:

While the files are moving through the process, “InitiateNew Release” and “Nextrevisio-00” will be set as revision values, but the revision is not set. This automatically generates new rows inside the drawing’s revision table. Note that both the Checker and Approver are still available in the table from the previous revision as they should be.

Seems to be working, right? Well, there is another thing. Whenever the user now fills a revision note (revision C) and sends it through the workflow a new empty revision will be added. This means that the new “right” revision is not right at all!

Please note that “Addrevision” is not done for the table because it looks like the correct revision exists there.

One possible solution is to make one more action into the workflow. Set a variable action that adds a description when “D-00” will be set, therefore indicating to the user that this row should be deleted from the design table.

When the user now deletes this “temporarilyRow” and it adds a new revision row, then the system seems work as it should.

Therefore it is possible to get the system to work. Not quite as expected, but at least to work.

Datacard and Workflow comments

What about showing the revision table in the Datacard? It is possible to show the latest revision comment in the drawing card, but the revision table itself is related to a particular drawing and cannot be pushed to a model.

Whenever there is a business need to show the full revision table, then a custom solution with dispatch action needs to be developed (this is impossible in PDM Standard).

What about the idea to write release comments into the workflow comments and then have PDM push them into the comments inside the revision table?

This is a good idea when we only release one part per workflow or one assembly in the workflow exactly as it’s done by application engineers in demos and webinar videos.

However, I would argue that SOLIDWORKS should come closer to the customers and look at how big real assemblies are and how many parts are moving through the workflow.
Having one comment for an assembly with 20 new parts and having it in the revision table simply makes no sense.

In conclusion I would say that yes, the revision table has been imlemented and it is working somehow, but I am somewhat dissapointed with the apparent lack of professionality of SOLIDWORKS when it comes to making these kinds of improvements. One would expect things like this to undergo more testing before an official release. Hopfully this will improve and users will not have to make tricks and workarounds to achieve the desired functionality.

And as always, we’re really interested in hearing your feedback on the subject. If we’ve totally misunderstood this topic, let us know how things are really done in the comments below!