Boo! (for anyone celebrating Halloween )
Now this IS scary... I'm making an exploded view assembly drawing with a BOM and balloons, and I'm at the point of adding balloons. I've tried a couple of the options, and currently, By Component is my favorite method. However, coming from SolidWorks World (pun intended!) I'm used to adding balloons with two clicks... 1. Clicking the point of attachment. 2. Click the balloon location. Quite simple, for us simple SW folks.
In Creo, the balloons seem to land just about anywhere they want. I've tried single component, MMB, RMB, options and can't get the results I want. I've looked in the textbook for my current class, no luck. If there is a way to add a balloon without the EXTRA steps of editing the attachment point & balloon location once the balloon appears, please tell me.
Thanks in advance for any help!! Now, put your costumes on & go get some candy
I'm using a "Balloon Note" so yes, this is my preferred way to make balloons.
My BOMs are also constructed rather than repeat regions.
It really is much simpler in the long run when every client needs something slightly different.
However, if items in an assembly are assigned item numbers through the repeat region BOM process, a simple symbol balloon should be able to pick up that attribute when you attach it to the part or subassembly member. This also solves the issue when you have to use the same item number in several places so the quantities can be "split".
I prefer to use drawing symbols (not notes) that handle integrated complex item and flagnote callouts along with off drawing PLs managed in Excel that are semi-automatically bounced against the model tree to allow validating all the parts are identified and that all quantities are accounted for. It makes it very easy to perform customer audits.
My preferred approach also doesn't answer the original problem, except to say, avoid BOM balloons.
To use the repeat region tables and BOM balloons is more trouble than it should be. Often it devolved into a Whack-a-mole style effort with balloons showing where they are least useful or refusing to show in desired views. In WF5 I frequently filed before showing BOM balloons as there was a 5% chance of software crash. It was the only operation that frequently crashed.
I would enjoy seeing the software development spec that backs up the current implementation. I suspect it has the words "scattershot" and "frustrating."
Not know any details about what Dan is trying to accomplish other than making showing repeat region balloons easier to show and position, all I know is you can't explicitly do what he is asking. Now, if he is open to other ideas about getting balloons on a drawing, there are a myriad of ways that can be accomplished, each with their own advantages and disadvantages.
I would also agree with the "specification" for BOM Balloons includes "scattershot" and "frustrating." I know how to manipulate repeat regions and I know how to manipulate bom balloons and I feel like I can do just about anything I need to do to get my drawing to look the way I need it to look but I also feel like I can waste SO much time on it that it's just not worthwile. At my current job, there is no requirement to use repeat region BOMs and balloons. I use them when it's easiest to use them. I don't when it's going to be "scattershot" and "frustrating."
Thank you Stephen, Antonius, & David! I will investigate other methods of balloon management, as described, to see what works best. Perhaps I can make a custom note that calls an item's BOM number? Then I will make less mistakes between the BOM & balloons. We do use repeat region BOMs (not likely to change).
At least you confirmed my suspicions, I CAN'T do what I'm trying to do. This seems to be my mantra, coming from SW . I'm really trying to warm up to Creo, seriously, because I could be here for the next 15 yrs. Then I discover today that PTC has only created a .bat file to deal with (remove) all the old file versions in a folder. What if I have a 1,000 part assy!?!?
Ah well, it's a good thing for me the Creo Community is as friendly & helpful as the SW Community. I guess we CAD guys like to help each other out, regardless of our CAD denomination. Thanks again!
Being a SW guy, you could really dig into Creo on a different bend from just geometry programming.
Remember that Pro|E's background is Unix and everything in Creo seems to be a simple little routine. You might be surprised at how much your background will help make Creo a lot more that what it presents.
As for the batch file, it is actually Purge.exe that does the cleaning of folders. Not sure what the bat file is doing but sometimes getting it to work requires some environment settings or moving some DLL files that purge.exe depends on.
You might also be able to dig into what Creo does with the repeat region. Somehow it tags all the parts with a item number so you should be able to create a symbol that extracts that information. If this interests you, you could employ the help of the customer support team by filing it as a case.
And as with all things SW... syntax, syntax, syntax... or sin tax as if you like
Repeat regions create a list that depends on the repeat region parameter. It's easy to make a BOM repeat region that makes every component look like the same item on that list. Somewhere in there it also creates a look-up table to tell which item number each component is matched to on that list.
There can be several repeat regions on a drawing, each with a different item classification method, so any particular component can be related to multiple item numbers.
A user symbol has no way to get that information because PTC does not include the ability to reference which table to extract the related item number from, unless that is a new capacity unmentioned by Creo 3 users; the same disconnect is found in user notes/annotation where references to item numbers also can't be automatically maintained.
PTC could add a general purpose internal language such that symbols and other components could carry their own software. While Weblink and J-Link and VB can manipulate the data, those tools do not stay with the components they affect. If they did, then user created BOM symbols could be much more flexible. Off hand I can imagine that a symbol could not only determine which was the correct item number, but also keep an account of exactly which components it was pointed to to get a correct quantity, eliminating the need for merge/split/etc, maintain an index of which sheet and zone it was on, and even draw the symbol, much like the Postscript language does.