How do you version control your PCBs these days?
I'm at the point I need to implement a more consistent schema for
hardware versions, prototype, and production boards.
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is
the manufacturing revision. Would you letter designate prototypes that
are manufactured as well, or just revisions intended for public
consumption?
On Mon, 24 Mar 2025 14:14:38 -0400, bitrex <[email protected]> wrote:
How do you version control your PCBs these days?
I'm at the point I need to implement a more consistent schema for
hardware versions, prototype, and production boards.
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is
the manufacturing revision. Would you letter designate prototypes that
are manufactured as well, or just revisions intended for public
consumption?
For a V375 VME module, our schematic drawing number is 22S375A, where
22 means the VME product line and S means schematic and A is the rev
letter.
22D375A is the PCB fab (drill) drawing and pcb design file name.
22A375A is the pcb assembly drawing.
22M37501B might be a mechanical part drawing, like a front panel.
22A375.1A is the BOM file for the sellable -1 version.
During development, we iterate the schematic and PCB together, as
22S375A4 and 22D375A4, for example.
We have a formal procedure about all this. FPGAs, uP code, test sets
and procedures and software have to be coordinated too.
Times hundreds of products with rev letters and dash number versions,
this gets serious.
Prototypes are 99 series, with informal project files on a server.
These are essentially little breadboards. We don't prototype entire
products; we just release the full rev A document set to manufacturing
and expect it to work.
On 3/24/2025 2:46 PM, john larkin wrote:
On Mon, 24 Mar 2025 14:14:38 -0400, bitrex <[email protected]> wrote:
How do you version control your PCBs these days?
I'm at the point I need to implement a more consistent schema for
hardware versions, prototype, and production boards.
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is
the manufacturing revision. Would you letter designate prototypes that
are manufactured as well, or just revisions intended for public
consumption?
For a V375 VME module, our schematic drawing number is 22S375A, where
22 means the VME product line and S means schematic and A is the rev
letter.
22D375A is the PCB fab (drill) drawing and pcb design file name.
22A375A is the pcb assembly drawing.
22M37501B might be a mechanical part drawing, like a front panel.
22A375.1A is the BOM file for the sellable -1 version.
During development, we iterate the schematic and PCB together, as
22S375A4 and 22D375A4, for example.
We have a formal procedure about all this. FPGAs, uP code, test sets
and procedures and software have to be coordinated too.
Times hundreds of products with rev letters and dash number versions,
this gets serious.
Prototypes are 99 series, with informal project files on a server.
These are essentially little breadboards. We don't prototype entire
products; we just release the full rev A document set to manufacturing
and expect it to work.
I see, that makes sense. Some designs I'm working on now are modest
enough that can do that with the entire product relatively cheaply, so I >guess, y'know, existentially speaking, if "A" ended up needing major >revisions, but _if_ it had worked first time it could've been sell-able,
that should count that as a letter-revision.
That is to say I guess it makes sense to be consistent and give any full >board that gets manufactured in whatever quantity a letter revision, and
I like the idea of giving "little breadboards" that aren't a full thing
their own project/test series designation
How do you version control your PCBs these days?
I'm at the point I need to implement a more consistent schema for hardware versions, prototype, and production boards.
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is the manufacturing revision. Would you letter designate prototypes that are manufactured as well, or just revisions intended for public consumption?
On 3/24/2025 11:14 AM, bitrex wrote:
How do you version control your PCBs these days?
Just like any other version control. Part number with revision identifier. >For *everything* (including the tools used to do this!)
I'm at the point I need to implement a more consistent schema for hardware >> versions, prototype, and production boards.
Why would there be any difference between them? They are all just
"things placed under version control". Each deserves its own unique >identifier.
DON'T fall for the trap of wanting to assign significance to your >identifiers. That's "small shop" mentality. Avoid the "urge" to
pick identifiers just to make it "easy" on yourself to "recall"
related objects:
product PRD123 is built from
bare PCB PCB123 shot from
with gerbers GER123 defined from
schematic SCH123 populated with parts from
bill-of-material BOM123 and
firmware FRM123 tested to
acceptance procedure ACC123...
This just leads to stupidly long identifiers that will, eventually, prove >incapable of "encoding" the information that you want to be able to "recall" >unaided.
I've got a small board, here, in front of me. It's a management interface >for a UPS. Likely produced in tens of thousands, if not more.
There are two different barcode labels affixed. At least 6 different >"process stamps". Two different identifiers *in* the silkscreen.
Yet, obviously only partially populated -- so, we know the silkscreened >identifiers won't tell me what *this* unit actually is!
The manufacturer will have adopted some convention as to which of
the identifiers actually is associated with the topmost level for
this board -- which is likely different than the identifier
assigned to the *kit* in which it was packaged (which included
still other materials).
Perhaps it is not possible to truly and unambiguously identify
THIS item as there may be identifiers "hidden" from view (i.e.,
only "visible" with tools that can directly query the device)
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is the
manufacturing revision. Would you letter designate prototypes that are
manufactured as well, or just revisions intended for public consumption?
Why "PCB-"? Will that help you find the schematic for the device >(SCH-12345-Q-D because the schematic need not have a 1:1 correspondence
with the actual *board*!) What about the BoM: BOM-12345-L-F (because
the board might find use in different products each with different
stuffing options)?
Will you end up choosing a marketing name that allows you to similarly >associate with these "manufacturing identifiers": Frajistat 12345?
Will you keep it in the stockroom immediately adjacent to the 12346
device (to make it easier for you to find)? Or, will you let SOMETHING >BETTER EQUIPPED (than your grey matter) keep track of this association
FOR you?
(Identifier, revision). End of story. Whether it is a screw, resistor, >case, procedure, compiled binary, source code, etc.
On Mon, 24 Mar 2025 14:51:11 -0400, bitrex <[email protected]> wrote:
On 3/24/2025 2:46 PM, john larkin wrote:
On Mon, 24 Mar 2025 14:14:38 -0400, bitrex <[email protected]> wrote:
How do you version control your PCBs these days?
I'm at the point I need to implement a more consistent schema for
hardware versions, prototype, and production boards.
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is
the manufacturing revision. Would you letter designate prototypes that >>>> are manufactured as well, or just revisions intended for public
consumption?
For a V375 VME module, our schematic drawing number is 22S375A, where
22 means the VME product line and S means schematic and A is the rev
letter.
22D375A is the PCB fab (drill) drawing and pcb design file name.
22A375A is the pcb assembly drawing.
22M37501B might be a mechanical part drawing, like a front panel.
22A375.1A is the BOM file for the sellable -1 version.
During development, we iterate the schematic and PCB together, as
22S375A4 and 22D375A4, for example.
We have a formal procedure about all this. FPGAs, uP code, test sets
and procedures and software have to be coordinated too.
Times hundreds of products with rev letters and dash number versions,
this gets serious.
Prototypes are 99 series, with informal project files on a server.
These are essentially little breadboards. We don't prototype entire
products; we just release the full rev A document set to manufacturing
and expect it to work.
I see, that makes sense. Some designs I'm working on now are modest
enough that can do that with the entire product relatively cheaply, so I >>guess, y'know, existentially speaking, if "A" ended up needing major >>revisions, but _if_ it had worked first time it could've been sell-able, >>that should count that as a letter-revision.
That is to say I guess it makes sense to be consistent and give any full >>board that gets manufactured in whatever quantity a letter revision, and
I like the idea of giving "little breadboards" that aren't a full thing >>their own project/test series designation
We roll the rev letter if there is any change to the schematic or the
PCB. Dash numbers identify versions, like parts values or stuffing
options. A new BOM can create a dash number without revving the PCB.
This is a quasi-military drawing number system which is in fact
acceptable to the US military and NASA.
It's important to note that only physical things have dash numbers.
Drawings don't.
We have one big customer that assigns the next available 12-digit
number (their 12NC) to the next thing that needs a number. A
schematic, a forklift, a building, an employee. You need a
cross-reference to tell which schematic corresponds to which PCB.
On Mon, 24 Mar 2025 14:19:56 -0700, Don Y
<[email protected]d> wrote:
On 3/24/2025 11:14 AM, bitrex wrote:
How do you version control your PCBs these days?
Just like any other version control. Part number with revision identifier. >> For *everything* (including the tools used to do this!)
I'm at the point I need to implement a more consistent schema for hardware >>> versions, prototype, and production boards.
Why would there be any difference between them? They are all just
"things placed under version control". Each deserves its own unique
identifier.
DON'T fall for the trap of wanting to assign significance to your
identifiers. That's "small shop" mentality. Avoid the "urge" to
pick identifiers just to make it "easy" on yourself to "recall"
related objects:
product PRD123 is built from
bare PCB PCB123 shot from
with gerbers GER123 defined from
schematic SCH123 populated with parts from
bill-of-material BOM123 and
firmware FRM123 tested to
acceptance procedure ACC123...
This just leads to stupidly long identifiers that will, eventually, prove
incapable of "encoding" the information that you want to be able to "recall" >> unaided.
I've got a small board, here, in front of me. It's a management interface >> for a UPS. Likely produced in tens of thousands, if not more.
There are two different barcode labels affixed. At least 6 different
"process stamps". Two different identifiers *in* the silkscreen.
Yet, obviously only partially populated -- so, we know the silkscreened
identifiers won't tell me what *this* unit actually is!
The manufacturer will have adopted some convention as to which of
the identifiers actually is associated with the topmost level for
this board -- which is likely different than the identifier
assigned to the *kit* in which it was packaged (which included
still other materials).
Perhaps it is not possible to truly and unambiguously identify
THIS item as there may be identifiers "hidden" from view (i.e.,
only "visible" with tools that can directly query the device)
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is the >>> manufacturing revision. Would you letter designate prototypes that are
manufactured as well, or just revisions intended for public consumption?
Why "PCB-"? Will that help you find the schematic for the device
(SCH-12345-Q-D because the schematic need not have a 1:1 correspondence
with the actual *board*!) What about the BoM: BOM-12345-L-F (because
the board might find use in different products each with different
stuffing options)?
Will you end up choosing a marketing name that allows you to similarly
associate with these "manufacturing identifiers": Frajistat 12345?
Will you keep it in the stockroom immediately adjacent to the 12346
device (to make it easier for you to find)? Or, will you let SOMETHING
BETTER EQUIPPED (than your grey matter) keep track of this association
FOR you?
(Identifier, revision). End of story. Whether it is a screw, resistor,
case, procedure, compiled binary, source code, etc.
Do you propose to assign a random number to any drawing or any part or
any variant of any physical assembly?
Do you propose to not have revision letters or dash numbers?
john larkin <[email protected]> wrote:
On Mon, 24 Mar 2025 14:19:56 -0700, Don Y
<[email protected]d> wrote:
On 3/24/2025 11:14 AM, bitrex wrote:
How do you version control your PCBs these days?
Just like any other version control. Part number with revision identifier. >>> For *everything* (including the tools used to do this!)
I'm at the point I need to implement a more consistent schema for hardware >>>> versions, prototype, and production boards.
Why would there be any difference between them? They are all just
"things placed under version control". Each deserves its own unique
identifier.
DON'T fall for the trap of wanting to assign significance to your
identifiers. That's "small shop" mentality. Avoid the "urge" to
pick identifiers just to make it "easy" on yourself to "recall"
related objects:
product PRD123 is built from
bare PCB PCB123 shot from
with gerbers GER123 defined from
schematic SCH123 populated with parts from
bill-of-material BOM123 and
firmware FRM123 tested to
acceptance procedure ACC123...
This just leads to stupidly long identifiers that will, eventually, prove >>> incapable of "encoding" the information that you want to be able to "recall"
unaided.
I've got a small board, here, in front of me. It's a management interface >>> for a UPS. Likely produced in tens of thousands, if not more.
There are two different barcode labels affixed. At least 6 different
"process stamps". Two different identifiers *in* the silkscreen.
Yet, obviously only partially populated -- so, we know the silkscreened
identifiers won't tell me what *this* unit actually is!
The manufacturer will have adopted some convention as to which of
the identifiers actually is associated with the topmost level for
this board -- which is likely different than the identifier
assigned to the *kit* in which it was packaged (which included
still other materials).
Perhaps it is not possible to truly and unambiguously identify
THIS item as there may be identifiers "hidden" from view (i.e.,
only "visible" with tools that can directly query the device)
E.g. PCB-12345-R-B where 12345 is the PCB/product identifier and B is the >>>> manufacturing revision. Would you letter designate prototypes that are >>>> manufactured as well, or just revisions intended for public consumption? >>>Why "PCB-"? Will that help you find the schematic for the device
(SCH-12345-Q-D because the schematic need not have a 1:1 correspondence
with the actual *board*!) What about the BoM: BOM-12345-L-F (because
the board might find use in different products each with different
stuffing options)?
Will you end up choosing a marketing name that allows you to similarly
associate with these "manufacturing identifiers": Frajistat 12345?
Will you keep it in the stockroom immediately adjacent to the 12346
device (to make it easier for you to find)? Or, will you let SOMETHING
BETTER EQUIPPED (than your grey matter) keep track of this association
FOR you?
(Identifier, revision). End of story. Whether it is a screw, resistor, >>> case, procedure, compiled binary, source code, etc.
Do you propose to assign a random number to any drawing or any part or
any variant of any physical assembly?
Do you propose to not have revision letters or dash numbers?
Far from unknown. It does introduce a critical dependency on some database.
(Windchill is a popular choice, or was a decade ago when I last looked. )
I�m with you�it�s good for stuff to be human-manageable.
I’m with you—it’s good for stuff to be human-manageable.
Below some size, this can be done.
I've run into problems trying to code the sub-fields of small
addresses (used within some hardware gadget). It took only two or
three implementations of such gadgets before one ran out of code
space. The solution was to make each kind of gadget have its own
subfield coding, because these devices were bespoke anyway.
On 3/24/2025 3:01 PM, Joe Gwinn wrote:
I�m with you�it�s good for stuff to be human-manageable.
Below some size, this can be done.
For most non-trivial businesses, that size is quickly exceeded.
How many part numbers does Bourns assign to resistors? JUST
resistors? Surely, unless you declare on Day 1 that you will
never use a particular power rating, physical size, value,
tolerance, etc., then YOUR numbering system must be able to uniquely >accommodate ALL of their parts! (and, some way of accepting "identical" >parts made by some other manufacturer -- with undoubtedly different
part numbers!)
Repeat for chokes, BJTs, FETs, caps, etc.
And, when a new packaging (or fabrication) technology comes
along, you'll be ready to REVISE your numbering scheme to
accommodate *that*!
Will you ever know if a particular identifier maps to a *real*
device? I.e., are there HOLES in your numbering system??
I've run into problems trying to code the sub-fields of small
addresses (used within some hardware gadget). It took only two or
three implementations of such gadgets before one ran out of code
space. The solution was to make each kind of gadget have its own
subfield coding, because these devices were bespoke anyway.
You end up with every type of device needing its own "system".
In which case, why not just adopt a system of using
(manufacturer, manufacturer's-part-number)
instead of wasting your time trying to create another system that
MIMICs those on which you will rely?
If I depopulate the diagnostic/test connector from a board
"effective serial number XYZ", is that a new revision? A new
board? If I *repurpose* said connector at a higher level
in the assembly hierarchy, is THAT a different board?
If I install entirely different firmware (effectively changing
the high level function of the board), is THAT a new assembly?
If I replace the search algorithm in a piece of code with a
different algorithm, is this a new revision?
On 3/24/2025 3:01 PM, Joe Gwinn wrote:
I’m with you—it’s good for stuff to be human-manageable.
Below some size, this can be done.
For most non-trivial businesses, that size is quickly exceeded.
And, when a new packaging (or fabrication) technology comes
along, you'll be ready to REVISE your numbering scheme to
accommodate *that*!
Will you ever know if a particular identifier maps to a *real*
device? I.e., are there HOLES in your numbering system??
The more you encode in a part number, the more brittle your
numbering scheme becomes. And, the more reliant you become on
fallible, REPLACEABLE human beings.
On 3/24/2025 3:48 PM, Don Y wrote:
On 3/24/2025 3:01 PM, Joe Gwinn wrote:
I’m with you—it’s good for stuff to be human-manageable.
Below some size, this can be done.
For most non-trivial businesses, that size is quickly exceeded.
And, when a new packaging (or fabrication) technology comes
along, you'll be ready to REVISE your numbering scheme to
accommodate *that*!
Will you ever know if a particular identifier maps to a *real*
device? I.e., are there HOLES in your numbering system??
The more you encode in a part number, the more brittle your
numbering scheme becomes. And, the more reliant you become on
fallible, REPLACEABLE human beings.
From _Engineering Documentation Control Handbook_:
"The most critical of these issues is that, over time, the significant
numbering systems tend to break down. As time passes, variations arise
which were not foreseen. One digit was set aside where two are now needed.
Significant numbers thus tend to lose their significance. They no longer
do the classification coding function intended by their inventors."
From _Engineering Documentation Control Practices and Procedures_:
"Typically, companies run out of numbers in certain categories of a
significant number. Also, a non-significant part number is more
cost-effective to use than a significant part number."
From _Bills of Materials: Structured for Excellence_:
"The solution is to use shorter non-significant part numbers. We have
found that part numbers of 5 or 6 digits are the most effective."
From _Manufacturing Data Structures_:
"Another important point about item numbers is that they should be as
short as possible. Part numbers are keyed, copied and used as verbal
identifiers. The shorter the numbers, the more accurate people can be.
Obviously, the greater the number of digits in a part number, the greater
chance of error. We also recommend that only numeric digits be used."
From _CMII for Business Process Infrastructure_:
"Identification numbers are preferably short, not long. The characters
that make up the number are preferably numeric, not alpha. Any symbols
to be used with the numeric characters are preferably limited to
dashes."
How much "significance" can you embed in an identifier when the TOTAL
length
of the identifier should be "SHORT" numerics?
When I first started off in business, I opted for 8 digit identifiers (because DOS filenames of 8 characters were readily supported and because NUMBERS are easier to track than arbitrary character sequences).
I figured 6 digits was too few; 8 was likely too many (but not
prohibitively
costly to support with the technology available at the time -- Paradox, dBase, etc.) And, variable identifier lengths means you never really
know if you have a valid identifier unless "something" can check it for
you.
(Are resistors xxxx-yyy? Or, xxxx-yy-z? Or...)
I've since scaled this back to 7 digits plus a check digit (the issuing authority ensures the correct check digit is created for any 7 digit "serial"). The check digit helps catch the case of numbers that may
have been transcribed (handwritten!) poorly.
In hindsight, I should have started with 1000000 instead of 0000000 as,
too often, I have to convince some piece of software NOT to drop leading zeroes in those identifiers! :<
In a hardware-oriented business, it's hard to actually *use* that
many identifiers; how many DIFFERENT screws do you use? If you opt
to use *one* clutch head screw in a design, do you have to set aside
a whole block of numbers to SIGNIFICANTLY encode head size, thread
pitch and length? What about when someone opts to use a Pozidriv fastener? (all those silly numbers -- and numbering SCHEMES -- created
for parts that you will likely never use!)
OTOH, if your "products" are primarily "paper", you can use hundreds of identifiers in short order; any object that needs to have its presence
in an assembly identified and its configuration changes preserved.
E.g., I use numeric file names for each module, specification, datasheet, etc. I create symlinks (or hardlinks, as appropriate) to give them "familiar names" (like stdio.h). But, these identifiers don't *formally* exist. (WHICH "stdio.h" are you talking about?)
If your company ad product line dies with you (many do), then you can do whatever you want (Ikea gives "names" to products). But, if you want
your designs to persist after you've left the business (or, if you
have to deal with certification authorities or investors who want
to purchase your business for more than "value of inventory on hand"),
then you want systems in place that don't rely on silly quirks
put in place historically.
"No. I can replace a single page if necessary. So, each EPROM
/in the set/ can be at a different revision level. It's up to
Engineering to manage this (configuration management) so only
valid "combinations" of those devices are incorporated into a
released product."
How about a bidirectional hash table for part # generation
On 3/25/2025 12:19 AM, bitrex wrote:
How about a bidirectional hash table for part # generation
I just use a "serial" data type; it's an integer that automatically >increments each time you add a row (an entry/record) to a table
in a database.
A procedure in the database then computes the check digit for that
particular "serial" and appends it as the 8th digit.
The use of "serial" ensures there are no duplications in the table.
The check digit acts to ensure errors in using the part number
(serial+check digit) are caught: 1234567X is valid but
any other value of X is "not a valid part number".
(No way to identify WHICH digit -- including the check digit -- is
in error. But, it reduces the chance of you mistakenly using, e.g.,
a *screw* instead of the intended *resistor*.)
The alternative, (putting significance in the numbering scheme)
means you will end up with more digits in your identifiers AND
lots of valid part numbers that you never actually use!
(What's your part number for the 44R2 1% resistor you use in
ONE of your designs? Likely you also have available a part number
for a 43R2, as well?? In fact, you probably have 1000 part
numbers -- 3 digits -- reserved to address 1% resistors over 10
decades!
power rating, etc. All "created" just because you chose to use
ONE particular device of that type /in your business/.)
((And, when SMT components came on the market, you had to adjust your >numbering scheme to accommodate them in the context of the existing
devices))
My first employer had fits trying to sort out how to assign part
numbers to the (EP)ROMs in our design:
"What's *in* this particular EPROM?"
<shrug>
"What do you mean, you don't know? How do we manufacture it?"
"The program is a book. That EPROM represents pages 100-199
in the book. Can you tell me which chapters that includes, today?
Can you tell me which chapters it will include when I revise the
book??"
"Then, it only exists in the context of other related parts!
The 'other chapters'. And, can only be changed with changes
to those other chapters!"
"No. I can replace a single page if necessary. So, each EPROM
/in the set/ can be at a different revision level. It's up to
Engineering to manage this (configuration management) so only
valid "combinations" of those devices are incorporated into a
released product."
On 3/25/2025 3:44 AM, Don Y wrote:
"No. I can replace a single page if necessary. So, each EPROM
/in the set/ can be at a different revision level. It's up to
Engineering to manage this (configuration management) so only
valid "combinations" of those devices are incorporated into a
released product."
This last is important. If you want to force a production change,
you have to change a part number, not a revision level.
E.g., I can revise an algorithm in a particular piece of code.
Any revision will perform identically (if performance is
defined by getting the correct "result"/return value). A new
revision may change some other aspect -- a faster algorithm,
smaller, better documented, etc. -- but is same fit/form/function
as the earlier revision.
If I *need* the product to use a newer version of that algorithm,
then I have to give the function a new part number and update the
BoM (makefile) to reflect that new part number.
for x in 1,2,3,4,5
do
<blah>
done
can be replaced by:
for x in 2,4,1,3,5
do
<blah>
done
if side effects are ignored. So, there's no need to discard
the builds where the first version was embedded in the binary
in favor of the second.
However, if the second MUST be used, then it must carry a
different P/N so the referencing BoM calls out *THAT* P/N.
But, most folks don't treat software as "trackable components"
and assume the revision is part of the part number.
OK so...how should I do revisions of this PCB/product (the product is the PCB)
again? It has a board, and uP code, and FPGA code. Can you provide a motivational example
Apparently HP had it right when every product was just like some meaningless number followed by a revision letter, eh?
Read the BOM.
People build airplanes, dams, all sorts of things without difficulty.
I think I'm just gonna use manufacturer PNs for externally-sourced parts; having to consult a table to find out PN 4917485 is just like a bloody 10k 0402
resistor sounds like bullshit to me.
On 3/25/2025 11:12 AM, john larkin wrote:
Read the BOM.
People build airplanes, dams, all sorts of things without difficulty.
I think I'm just gonna use manufacturer PNs for externally-sourced
parts; having to consult a table to find out PN 4917485 is just like a
bloody 10k 0402 resistor sounds like bullshit to me.
On 3/25/2025 12:37 PM, bitrex wrote:
I think I'm just gonna use manufacturer PNs for externally-sourced parts;
having to consult a table to find out PN 4917485 is just like a bloody 10k 0402
resistor sounds like bullshit to me.
What happens when you outsource its manufacturing?
Will they be REQUIRED to obtain THE part from THE
manufacturer specified? How will they know that they
can substitute an equivalent part, more readily available
(or less costly)?
On Tue, 25 Mar 2025 15:37:10 -0400, bitrex <[email protected]> wrote:
On 3/25/2025 11:12 AM, john larkin wrote:
Read the BOM.
People build airplanes, dams, all sorts of things without difficulty.
I think I'm just gonna use manufacturer PNs for externally-sourced
parts; having to consult a table to find out PN 4917485 is just like a
bloody 10k 0402 resistor sounds like bullshit to me.
If we used a mpn on a BOM, how would we handle alternate vendors?
When you see an mpn on your BOM, how do you know what it is? Google
it? It ain't always obvious. It turns out that there are many
different things with manufacturers part number "54"
We have 1800 BOMs. I wouldn't want to edit 600 of them if I switch
from Panasonic to Murata for a bypass cap.
We don't consult a table, we just run our MAX program. I can type in a
stock number, a description, or a mfr part number. I can see where any
part is used. Many parts have associated folders with data sheets,
notes, pictures.
I can do a search for res++0805++4.99K and see what we have in
stock. Anybody serious, that has hundreds of parts that they use,
needs a system like this. We have over 8000.
On 3/25/2025 4:46 PM, john larkin wrote:
On Tue, 25 Mar 2025 15:37:10 -0400, bitrex <[email protected]> wrote:
On 3/25/2025 11:12 AM, john larkin wrote:
Read the BOM.
People build airplanes, dams, all sorts of things without difficulty.
I think I'm just gonna use manufacturer PNs for externally-sourced
parts; having to consult a table to find out PN 4917485 is just like a
bloody 10k 0402 resistor sounds like bullshit to me.
If we used a mpn on a BOM, how would we handle alternate vendors?
When you see an mpn on your BOM, how do you know what it is? Google
it? It ain't always obvious. It turns out that there are many
different things with manufacturers part number "54"
We have 1800 BOMs. I wouldn't want to edit 600 of them if I switch
from Panasonic to Murata for a bypass cap.
We don't consult a table, we just run our MAX program. I can type in a
stock number, a description, or a mfr part number. I can see where any
part is used. Many parts have associated folders with data sheets,
notes, pictures.
I can do a search for res++0805++4.99K and see what we have in
stock. Anybody serious, that has hundreds of parts that they use,
needs a system like this. We have over 8000.
I do have a database of parts I have on hand, mainly for my own sanity
when finding parts to prototype something with. I outgrew the
organizational limits of just writing categories on drawers in Sharpie a >while back, I have too many distinct parts.
But I don't always keep stock on hand of every part that's in a design >though, like you I don't breadboard whole designs. A recent design has a >78M05 in TO-252 in it I don't have any myself, I'm pretty confident how
it will behave.
On 3/25/2025 12:37 PM, bitrex wrote:
I think I'm just gonna use manufacturer PNs for externally-sourced parts;
having to consult a table to find out PN 4917485 is just like a bloody 10k >> 0402 resistor sounds like bullshit to me.
What happens when you outsource its manufacturing?
Will they be REQUIRED to obtain THE part from THE
manufacturer specified? How will they know that they
can substitute an equivalent part, more readily available
(or less costly)?
On 3/25/2025 3:44 AM, Don Y wrote:
"No. I can replace a single page if necessary. So, each EPROM
/in the set/ can be at a different revision level. It's up to
Engineering to manage this (configuration management) so only
valid "combinations" of those devices are incorporated into a
released product."
This last is important. If you want to force a production change,
you have to change a part number, not a revision level.
E.g., I can revise an algorithm in a particular piece of code.
Any revision will perform identically (if performance is
defined by getting the correct "result"/return value). A new
revision may change some other aspect -- a faster algorithm,
smaller, better documented, etc. -- but is same fit/form/function
as the earlier revision.
If I *need* the product to use a newer version of that algorithm,
then I have to give the function a new part number and update the
BoM (makefile) to reflect that new part number.
On 3/25/2025 3:53 AM, Don Y wrote:
On 3/25/2025 3:44 AM, Don Y wrote:
�� "No.� I can replace a single page if necessary.� So, each EPROM
�� /in the set/ can be at a different revision level.� It's up to
�� Engineering to manage this (configuration management) so only
�� valid "combinations" of those devices are incorporated into a
�� released product."
This last is important.� If you want to force a production change,
you have to change a part number, not a revision level.
E.g., I can revise an algorithm in a particular piece of code.
Any revision will perform identically (if performance is
defined by getting the correct "result"/return value).� A new
revision may change some other aspect -- a faster algorithm,
smaller, better documented, etc. -- but is same fit/form/function
as the earlier revision.
If I *need* the product to use a newer version of that algorithm,
then I have to give the function a new part number and update the
BoM (makefile) to reflect that new part number.
To drive this home: ><https://www.product-lifecycle-management.com/plm-best-practice-revision.htm> ><https://cdn2.hubspot.net/hubfs/2568500/Content%20Offer%20PDFs/MCL_Revision_vs_New_Part_Number_Infographic.pdf>
<https://plmadvisors.com/plm-and-configuration-management-best-practices-part-numbers/>
Assuming you have assigned part numbers to each software module/file, >consider how you currently think of "version control". Is a rev B
version of that file INTERCHANGEABLE with a rev A version (see above >criteria)? Likely the new file would have an augmented set of
test cases to reflect the fact that it is now tested against the
condition(s) that the earlier version was found to be defective!
[So, *two* documents need to change before this is propagated]
Chances are, it is not! Rev B likely came about to FIX something
that was broken in rev A. So, using rev B in place of rev A would
lead to a different product (one that is more correct than the
predecessor).
As such, the part number for that file should change to reflect this >incompatibility. This change would then propagate upward through the >assemblies to eventually reflect the fact that the finished product
with the "revised file" is, in fact, a different and not interchangeable >product with those that were built on the unrevised file.
You surely wouldn't build a copy of last year's code base and try to
pawn it off as identical with the most recent codebase!
On Tue, 25 Mar 2025 23:28:01 -0700, Don Y
<[email protected]d> wrote:
On 3/25/2025 3:53 AM, Don Y wrote:
On 3/25/2025 3:44 AM, Don Y wrote:
�� "No.� I can replace a single page if necessary.� So, each EPROM
�� /in the set/ can be at a different revision level.� It's up to
�� Engineering to manage this (configuration management) so only
�� valid "combinations" of those devices are incorporated into a
�� released product."
This last is important.� If you want to force a production change,
you have to change a part number, not a revision level.
E.g., I can revise an algorithm in a particular piece of code.
Any revision will perform identically (if performance is
defined by getting the correct "result"/return value).� A new
revision may change some other aspect -- a faster algorithm,
smaller, better documented, etc. -- but is same fit/form/function
as the earlier revision.
If I *need* the product to use a newer version of that algorithm,
then I have to give the function a new part number and update the
BoM (makefile) to reflect that new part number.
To drive this home: >><https://www.product-lifecycle-management.com/plm-best-practice-revision.htm> >><https://cdn2.hubspot.net/hubfs/2568500/Content%20Offer%20PDFs/MCL_Revision_vs_New_Part_Number_Infographic.pdf>
Once a customer orders a Q451, they will expect to be able to order
more Q451's. And we advertise the virtues of Q151's. So even if we add
an LED or a software feature, we want to still call it a Q151, and
roll the rev letter internally.
The FFF thing is more a military requirement. Or a requirement from
people like Intel with a copy-exact philisophy.
<https://plmadvisors.com/plm-and-configuration-management-best-practices-part-numbers/>
Assuming you have assigned part numbers to each software module/file, >>consider how you currently think of "version control". Is a rev B
version of that file INTERCHANGEABLE with a rev A version (see above >>criteria)? Likely the new file would have an augmented set of
test cases to reflect the fact that it is now tested against the >>condition(s) that the earlier version was found to be defective!
[So, *two* documents need to change before this is propagated]
Chances are, it is not! Rev B likely came about to FIX something
that was broken in rev A. So, using rev B in place of rev A would
lead to a different product (one that is more correct than the >>predecessor).
As such, the part number for that file should change to reflect this >>incompatibility. This change would then propagate upward through the >>assemblies to eventually reflect the fact that the finished product
with the "revised file" is, in fact, a different and not interchangeable >>product with those that were built on the unrevised file.
Compatibility of hardware and software is controlled by the BOM for
this specific product/rev/dash number. The BOM has comments when that
would help.
We don't revise released software. That would be a nightmare.
You surely wouldn't build a copy of last year's code base and try to
pawn it off as identical with the most recent codebase!
Last years code was compiled and released and archived, with a drawing
number and a rev letter. Any changes would be a new rev letter with a
new release package. Why treat software any different than hardware?
On the internet, people can and do push out buggy code releases often.
On an electronic instrument, it's not a good idea to do that.
Form, Fit, and Function is now widely applied:
.<https://en.wikipedia.org/wiki/Form,_fit_and_function>
On 3/26/2025 12:22 PM, Joe Gwinn wrote:
Form, Fit, and Function is now widely applied:
.<https://en.wikipedia.org/wiki/Form,_fit_and_function>
It is also how customers think of products.
Is your BMW 320i EXACTLY the same as the one that was
parked immediately adjacent to it on the dealer's lot
at the time of sale? Are you *sure* all of the components
and subassemblies from which it was built are EXACTLY
the same (i.e., same rev levels of same part numbers?).
Do you, as a customer, *care*? Or, do you have a notion
of what a "320i" is and are satisfied that the vehicle
you purchased fits that interpretation?
You likely would be upset if told that this particular
vehicle happened to have "rev A" subassemblies in it
while all the other units on the lot were rev B or later.
"Do I get a discount for that? Or, will you upgrade
the assemblies to the latest AT NO COST TO ME?"
In general, people want the "latest and greatest". You
sure wouldn't want to buy something with an OLD version
of firmware in it (as newer versions tend to fix bugs in
older versions and/or add features/functionality/performance).
In *regulated* markets, you may want to be able to purchase
a specific version of a product -- if only to ensure 100%
compatibility with other instances you'd already acquired.
As such, you want (need!) the vendor to be able to roll
back his CM system to any arbitrary point in time and
create "one of those" (obviously, for some financial
consideration).
E.g., in the gaming world, I need to be able to recreate
a particular make/model/*serialnumber* of a built game if
there is some concern that there may be a hardware or
software flaw in THAT particular instance:
"Serial number 12345 has been paying out at a statistically
significant higher level than the rest of the herd. Can
you explain why? Was there any change in the production
of that unit that might be suspect? We've already
PHYSICALLY examined the unit for signs of compromise..."
The military is particularly obsessive about this sort of thing.
*And*, saddled with older CM technology.
A well designed CM system can also be leveraged for marketing
and support purposes. E.g., I can create a virtual part number
that represents "Joe's 320i" which is little more than a
wrapper around the purchase order he placed -- and delivery
manifest associated with -- for his vehicle.
Now, I can issue a query to identify all SALES and associated
customers who happen to have an instance of the vehicle (ANY
vehicle that I may have sold) that uses a bolt discovered to
be defective! No need to create an entirely different system
to handle such queries!
Or, identify sales of vehicles that included navigation systems
so I can pitch a "map update" to them (I surely wouldn't want
to incur the cost of reaching out to folks who purchased
vehicles that DON'T have navigation systems -- the map update
wouldn't have any applicability, there!
A sale is just a different type of "relationship" with a
(top level) BoM. (though I can likewise identify any customers
who purchased "spare parts" that include the items of concern
as well as the vendors f5rom which the parts were obtained)
A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4. Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.
So, should they have sold the rev. 1.4 3B+ as something different
(3.1B+)?
No idea what changed, but it must have been significant enough
to require a change to the bootloader.
I assume (hope) it was a
necessary change, i.e. it wasn't possible to make any more rev.
1.3 parts, and not just tinkering or cost reduction, though I
suspect the latter. In that case we'd happily pay (a little)
more for compatibility :(
On 3/27/2025 1:12 AM, Ian wrote:
A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4.
Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.
It's hard to imagine something changed that much that the
firmware couldn't have "massaged" the interface to be
compatible.
On 2025-03-27, Don Y <[email protected]d> wrote:
On 3/27/2025 1:12 AM, Ian wrote:
A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4.
Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.
It's hard to imagine something changed that much that the
firmware couldn't have "massaged" the interface to be
compatible.
Well the newer firmware could handle both revs of course, but our
image was built on the older firmware which knew nothing of this
newfangled 1.4 tin.
And the new firmware only came with a new kernel, and new userland
software stack that was incompatible with our driver and application,
so we had to knife'n'fork the new firmware into the image as the
least worst solution.
And, whats even more annoying, was that we'd done a bulk order for
the Pi3B+ to avoid this sort of thing, but half the delivery was
delayed by 12 months over the pandemic parts shortage.
End moan :)
On 3/29/2025 8:48 AM, Ian wrote:
On 2025-03-27, Don Y <[email protected]d> wrote:
On 3/27/2025 1:12 AM, Ian wrote:
A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4.
Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.
It's hard to imagine something changed that much that the
firmware couldn't have "massaged" the interface to be
compatible.
Well the newer firmware could handle both revs of course, but our
image was built on the older firmware which knew nothing of this
newfangled 1.4 tin.
And the new firmware only came with a new kernel, and new userland
software stack that was incompatible with our driver and application,
so we had to knife'n'fork the new firmware into the image as the
least worst solution.
And, you have to consider how your device "looks" (in terms of
compatibility) to *your* customers. If you are trying to
keep compatibility between YOUR revisions (and avoid a part
number change), then you are forced to take extra measures to
accommodate their unexpected/unwanted "change".
And, whats even more annoying, was that we'd done a bulk order for
the Pi3B+ to avoid this sort of thing, but half the delivery was
delayed by 12 months over the pandemic parts shortage.
If they had treated the "revision" as it should have been (i.e.,
identical FFF), then you wouldn't have cared if half of your
purchase was rev 1.3 and the other half 1.4 (or 1.9!). Because
they would be INTERCHANGEABLE.
*Or*, you would have been made aware of the difference when
notified "We no longer have any P/N xyz; would you accept
P/N abc, instead, for the balance of your order?"
On 2025-03-29, Don Y <[email protected]d> wrote:
On 3/29/2025 8:48 AM, Ian wrote:
On 2025-03-27, Don Y <[email protected]d> wrote:
On 3/27/2025 1:12 AM, Ian wrote:
A real example, that caused some pain, was the Raspberry Pi 3B+,
which at some point changed internally from rev. 1.3 to rev 1.4.
Unfortunately this was not made visible on purchase ("It's an RPi
3B+"), and the firmware image we were using wouldn't boot on the
rev. 1.4 hardware.
It's hard to imagine something changed that much that the
firmware couldn't have "massaged" the interface to be
compatible.
Well the newer firmware could handle both revs of course, but our
image was built on the older firmware which knew nothing of this
newfangled 1.4 tin.
And the new firmware only came with a new kernel, and new userland
software stack that was incompatible with our driver and application,
so we had to knife'n'fork the new firmware into the image as the
least worst solution.
And, you have to consider how your device "looks" (in terms of
compatibility) to *your* customers. If you are trying to
keep compatibility between YOUR revisions (and avoid a part
number change), then you are forced to take extra measures to
accommodate their unexpected/unwanted "change".
Quite. Fortunately our customer is somewhat less fussy then the US
DoD in that respect, though they do rather expect the thing to
actually work.
And, whats even more annoying, was that we'd done a bulk order for
the Pi3B+ to avoid this sort of thing, but half the delivery was
delayed by 12 months over the pandemic parts shortage.
If they had treated the "revision" as it should have been (i.e.,
identical FFF), then you wouldn't have cared if half of your
purchase was rev 1.3 and the other half 1.4 (or 1.9!). Because
they would be INTERCHANGEABLE.
*Or*, you would have been made aware of the difference when
notified "We no longer have any P/N xyz; would you accept
P/N abc, instead, for the balance of your order?"
Our main objective was to avoid rewriting our application to use
a different kernel API at that point in time.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 133:53:02 |
| Calls: | 12,087 |
| Files: | 14,997 |
| Messages: | 6,517,349 |