Sheet metal fiasco..

[pshepherdson]

Is it just me, or does Pro E / Creo Sheet metal leave a bit to be desired? I mean, there have been times when I’ve need to turn a flange into a flat, and split a chained flange into opposite but equal flats. I’ve been forced to part a part as a solid, then convert it to get nice, mitered corners because I don’t have nice 90° corners.

Recently, I’ve dropped a few notched in the bosses’ eyes because of a quirk with Creo. All our dwgs are the folded / formed part, with a flat pattern as the last sheet. Somehow, the included flat pattern on this particular part got disconnected from the formed part. So the part updated, but the flat remained unchanged. Something along the lines that I opened the flat pattern, saved it, and since doing so, Creo ignored its family table link, giving preference to the flat pattern file now available in the working directory. One of my coworkers was trying to explain it to me, but I only caught on to bit of what he said, as I’m tryignto hide my shame of a glaring mistake, and that the supplier caught it. (It was out by about .2”). Something along the lines that I opened the flat pattern, saved it, then opened the dwg, and the flat overwrote itself when I saved the dwg.. So, now, I / we are expected to manually verify all our bends to ensure the flat is as we intend. I now trust Creo even less than before.

I’m still new with Creo / Pro e, just under 2 years with it. Still learning, still going thru all the courses available / that pertain to me thru the PTC univ. I’m still discovering things about the program, scratching my head wondering how they thought things out.

I have a similar irk when I’ve copied a sheet metal part to create a new part. When I open the new drawing linked to the part, the dwg won’t open because it’s still calling up the old flat pattern. Why won’t the flat pattern follow the renaming of the part to the new name? SO, you have to open the new part & dwg, open the old part & dwg, delete the old part (flat pattern) from the new dwg, then re-insert the new flat pattern.. Oh, and you first have to open the new part, clear out the family table, redo the flat pattern & instance & resave it all.. And there is a bunch of regens & open & closing of the files with the odd memory cleaning in between.

I find it odd, that I have a flat pattern, supressed, and save the model. I then get a message aftger saving, saying that he flat isn’t updated. If I update the flat and save, I get the same message, but that the formed model isn’t updated.. A conundrum.. I usually update both, regen both, then save the formed part & ignore the message..

Sorry for the rant, but I'm not in a good mood after today’s fiasco. Can anyone offer up some tips and/or tricks to help a newbie along?

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.

[TomD.inPDX]

No, no Paul... Tell us how you -really- feel

Yes, this is one of the most frustrating processes you can possibly be required to comprehend fully.

But I would turn it on your boss and say "... and what exactly is the company's policy for managing sheetmetal parts and drawings using Creo?".

There really does need to be a "checklist" for how to deal with sheetmetal in both revision, and save-as processes. I am not sure PTC comprehends the concept of Form, Fit, and Function where many companies expect bin compatible parts under a specific part number. More and more often we find ourselves changing part numbers that is buried in the file name and everything disconnects. You end up with 5 layers of assemblies open just to incorporate the simplest of change orders. Throw in a few contractors that act like wiz kids that can do anything in 2 minutes only to find out months later everything associated to the wiz-files is now messed up.

So trust me when I say I feel your pain. Not just Creo mind you, but the industry. We simply don't value people that look at all this in a very practical sense. Managers only react when things go wrong, but they are all bark when you suggest putting in some up-front effort.

[dschenken]

What is the relation between the formed part and the flat part? Are they generic and automatic instance?

Seems like, but just to be sure ...

If so, the main thing is to habitually Verify the family table in the Generic after any change and before saving.

The other thing is to turn off instance accelerator files. They make retrieving things faster by skipping properly regenerating, which only works if you fastidiously Verify before saving. Instance accelerators are the only independent files I can think of; family table items don't have separate files otherwise.

http://help.ptc.com/creo_hc/creo30_pma_hc/usascii/index.html#page/pma/fundamentals/fund_ten_sub/About_Instance_Accelerator_Files.html

[pshepherdson]

Hi All, thanks for the support & kind words!

Yes, the model & flat are linked in a family table. Somehow I saved the flat pattern, which now overwrites the instance in the family table. (Kinda silly IMO..) so, deteted the file, and all is good..

Yes, i do have a habit of regening & saving often, as there is NO warning if you close a window... all then is lost..

Stuff 'in memeory / In session' has burnt me once or twice, as well as "oops, forgot to save".. a consept that is taking a while to sink in...

[dschenken]

There's a configuration option to prompt on exit about saving items in memory; this gives you a warning.

If you managed to create a file with the same name as an instance, the file will be preferentially opened, so that would be problem.

I was emphasizing Verify on family tables. In small ones like this for sheetmetal it is easy to get all the instances and regen them individually, but on larger ones it is easy to miss one or more and that causes havoc.

[pshepherdson]

OK, next bit, trying to understand Creo's logic here:

