How do you version your PCBs and schematics?

Am 26.11.2012 14:54, schrieb Matias Sjögren:

2. You have a PCB version A and schematic version A, and then you have to change a component value(wich doesnt need anything in the PBC to be changed) in the schematic wich will become version B.

This situation can NOT occur, because a changed schematics value DOES

change the board, e.g., in the documentation, where this resistor will

appear with the changed value.

How do you handle versions on your PCB and schematic in these scenarios?

Under EAGLE, schematics and board ALWAYS belong TOGETHER. Therefore,

completely independent of where changes are necessary in theory, NEVER

just change something in only ONE window, but ALWAYS in BOTH.

The absolute simplest method is: If you have a design version A

consisting of 'a.sch' and 'a.brd', and you want to make another version,

save the design under a new name 'b.sch' and 'b.brd' and change these

new files.

With EAGLE 6, other methods called 'version control systems' are

possible, but these are often a bit tricky to set up. It's much easier

to just save your design with another name...

I myself put every design in its own folder, and if I have different

versions of the same design, I put them in different subfolders called

'v1', 'v2' etc. as in the attached picture.

Andreas Weidner

On 11/26/2012 02:54 PM, Matias Sjögren wrote:

Hi.

 

I just want to know how you decide versions on your PCBs and schematics.

 

For example:

1. You have a PCB version A and schematic version A and you just need to do a tiny fix(wich doesnt need anything in the schamatic to be changed) on the PCB wich will become version B.

 

2. You have a PCB version A and schematic version A, and then you have to change a component value(wich doesnt need anything in the PBC to be changed) in the schematic wich will become version B.

 

How do you handle versions on your PCB and schematic in these scenarios?

 

/Matias

 

Hi

I use git version control system and every changes is committed as in

your option 1. (stored as an restoring point), and every milestone (your

option 2.) is also tagged, which is basically a way of pinpointing

important happenings in your design.

You may then switch between different versions of your design with

simple commands whenever needed.

If you have never used version control software (VCS's) before, this can

be a bit hard to understand out of the blue (If you are familiar with

it, stop reading), but the simplest and "popular scientifically" way of

describing it is to call VCS a dynamic database that keeps track of your

file changes.

There is many VCS solutions and git is just one of them and which was

created by Linus Torvald, you know, the Linux guy. Then you have SVN and

CSV and many others. I find git very usable and handy for my eagle

designs. I also use it for keeping track of my library and the sw

projects +++.

This is helpful reading

http://git-scm.com/book/en/

Breg

Vidar (Z)

On 11/26/2012 08:54 AM, Matias Sjögren wrote:

Hi.

 

I just want to know how you decide versions on your PCBs and

schematics.

 

For example: 1. You have a PCB version A and schematic version A and

you just need to do a tiny fix(wich doesnt need anything in the

schamatic to be changed) on the PCB wich will become version B.

Generally, anything that required a board layout change gets a bump in

the revision.  So if you changed a resistor from an 0603 to an 0805, for

example, it goes to Rev B.

2. You have a PCB version A and schematic version A, and then you

have to change a component value(wich doesnt need anything in the PBC

to be changed) in the schematic wich will become version B.

Again, generally, a component value change (whether it's value,

tolerance, rating, etc), we append a digit to the revision.  So if all

you're doing is changing the value of a resistor, it goes from Rev A to

Rev A1.  The BOM is updated to the new component and always states the

revision (A, A1, B, etc) to which it applies.

I will even go so far as to list the changes between Rev A and Rev A1 in

a was/is format.  Something like

    "R43 WAS 4.7k 5% our P/N 1234, IS 4.7k 1% our P/N 1235"

It keeps it clear to my vendor what the differences are and makes it

easier and more accurate for them to know which part to load in place of

the old part.

The major revision tells us and our assembly house that a new stencil is

being used, and the part coordinates may be different.

A change in the minor revision (scenario 2 above), doesn't change the

stencil, or part coordinates, so the assembly house can use the same

pick-and-place program that was used in the prior revision.

Now that Eagle stores its data in XML format (since v6.0), it's much

easier to determine all the changes that were applied since the previous

release.

How do you handle versions on your PCB and schematic in these

scenarios?

These are policies that work well for us.  Perhaps it will help you

develop your own policy.  No matter what policy you develop for your own

use, stick to it with minimal exceptions.

Rules should not be broken without 500 layers of management approval.

Policies, however, are intended to be more flexible.

HTH,

    - Chuck

Chuck Huber schrieb:

Generally, anything that required a board layout change gets a bump in

the revision.  So if you changed a resistor from an 0603 to an 0805, for

example, it goes to Rev B.

...

Again, generally, a component value change (whether it's value,

tolerance, rating, etc), we append a digit to the revision.  So if all

you're doing is changing the value of a resistor, it goes from Rev A to

Rev A1.  The BOM is updated to the new component and always states the

revision (A, A1, B, etc) to which it applies.

...

The major revision tells us and our assembly house that a new stencil is

being used, and the part coordinates may be different.

 

A change in the minor revision (scenario 2 above), doesn't change the

stencil, or part coordinates, so the assembly house can use the same

pick-and-place program that was used in the prior revision.

We do it exactly the same way, except for using numbers for the board

revisions and letters if there are value changes (e.g. -R1, -R1a).

Tilmann