Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X
Does anyone know if there's a way to parameterize the flag notes in such a way that those in the notes block and the rest of the drawing are synced? For instance, I have a flag note 5 that is now becoming flag note 4, since I deleted a note above it and I need to keep the notes sequential. However, it is extremely tedious/annoying to go through all pages of the drawing and change those flag notes 5's to 4's individually. I find this to be problematic for larger drawings (10+ sheets). Can I control it at the notes level and have the corresponding flag notes auto-update?
Solved! Go to Solution.
The numbers could be updated in the drawing parameters interface. Or, potentially, just by double clicking any of the note instances. Create a parmeter "FlagLabelA" which is an integer with value=1. Then in the flag notes place &flaglabelA", the flag will then display "1"
The way we handle that is we would leave the note numbering alone and just change the text on say note 3 to just say DELETED.
All flag notes will stay the same and it provides a little bit of traceability between the revisions.
I agree 100% with Ben. In fact, I'll go further: BOM's should have the entire region "Fixed" before it's released at rev "A". If an item is deleted from the BOM, you should have a "REMOVED" part (where the description just says "REMOVED" (without the quotes) and there is no other info) added to the assembly, and have that index "Fixed" to be the item number that was deleted. Any NEW parts to the BOM should immediately have their Index fixed. In notes, do not go renumbering notes. As Ben mentioned, simply put "REMOVED" (without quotes) where the text of the note went.
The reason for this is that many times notes and BOM items cross-reference each other (i.e. press fit Item 1 into Item 2 of a note number in a BOM column referencing a note), and it's WAY too easy to forget to make sure the renumbering happened correctly, especially on dwgs with many sheets. Also, there is a good chance that outside documents (assembly instructions or build sheets) reference BOM item numbers and note numbers, and then they could get screwed up as well. This way, at initial release, the note and BOM item numbers are locked, and you almost can't make a mistake even in outside reference documents. In every entity or company I worked for (Navy, NASA, DOD, DOE, private industries, etc.), if there wasn't already an edict to do this (there was for all Gov't agencies I worked for), I MADE it an edict that this was how we handled things.
For sure on the BOM being fixed, too. I have a 100 empty part family table with Deleted # for the name so we can dlete items and fill in the BOM. Have to have the Deleted #, or the BOM will list qty of 5 for DELETED, so each one has to be unique.
'Sup Ben!
In all my start parts, particularly my "Removed" part, I have a string parameter: BOM_QTY_TYPE, and it has a null value (no characters, not even a space). In my BOM table, I have a relation that controls that:
if ASM_MBR_BOM_QTY_TYPE == "" | ASM_MBR_BOM_QTY_TYPE == ""
Qty=ASM_MBR_BOM_QTY_TYPE
ELSE
Qty=rpt_qty
ENDIF
This prevents the quantity from getting filled out no matter how many parts there are. I made a pattern and the qty was blank. I see what you mean about having multiple parts/indexes removed though, and yes, you'd need a number of parts for that (family table being a great way). But at least this will fix the quantity issue.
Ok, I ran into some issues. The quantity in the BOM for my "Removed" part was null...but that only worked for 1 index, no matter how many, say, of a pattern there were. Great...BUT...if I tried to have multiple different replacements/indexes, they all ended up as the same index (NOT great), even if I did a family table. So, I added the (family table) part parameter "BOM_QTY_TYPE" (I misnamed it as "ASM_MBR_BOM_QTY_TYPE" above, that's how it shows up in the BOM...Doh!) as a column to my family table, and put a different value for each of the 20 instances (i.e. RMVD-001, etc.). Then I had to write the following relations in the BOM, and, mother of all surprises, it worked. I s@ck at programming so, I'm not really sure WHY that syntax works, but it does and I'm not gonna worry about it.
if ASM_MBR_BOM_QTY_TYPE == "RMVD-001" | ASM_MBR_BOM_QTY_TYPE == "RMVD-002"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-003" | ASM_MBR_BOM_QTY_TYPE == "RMVD-004"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-005" | ASM_MBR_BOM_QTY_TYPE == "RMVD-006"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-007" | ASM_MBR_BOM_QTY_TYPE == "RMVD-008"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-009" | ASM_MBR_BOM_QTY_TYPE == "RMVD-010"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-011" | ASM_MBR_BOM_QTY_TYPE == "RMVD-012"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-013" | ASM_MBR_BOM_QTY_TYPE == "RMVD-014"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-015" | ASM_MBR_BOM_QTY_TYPE == "RMVD-016"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-017" | ASM_MBR_BOM_QTY_TYPE == "RMVD-018"\
| ASM_MBR_BOM_QTY_TYPE == "RMVD-019" | ASM_MBR_BOM_QTY_TYPE == "RMVD-020"
Qty=""
ENDIF
Not necessarily advocating this but one of my users created drawing parameters which were then called out in a symbol and the symbol was embedded into the drawing notes.
There was one place that was layered off that had the numbers and when changed they changed everywhere.
Personally I don't like embedded symbols in notes but it was a technique that worked for what they were trying to do.
The numbers could be updated in the drawing parameters interface. Or, potentially, just by double clicking any of the note instances. Create a parmeter "FlagLabelA" which is an integer with value=1. Then in the flag notes place &flaglabelA", the flag will then display "1"
Thank you!! This is just what I needed. While I understand writing "REMOVED or DELETED" next to an expired note is common and helps with tracking between revisions, I don't feel it is necessary when creating a drawing from scratch. This is a cool way to control the value of your flags in one place without having to go through all your sheets and update them.