I've just made three new parts, all based off the original part, but each has grown in one dimension by 1/8".

SO, "save as" and a new name, the dwg seems to follow along. (open the new part, Open the new .drw file) Check flat & calculate deveoped lengths based on bend tables. All good.. but.. once the meomry is cleaned, the wheels fall off..

Why dosen't the family table also update? And insists on pointing to the old part? I woudl think that if I rename a part, the included instance would also get renamed..

So, as just explained to me, I've been missing one step... Renaming the instance in the family table!!!

SO:

1) open drw

2) open part

3) open family table, rename instance & common name

4) save part

5) verify flat in drw is correct

6) save drw file

comments?

[TomD.inPDX]

Yep, you cannot just name family table instances 1, 2, 3 because in the schema of Creo, that is a "part" in its own right. It is -way- to easy to duplicate an instance name if you don't have a unique identifier in there somewhere.

[TomD.inPDX]

And just for making my life more difficult than it already is, I also use the rename function to create new files. I normally copy all the affected files to a temp working folder, open them all, and start renaming stuff. Once the new subset is saved and tested, I move the files into the appropriate storage location. This is how I learned. I know there are many new interfaces to do this differently, but for the most part, copying parts in an isolated workspace seems to help. Of course, remembering to disable search paths and clearing memory is still a 1st level operation for this process to work.

[Dale_Rosema]

... or coping the model and the drawing to a zzzzzoldpartname.prt or .dwg and then renaming the part current part to the new name and the going in to the zzzzz part/drawing and deleting the zzzzz and they you have the old parts back....

No windchill here.

[TomU]

Assuming you're NOT working in Windchill, it might be safer to do the save-a-copy first, then open the copy and change the instance names. This will prevent you from inadvertently changing the name of the instances in the model your copying from.

[dschenken]

Why dosen't the family table also update? And insists on pointing to the old part? I woudl think that if I rename a part, the included instance would also get renamed..

It can't. It's like if you rename a spreadsheet in Excel, the contents of the sheet don't change.

Any place using the instance has a reference built in, like Instance_name->Generic_name, so it knows where to look for the Instance. It can't search all the parts on the off chance that one has a matching instance in it, so it depends on the Generic_name to find it. It also can't depend on the Generic not getting the instance deleted, so if it doesn't find a file that matches Instance_name, and it doesn't find Instance_name->Generic_name, it falls back to Generic_name.

I also note that between steps 3 and 4 there wasn't Verify family table.

Verify is somewhat critical for this reason - When you edit the family table and change the name, you are effectively deleting the old part entirely and creating a brand new part. PTC doesn't track based on the entry number in the table, only by name. Manually change the name in the table, and it's a new part. Verify replaces a number of things which were deleted when the old part was deleted. It doesn't fix the drawing, but it is needed on the way to do so.

The better approach is to Rename in session: the part, the instance, and the drawing, and then fix the Common name. This way all the relationships between the generic, the instance, and the drawing are in place and only the Common name parameter needs (not really, it could stay the same, depending on down-stream use) to be changed. Verify is still a good idea, but since nothing is deleted, it isn't as big a problem.

[TomD.inPDX]

I guess the problem comes into play when you accidentally save the FT instance as a part. If you then have a FT instance with the same name as a part in memory, it won't let you open it. This is perhaps why I adopted a strategy to manage the names of my FT instances.

[pshepherdson]

I’ve been thinking about this over the past month or so.. Always present in the back of my mind. But I think I’ve figured out what happened, that started this whole discussion.

While doing another part recently, I dawned on me. I have a Sheet metal part, and I have the flat pattern. In Creo 2, I updated the part. I get the little green circle at the bottom of the screen to say the part is up to date. I then save the part, only to be told that there is a "conflict" (the conflict window appears). My flat pattern isn’t up-to-date. Sure enough, when I resume the flat pattern, it requires an update; little yellow circle at the bottom of the screen.

So, it seems that the part can be up to date, but the suppressed feature (flat) gets reported that it’s not updated. And visa versa. So, that’s where I think I goofed, assuming that if I save both the flat & the model, I won’t get the conflict, un updated features. But that, in turn, saves the flat to a file, not saving the instance in the family table..

Would it be safe to assume that, the family table might not be the best way to link these two states?

Back to PTC Univ.. to see what they said.. (Or how I mis-interpreted it..)

[TomD.inPDX]

It is safe to say that just because the green dot is present that there still may be issues that just haven't been reported to the regen manager. I believe there are several instances when this happens but you cannot force the regen manager to act.

However, the means to manage flat and bent stated with family tables is very sound. You just have to remember to verify your states when you update your model.

[Dale_Rosema]

... and in case you don't know (like I didn't) that to verify the family table, you click on the little check box above a three columns (like shown on the top left below). It pops up a window (like shown below) and you click the verify box and it goes through and verifies each instance.

Thanks, Dale