The method we use is this:
- Add a note (balloon / triangular) and link the text to the drawing's custom property "Revision", set font size and any other properties.
- Turn the note into a sketch block, and save the block to your template folder with a name like "Revision-Balloon"
- Place it outside the sheet and RMC hide it.
- Save sheet format
The next time you use this sheet format, click "insert Block", and you'll have this pre-edited revision-linked note waiting for you to fulfil its destiny.
Hope this works for you,
Iftach, I don't see the benefit to this - it doesn't do anything different than using a standard revision table and is more work. The balloon is still tied to the revision property, so when the rev changes (through an EPDM workflow) the balloons will be wrong. This is exactly the problem with the solidworks revision table that I'm wondering how people handle.
Our company has always kept the latest two revisions in a rev table on the drawing. When using a solidworks revision table, it's easy enough to just add a new row and add balloons for the new revision, and when you delete an old row it automatically deletes all the balloons associated with that deleted row. This is perfect. Except it doesn't work with EPDM, because EPDM won't add a new row, it will just change the revision property which will change the current row and screws up all the balloons.
I know I can create a "rolling" revision table (using a solidworks general table) by using a couple extra variables in EPDM, but how does everyone handle revision balloons then? Manually type the letter in each balloon and then manually delete all the old balloons? Write a macro for adding a row to the table and deleting the old row? I don't mind using macros to automate manual tasks, but I hate using custom programming as a primary part of any procedure as it becomes a maintenance issue with the software and can cause issues with customer support when troubleshooting other problems.
Okay, so just to update after some thought the best I've come up with so far is to:
- Create a block, consisting of nothing more than a balloon with text inside, for every possible rev (easy enough to do with a macro).
- Add each rev balloon block to your design library.
- Create a table on your drawing template (I drew this as part of the sheet format). Populate each cell with properties mapped to EPDM variables (e.g. Rev1, Rev2, Rev3, RevDescription1, RevDescription2, etc.).
- Set new and old revision variables through workflow transition. (e.g. SetVariable Rev1=NextRevision, Rev2=Rev1, Rev3=Rev2, etc.)
- In the drawing, designer can add as many rev balloon blocks as needed from the design library (emulates RMB>Insert Symbol on rev table)
- When an old rev is knocked off the table, designer just goes to the blocks folder in the drawing's feature tree, and deletes the old rev block. This will delete all the children that are on the drawing. (emulates deleting a rev off the revision table)
This allows me to have the revision change be controlled by EPDM, eliminating errors in improper revision identification.
This also ensures changes from previous revisions remain correctly identified until deleted. This is the desired behavior.
Lastly, it allows me to delete all previous revision balloons with a single command, reducing risk of having old balloons lingering on prints that no longer show that rev in the table.
I hate to mark my own reply as the answer, so I'll leave this open for a bit, but if nobody else has any better ideas this is what I am going with.
Steve, That is a cool idea with the blocks, I especially like step 6.
Iftach Priel's method is also clever - it would work well for companies (like us), that don't keep any of the old revision symbols on the drawing - and it is nice because you only have to keep one revision block, instead of one per letter.
One other thought is don't change anything. If you like your SolidWorks Revision table scheme without PDM, then keep using it with EPDM. It is not required to connect them automatically.
We basically kept doing the same thing when we switched from no-PDM to EPDM. We use a general table and manually fill in the 5 cells. We keep as many rows as we think are appropriate, or that we have room for. We use notes as our rev symbols. It might not be as cool, but it is simple and effective (as far as the rev table - I have to agree it would be nice to delete the old revision symbols in one step). We have not had a drawing go thru with a discrepancy between title block Revision (EPDM variable) and the revision table.
I have a note off sheet (next to rev table) that shows the most current EC (linked to variable), as a reminder when filling that in. This system does mean some duplicated effort filling in some fields, but it is minimal, a matter of seconds. I decided my time as an admin and engineer was better spent on other things that setting up a fully EPDM linked revision table (and Dispatch to pass variables), but there are always trade-offs and different situations.
The issue with using a revision table (or using a balloon linked the revision property) is that when the revision property is changed via EPDM, then all the balloons will be wrong because they will also update. This is what I was trying to fix.
I don't see how the method Iftach proposed would provide any benefit over using the built-in revision table.
You would get the same behavior (having the balloons tied to the revision property) by just using the built-in revision table.
There is nothing wrong with the revision table, except that you would still have to manually manage it as EPDM cannot add a new row (without using API or Dispatch).
The reason I want the revision controlled by EPDM is that after auditing hundreds of files I found a lot of issues with "typos" in the revision block where the revision block info did not match the title block info, or did not match the ECN. I even found a handful of cases where the title block had the wrong revision identified. By removing the manual data entry step we can avoid these types of issues in the future.
Hi Steve, one thought on the above. After you change all the variables in step 4, your drawing will not "rebuild". so if you look at the file with Edrawings, it will not be correct.
Also, with the above process, you are setting the revision before the file is approved. May companies do this... we do not. We wait for all approvals before changing the revision. Just make sure that fits your process correctly.
Best of luck.
Good point on the eDrawings.
I have my workflow set up so that only the engineering group can see files that are under the WIP state.
They will have to update the drawing and save it before they can check it in and submit for review. So by the time it gets to anyone outside the engineering group, the eDrawing preview will be correct.
I've gone back and forth on the rev thing, but for what we are trying to do I think it makes the most sense to set the rev first. I have added the appropriate steps to decrement the rev when needed (for example if a change request is cancelled after work has been done). I also have created a state "Waiting for admin" and a transition an engineer can used called "request admin" that will alert me (or if we add an admin group later on) to go work with them if they can't do something for some reason.
Just to follow-up (i was going through old questions that weren't marked with an answer to see if I could update them) I ended up handling the "update" issue by using dispatch to check-out and check-in the file after the state transition where the revision is set.
This seems to be working good in testing.