So if the part has 12 versions and versions 5 and 10 are Revs A and B:
version 5 is an old rev
version 10 is current “released” rev
version 12 is known to the world as rev C even though PDM calls it “working document” because that version hasn’t been stamped with a revision yet. The notion of a drawing not having a revision doesn’t fit here.
More about what that means but unfortunately, this gets messy quick
because of inventory, vendor lead times, customer requirements, etc. there may be a long time between when Des Eng releases a revision to when it is implemented. Typical is a couple days to a couple weeks; min and max that I’ve seen is a few minutes to a couple of years.
It is not uncommon for rev A to be current production, rev B is “released” but not yet phased in, and version 12 is, unfortunately, the next change request.
we do not use old revs, many people assume that when I mention get referenced or old versions. We are not using old revisions, the shop cannot make old revisions and the reason the phase in takes so long some times is slow moving inventory needs to be purged or scrapped before the new rev is phased in.
consider a new usage of that part being released; it’s uniqueness has nothing to do with the part we’re talking about, it’s just using the other part. This assembly being sent to review should be using the rev that is in current production, so it should be referencing version 5 (rev A), not 10 and not 12. There are several reasons for this that I’ll just not go into right now.
Exact same issue here. We have “Engineering Release” and “Manufacturing Release” but we can’t work that into the CAD file workflow. since the files need to undergo more ECOs while the factory “catches up”. Engineering can be on release revision “E” while the factory is still processing release “C”. The CAD file workflow can’t have both in PDM, so we handle it with the PDFs. We create a separate PDF of each revision and they have a workflow that flows from “Engineering Release” to “Manufacturing Release” to “Archive” as ECOs are processed.
Windchill handles this better, each “Rev” of a file/part is separate and have their own workflow state. The ECO sets the files state as certain tasks are completed.
Mfg mostly works from the PDFs, rare they want to open a model except to program CNC stuff or export DXF files.
Ah yes, same page. The PDF is how we go about this as well, they are saved with the rev number from PDM in the filename.
Where we are running into problems is not when opening or saving pdf of the drawing; what’s getting us is working with all the where used of these files. Remember, all our part numbers can be considered as a “standard part” so they are used in parents that have been released for months, parents that are under ECO and parents that are in prototype phase; usually all at the same time.
Yeah, we don’t have a good solution for this either. I think Windchill handles this somewhat with it’s “Baseline” feature which we aren’t using yet. It’s a snapshot of BOM “references” and their states/revisions that is created when an ECO reaches a certain state (where ever you set it). So you could create a baseline of a BOM with all current “Engineering Release” revisions. Then call that back up in the future. These are usually created when an ECO releases the parts/drawings, etc.
What about putting it into a different ‘state’? Does that not apply here?
When rev B is done by engineering it goes into a state that is basically released until another party does the final release. Is this not really possible?
i.e. we do have i.e. a ready to release state for our CNC parts. It’s reviewed, approved, BOM knows about it… We have regular times throughout the year when this will get released (if it’s not urgent) - i.e. once a month - and the only thing we do is to ‘release’ it.
I know that this does not fix your problem of loading it correctly…
We face the same problem here - but at least you can see & sort it better.
We had tried involving the other departments into the workflow to help with this. Several problems came up, here’s a couple, the first one could have been figured out but numbers two and three were show stoppers.
There’s already other data systems that other departments live in, it’s hard to claim a net gain when their action is just adding more workload for every part number they touch. If I would have known what I was doing when we set up PDM here we may have been able to do this with some API to transition files using calls from the other data systems triggered by actions those users already do many times a day. Maybe in a perfect world…
We thought we could keep it simple with just a single state between Des Eng release and Mfg Eng release. Well then after trying a bunch of things we wound up with a Purchasing Doc Control state and Mfg Eng Doc Control state. Then we needed something to deal with prototype/quote release for purchased part and when a purchased part is released. It just kept snow balling. Files left in states because there was no transition that would work for the process. We wound up making new workflow with just a few states then a bunch of WF jumps with auto transitions to them. That’s why “Released” in PDM just means to get changed it needs a rev.
Files would be hung up in the other states waiting for the previous change to be implemented while new ECOs were needing to work on them.
What we learned is PDM is >FILE< management. Sometimes it can be made to be a >PART< management system but not with what we’re throwing at it. PDM is for Files (metadata included). Yes, we represent objects such as physical parts or concepts such as ECNs or whatever with files and use PDM to manage those files. But the data and behavior of those objects are not fully encapsulated in a file and metadata. So, inevitably there’s going to be some function boundary between PDM and whatever manages the rest of the object attributes and behavior. The best place to draw that boundary line will vary from place to place as there are so many things involved. But, I could be wrong about all that I’ve only been working with it for a couple years now; my perception is still evolving.
