MAJOR repeat region table issues, "Fixed" indexes changing themselves.

[Patriot_1776]

Ok, since we have our BOM's in another database, I need to go into the dwg BOM and make it reflect the numbering scheme in that system. So, I try and "Fix index" on an index-by-index basis....and it decides to change what I've done when I do an "Update" on either the sheets or in the ribbon tab. I finally found I had to fix every index, then fix the entire region to make it work. Then I needed to add a view of a simplified rep, with a BOM table specifically for that view, but with the 4 parts numbered the same as the master rep. I CANNOT make it work. It keeps changing a couple components indexes. EXTREMELY frustrating. I'm trying to show to management that this is the way to go and establish this as policy instead of using dumb tables, and wasting time with this is an absolute nightmare. The absolute worst thing at the worst time. Now, a couple of parts are flexible, but I got them to work on the master reps so it should work elsewhere. I can't isolate that they're the issue, but thought I'd mention it.

Getting REALLY tired of all the bugs and issues.

Anyone else seeing this? Any solutions?

Grazie!

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dschenken]

The real solution is off-drawing parts lists and hand created balloons. Never. Ever. Fails. I have a preference for Excel sheets that are designed to validate against the model tree. I can generate the entire PL, including items that aren't modeled yet, including the assembly, setting up for the ERP system, and a large number of follow-on drawing creation and validation steps.

The way regions work has always appeared to me to be the work of one really talented summer intern they hired for release 10 and have never updated since. As a result it is a brilliant piece* of inadequately designed software that requires far too much hand-holding to work right. The amount of user up-front work and maintenance work is greater than the effort to handle it manually. PTC will never fix it because too much user product depends on the original flawed work, so the only option is to add more code to the distribution and that means two implementations to keep track of. All that could happen is an overlay that can generate the user code and maybe a debugger, but it's not likely.

*Not sarcasm - it does get a lot of mileage out of a flawed foundation. Exactly what I would expect from an under-grad student who didn't understand how PLs & BOMs are supposed to work. So they built a complicated programming language with no debugging facility to allow users to program it to do what it should do OOTB.

[Patriot_1776]

That was so good, I had to mark it as helpful! Yeah, this is REALLY pi$$ing me off.......

[CeliaLee]

It was probably automatic for you, Frank, but you should have filed this under Creo, not Windchill if you want the Creo team to see it.

-Celia

[Patriot_1776]

Automatic? LOL When I posted, it was really weird, I could have sworn it posted in the creo discussions.....maybe the site is buggy too....

[ryankelley]

No worries, moved this discussion from into .

[jliddane]

Hi Frank, I am seeing similar issues, is there any way to fix this or have you simply reverted to manually attaching balloons?

Thanks.

[Patriot_1776]

I had to go thru all 6 large tables, fix all the indexes of each row induvidually, then fix the entire region.  That seemed to work, but I have to do that now EVERY time the table gets changed for almost any reason.  My fear is that one of our (many) minimally experienced users will have to make a change, and the tables will FUBAR themselves....

PTC REALLY needs to fix this.

[StephenW]

I don't remember ever having a problem with fix index by record for each item. You do have to fix each index because if you add or remove a component, depending on your table sort, it may bump an index that wasn't fixed. I haven't used fix the entire region in a long time and don't remember why I used it when I did.

Are you having problems when you explicitly set an index and it changes?

[Patriot_1776]

Yes.  They STILL haven't worked the bugs out of flexible parts.  Very scary to have a large assy simply decide to go changing some of the index's around unexpectedly....out of the blue....

[StephenW]

Hmm, I knew flexible components were a mess with the BOM tables and balloons, I had never noticed a fix index issue with them though. I better look carefully at the next one I do.

[jliddane]

Just want to check up on any advances in this. I am using M140 CREO 2.0 and myself and my colleagues are still seeing the issues. We have reverted to manually ballooning items for the moment. Is this fixed with any later CREO updates? as wwe aer wondering whether to pay for maintenance to fix this problem.

It would be nice to hear from PTC on this one.

[mender]

There have indeed been some fixes recently to the stable identification of repeat region records (which is the core issue for anything about fix index / dash item / etc. being matched to the right record when tables are updated), in particular for a case involving flexible components fixed in M170.

One thing that is worth checking on whatever release you may have is updating the drawing to any versioned fixes with File > Properties > Detail Options, enter the detail setup command 'update_drawing all' (put update_drawing in the name, all in the value) and regenerate (and inspect the drawing to see that all changes are desirable).  If the problem cannot be newly introduced after that, then it is likely that it was fixed with versioning protection, and will not occur in new/updated drawings.  (Versioning proection is required for fixes in this area, as they could otherwise change the drawing's appearance on retrieval.)

[Patriot_1776]

Well, glad to see that since flexible parts were available in what, WF3(?), that they've fixed the issue in a "timely" fashion recently in creo 2..... 

Too bad I'm still on creo elements/pro 5.0 (or whatever it's really called....)

[mender]

Caveat, naturally I can't say if this particular fix is the issue that the poster is referring to.  While the stable documentation of flexible components has improved over the years with a large number of fixes over several releases, can't say that they are no more bugs to be found.

[Patriot_1776]

.....now THAT'S encouraging.....