Is it possible to have a revision table that hides old revision entries?

[arron.craig]

I have a revision table with 4x rows and when a new revision is made, the oldest revision is deleted, all entries are shuffled down before the newest revision is added to the top row.

I have this automated in Inventor and am looking for a suitable way of improving this process in AutoCAD, any suggestions are welcomed.  

[pendean]

Can you provide screenshots showing before/after?

[arron.craig]

In the image below I have 4 revisions entered in cronological order. If I want to add revision E then revision A must be removed manualy and each revision needs to shift into the next cell so the new order is B,C,D & E.

Revision B would move into REV1, BY1, CHKD1, DATE1, MOD1 etc.

What we currently do is manualy re-type the revision details into the next cell which is very time consuming and prone to errors, some users don't bother and so we end up with revision tables completely out of order.

I am sure there is some other common workflow that would be a better option but if not, I would like to automate the current method as much as possible.

[Libbya · Accepted solution]

The following screencast shows how to set it up with a linear parameter and an increment.  Each increment you pull the linear parameter moves the attributes and also makes another of them visible.  You can do the same for any number of attributes or any number of states.  If you expand that concept, I believe that is about as automatic as you can make what you describe.  If you get stuck and need more assistance, post the block.  If that is not what you are looking for then offer a better description and post the block.

[arron.craig]

@Libbya, That is absolutely brilliant! thank you. 
You've done quite a few things I am not familiar with, so I will have to go through this slowly later tonight. 

Do you know if it's possible to turn the visibility of Rev1 OFF after Rev5 is turned ON? Rev2 turns OFF after Rev6 turns ON etc. So that there are only ever 4 revisions visibile?

[Libbya]

Sure.  In thinking about it some more you could have just a single lookup pulldown and select the current revision number.  The single lookup would then move the appropriate attributes where they should be and change the visibility state.  The linear parameter and double-lookup is probably more complicated than necessary.  If you want that demonstrated, then post the block as I didn't save the example block and would rather not start from scratch again.  

[arron.craig]

Ok great, I will see how far I get with it and report back. Thanks again.

[Anonymous]

Sometimes you can save a lot of time and effort by things the simple way.

Since you currently destroy any history beyond the last four revisions, I will assume that they are not required and the actual issued drawing files will provide the history if needed.

I would  attack the problem by using simple nested blocks instead of using dynamic blocks. The result is much less work than creating and modifying the dynamic block method shown above.  The blocks being "removed" could be placed on a no plot layer and turned off if you wanted to keep them.

[Libbya]

I don't think that would be simpler even on the initial setup and it would be more work with each revision change.  

---

@Anonymous wrote:

Sometimes you can save a lot of time and effort by things the simple way.

Since you currently destroy any history beyond the last four revisions, I will assume that they are not required and the actual issued drawing files will provide the history if needed.

I would  attack the problem by using simple nested blocks instead of using dynamic blocks. The result is much less work than creating and modifying the dynamic block method shown above.  The blocks being "removed" could be placed on a no plot layer and turned off if you wanted to keep them.

---

[Libbya]

Here's the single-lookup method I referred to.  Select the revision number, then edit the attributes for the latest revision.  If you have multiple sheets and want the same revision information shown on each sheet within a set, you can also do that using custom sheet set properties and fields referencing those properties.  

[Anonymous]

If multiple drawings will have the same revision text, then nesting blocks would be useful to update all drawings. If the revision block is valid for only one drawing, nesting blocks would not be necessary.

Unless one has a crystal ball, each drawing revision requires changes to the lookup table (Rev, By, Checked, Date, and Modification). Modifications would be easier by editing simple attributes than by editing the lookup table and visibilities in a dynamic block.

Currently the OP does not appear to be saving the earlier revision lines.  If they are no longer needed, they can be easily erased with standard blocks - with a dynamic block retaining all revisions, it is more difficult task.

The number of drawing revisions that will be made is unknown. A dynamic block requires a fixed number due to visibility issues.  Adding more revisions to a dynamic block means a user must deal with visibilities and measurements.

If multiple users need to update revisions, some may have to learn how to modify dynamic block lookup tables (see OP responses above) but most would know how to modify block attributes.

[Libbya]

---

@Anonymous wrote:

If multiple drawings will have the same revision text, then nesting blocks would be useful to update all drawings. If the revision block is valid for only one drawing, nesting blocks would not be necessary.

---

Nested blocks would not be necessary in either case.  As I mentioned in my last post, sheet set custom properties could house the revision information for all drawings in a set and sheet set fields could display that information in the attributes of the dynamic block.

---

@Anonymous wrote:

Unless one has a crystal ball, each drawing revision requires changes to the lookup table (Rev, By, Checked, Date, and Modification). Modifications would be easier by editing simple attributes than by editing the lookup table and visibilities in a dynamic block.

---

After making the initial dynamic block with EXTRA revision date attributes set up, there would be no need for a crystal ball and no need to edit the lookup table or visibility states ever again - not for the current project and not for any consequent projects that used the dynamic block.  It would simply be a matter of editing simple attributes.  There would be multiple advantages to the dynamic block version over using nested blocks.  The attributes that needed editing would be immediately available by clicking the block.  There would be no need to enter block editor for editing the attribute values of nested blocks.  Adding the next revision date would require just a single click vs. redefining nested blocks.

---

@Anonymous wrote:

The number of drawing revisions that will be made is unknown. A dynamic block requires a fixed number due to visibility issues.  Adding more revisions to a dynamic block means a user must deal with visibilities and measurements.

If multiple users need to update revisions, some may have to learn how to modify dynamic block lookup tables (see OP responses above) but most would know how to modify block attributes.

---

As I said above, it is very easy to set up the block initially with more revision dates than are likely to ever be needed in a similar project.  No user would EVER need to edit the visibility states or the lookup table ever again - not for this project and not for any other future project that needed to use the revision block.    

Your responses lead me to believe that you do not understand how the dynamic aspects to the block would actually work as you continue to say things that are not accurate about them.  If you have questions I am willing to help.  
  

[Libbya]

@WashingtonG The prior screencasts were only focused on building the block.  The building process would only need to be done ONCE, ever.  The following screencast shows the workflow of actually using the block.  As you can see, adding another revision date is the simple process of selecting the next revision letter and entering the information into the attributes.  That is far simpler than any method I can imagine that would use nested blocks for housing the information.  Furthermore, if multiple sheets are needed, either the single block could be copied to each sheet after the additional revision attributes have been filled out, or as mentioned previously, sheet set custom properties could be set up once in the sheet set template, and then filled out as needed for a given project.  Then with fields added to the attribute values in the block definition, the fields would update the attribute values automatically.  See screencast.

[Libbya]

Screencast was not posting correctly... here it is:

[Anonymous]

After closely following the video, I have to admit your method was faster under the conditions presented.

As far as adding revisions (more than the default placeholders of the initial block),  editing the block is still required to get the correct revision visibilities and positions.

The simple block configuration does have its place - some companies only show revisions that occur in the drawing. For instance,  drawing 1 (shows revisions 1,2, and 3) , drawing 2 (shows revisions 1,2, and 4), and drawing 3 (shows revisions 2,4, and 5). This scenario would require editing the attributes of each dynamic block to show all three lines stacked and without spaces between them. In my opinion, this is a case where the simple block configuration would be faster.

I do have a suggestion for your block - the "Y" position should be the same for the first four revisions. This would position the revisions starting directly above table heading rather than leaving blanks between revisions and heading.

[Libbya]

---

@Anonymous wrote:

After closely following the video, I have to admit your method was faster under the conditions presented.

As far as adding revisions (more than the default placeholders of the initial block),  editing the block is still required to get the correct revision visibilities and positions.

---

That's a total non-issue.  When initially building the block it takes a minute to copy the attributes for another revision date.  As I've mentioned, simply add more revision date attributes into the block than are EVER likely to be needed.  If the typical project sees 5 revisions, then add 10 placeholders, or 20, or 50... just in case you'll ever need them.  The initial time involved is minuscule.  

---

@Anonymous wrote:

The simple block configuration does have its place - some companies only show revisions that occur in the drawing. For instance,  drawing 1 (shows revisions 1,2, and 3) , drawing 2 (shows revisions 1,2, and 4), and drawing 3 (shows revisions 2,4, and 5). This scenario would require editing the attributes of each dynamic block to show all three lines stacked and without spaces between them. In my opinion, this is a case where the simple block configuration would be faster.

---

I also disagree with that.  The company I work for actually does exactly what you describe and it is easier and faster to use the dynamic block that I have set up for the company that uses project based custom properties and fields.  A block configuration like you describe would be both considerably more effort to use and much more prone to errors.  No editing of attributes are ever required as the information is housed at the project level.  The method of selecting the individual revisions that are to be displayed is different (and more complicated) than what the original poster has described so it is not actually relevant to this thread, but it is still considerably simpler to use than nested blocks.

---

@Anonymous wrote:

I do have a suggestion for your block - the "Y" position should be the same for the first four revisions. This would position the revisions starting directly above table heading rather than leaving blanks between revisions and heading.

---

That is easily doable, but I do not believe that is what the original poster requested.  Regardless, they can use the concepts presented to build the block to accommodate whichever way they choose based on their own company standards.