Pre-released / Prototyping Engineering Drawings

Nath_McC

Hi All,

How do you all deal with drawings that have not been released (an unformal release) but need prototyping work completed?

Especially if emails are going backwards and forwards to companies who are completing the prototyping, the last thing you need is to email with PROTOTYPE-001 pdf, then update with the new information and resend PROTOTYPE-001, but they still use the old one. Generally, our rule is that the file name is the drawing number + revision, e.g. DWG-0001-A, DWG-0001-B, etc.

I also do not want to release a drawing at revision A and then end up at revision Z before you finish getting the prototype correct (a slight exaggeration )

I initially thought of putting an export date/time stamp on the drawing or some time stamp in the file name.

romeograham

I generally release everything as early as possible - even parts / drawings for prototype or evaluation. This way, you use the power of Release Management for keeping track (as it's intended), and it reduces ambiguity (even internally)...and provides a great historical record of your process for later forensic investigation.

In cases where I want to share an unreleased (and therefore uncontrolled) drawing - I'll name the file Dxxxx-REV-[1 draft]....PDF. The "draft" in the Revision part of the filename hopefully shows that this is not a controlled drawing. Of course, the large watermark "In progress" on the drawing helps too - but seems to be easily ignored. Also - there's no elegant way to up-rev the "draft" revisions - since when you really release, you need to go back to 1.

I've seen other systems where all prototype revisions are 00, 01, 02 etc...then when "production" starts the Revisions change to A, B, C etc. You can use Custom Revision Schemes for that.

Here's the Help entry for how to do this: https://jps.onshape.com/help/Content/Plans/release_management_2.htm#rev_parts_and_num

However - I think you should use the Part Numbers and Release Management as early as possible - before you share anything. The Part Numbers are generally free (if they're just numerical increments from the last part number) and so are Revisions - There may not be a real reason to hold back on Revisions - other than Company history or custom "we always go to Production with Rev-1"...

Since Revision control is easy in Onshape - there's not much extra work in starting it early in the project.

You can always hide rows in the Revision Table if needed.

philip_7

I like to use releases and release management where possible because, as romeograham said, it reduces ambiguity.

I try to make release management fast, but it does slow things down a bit... so for quickly quoting iterations of a prototype design during its development (especially if I'm uploading to an automatic quoting engine like Xometry or Protolabs etc.) I will sometimes reference the version number from Onshape's history tree in lieu of a formal release (e.g. PN 12345 v1, then v2, v3, etc. as I upload refinements). If I'm requesting a manual quote from a supplier I will almost always release and send a proper revision to avoid ambiguity.

S1mon

From our internal documentation on our product lifecycles and revision scheme, see below. There are some things here that we haven't fully implemented in Onshape (e.g. the RevC-01 idea for update tests), but we do have 3 separate revision schemes in Onshape. We also don't have a way to transition automatically from one scheme to the others - there's just a drop-down in the release management.

---------

Revision

Use of Revisions

A new revision shall be used whenever a document leaves a development system and is shared with people outside the development team. Even if it’s only for internal stakeholders, but it will be used to track a build, test, or other important points in the development, it shall have a revision.

Some development systems may also support the concept of versions. These are to be used for internal tracking of key points in the development in order to revert changes or otherwise track or compare progress. Versions are typically positive integers which count from 1 to infinity. In many systems, a particular revision also corresponds to a version. Version numbers should never be marked on parts or documents as a way to track something important which is shared outside a small development team.

While the point of a revision is generally to make an improvement, they shall be forward and backward compatible. If there is a bin of parts with more than one revision of the same part number to pull from on an assembly line, there should be no penalty for pulling a random revision.

However, a change order may specify a material disposition which will require old parts to be scraped, used up first, or reworked to an updated specification.

A change in form, fit or function requires a new part number.

Changes to a subassembly’s constituent parts may require a new part number for the assembly if the form, fit or function changes. If not, it can just be a revision change.

Stages: Development RevX01, X02... X99

During initial development of a design or a new part which may become part of an existing product there will be many rapid changes to documents. These documents can be used to create breadboards, test models, 3D prints, proposals shared with vendors, internal stakeholders, etc. These development parts are never for use in salable product.

In order to support rapid development, any engineer or document creator may create or revise a document. Form, fit or function rules for changing a part number may be relaxed during this stage if there is little chance of confusion, and the engineer deems it to save time.

You can think of the initial “X” as experimental, but it's also there to make it clear that these parts/documents are being produced in relatively low volumes for initial feedback and testing.

Stages: Pre-production Rev01, 02... 99

During pre-production (EVT, DVT), the costs and risks of development are higher, and the rigor in documentation and revision control is also higher. Pre-production is generally produced using the same production methods (e.g. injection molding, die-casting, etc.) as production.

Pre-production changes require approval/review from at least another team member if not a manager. Entering pre-production - changing from an X rev (development) to pre-production (01, 02...) - requires the same review as changing from Rev04 to Rev05.

Pre-production parts will be used for things like reliability and regulatory testing, and cannot be sold to end customers.

Stages: Production RevA, B... Y, AA, AB, ...

When a part/document is ready to go into mass production for sale to end users, it moves to production phase (PVT and MP). These revisions are in an alphabetic sequence specified by ASME Y14.35. They skip letters I, O, Q, S, X and Z. These letters are not allowed because they can be mistaken for numbers or for other letters. For example, a revision letter I can be mistaken for a 1 while an S can be mistaken for a 5. Revision letters must also be uppercase, to minimize confusion between a lowercase "l" and "1" and "I".

A change order shall be necessary to enter production or move from one revision to the next during production.

Stages: Production-Change RevC-01, RevC-02 —> RevD ...

During production it may be necessary or desirable to make test parts in order to qualify a change which are not to be sold. For example, a part is at RevC, and we want to test out a potential change. We can release this as RevC-01. This revision is not to be used in a salable unit. It is for tracking the change and test purposes only. If this test build fails, and another change is required, we move to RevC-02. When we’re ready to commit a change to production, it moves to the next letter in the sequence - in this case RevD.

Labeling Revisions

Documents, such as 2D drawings, or BOMs, which have clear fields marked with a header of “Revision” may just show the revision letter or numbers per the stage of production (e.g. “X04”, “03”, or “E”). When a file is shared it shall be named with the document name, part number, revision and extension (e.g. “ModelZ-Deck-Top-UP000123-Rev03.pdf”). To avoid bad formatting, spreadsheet users may want pre-production revisions to be formatted with Rev (e.g. Rev02).

Any custom part which has room shall have the part number and revision molded, stamped, laser-marked etc. as is appropriate for the production process and vendor. On a molded or cast part, the revision shall be on a replaceable core pin or insert in the tool. Just the revision character(s) are acceptable on the part marking. If possible, the part number will be on its own insert.

Where it’s impractical to label the parts, the packaging shall have part name, number, revision, and lot code on the bag or box.

adrian_vlzkz

I've put in a Improvement Request for support of two-tier revision schemes since the day Release Management was available. It's been a long time and still is a huge short-coming since we have a Major and Minor Rev system in our PDM environment.

We have a similar concept as the one @S1mon describes, which is quite common in industry, hopefully 2024 is the year of Release/Data Management for Onshape Development