From: John Larkin on
On Sun, 04 Oct 2009 15:01:18 -0700, Joerg <invalid(a)invalid.invalid>
wrote:

>John Larkin wrote:
>> On Sat, 03 Oct 2009 12:04:03 -0700, Joerg <invalid(a)invalid.invalid>
>> wrote:
>>
>>> John Larkin wrote:
>>>> On Fri, 02 Oct 2009 07:09:34 -0700, Joerg <invalid(a)invalid.invalid>
>>>> wrote:
>>>>
>>>>> John Larkin wrote:
>
>[...]
>
>>>>>> To calarify, this is rev 30 of the working layout. We haven't fabbed
>>>>>> any boards yet.
>>>>>>
>>>>>> The PCB file will be formally released as 26D150A.PCB, to make rev A
>>>>>> of the product. During layout, we number every iteration. If we change
>>>>>> a net or add a resistor or whatever, we start with schematic
>>>>>> 26S150A29.SCH, change it to 26S150A30.SCH and save that, make the
>>>>>> differences file ECO30, apply that onto pcb 26D150A29.PCB, and save as
>>>>>> 26D150A30.PCB. So we have all the iterations and all the ECO files,
>>>>>> all organized. When we release the schematic and pcb as rev A, we
>>>>>> delete all that working junk. Since we're iterating on the BGA pinout,
>>>>>> we're spinning a lot of ECOs.
>>>>>>
>>>>>> If we go A to B, we start the sequence all over, 26S150B1.SCH etc.
>>>>>>
>>>>> I do it similarly, except adding X1, X2 and so on. And I usually cannot
>>>>> erase the intermediates upon ECO-release because federal agencies often
>>>>> require that a complete design history be kept. So if you do medical,
>>>>> maybe better not to toss it.
>>>> The next logical step would be to log every key and mouse click, and
>>>> videotape everything that happens in Engineering.
>>>>
>>> Orwell ...
>>>
>>> But seriously, all they want is that you are able to show, for example,
>>> why you dismissed a direct conversions scheme somewhere, how the old
>>> schematic looked, and how the new one looks. An answer like "Oh, ahm,
>>> well, I guess we must have purged the old files" raises some flags and
>>> creates an urge to dig some more.
>>>
>>> They don't want to know the shoe size of all the people signing an ECO.
>>> At least not yet :-)
>>
>> The ECOs I'm talking about are just "differences" files that PADS
>> makes whenever you edit a schematic and want to carry the changes over
>> to the PCB. We can do several of them a day when a board is being
>> created or revised. At the end, we crosscheck the schematic and pcb
>> netlists and formally release the new letter rev. We always archive
>> all the released files of all the revs, and anything else that
>> controls the configuration or processing of anything shippable.
>>
>
>That appears to be a sound procedure. As long as some prose is kept
>alongside so you don't have to wonder in front of an inspector "Now why
>did we change that?".

Inspector?

We keep a "next" file on a server, something like

J:\NEXT\V470\AtoB.TXT

where anybody who has anything to say about rev A adds whatever they
want to say. Production will comment on a pad or drill size.
Purchasing will note any part EOL notices or whatever. Engineering
might suggest a circuit change or a possible feature. Like that. Keeps
us from forgetting the little stuff. We check any effective ECOs and
the NEXT file whenever we do a board spin, before we decide what to
actually do.

Everything on the servers gets archived regularly.

>
>Can't do that in many of my fields because they are heavily regulated.
>Aero (stuff that will actually be flown for decades) and medical have
>their strict rules. In fact, I know of one large medical device
>manufacturer where the FDA put the padlocks on the doors. Very
>embarrassing. Luckily not a client :-)

As far as I know, we have only one VME module flying, on a C130.
Nobody bothered us about internal procedures. We have lots of stuff in
test stands and deployable test sets, ditto.

Some people do sometimes request our quality procedure, so we send it
to them.

John

From: John Larkin on
On Sun, 04 Oct 2009 17:06:33 -0500, krw <krw(a)att.bizzzzzzzzzzz> wrote:


>>The ECOs I'm talking about are just "differences" files that PADS
>>makes whenever you edit a schematic and want to carry the changes over
>>to the PCB. We can do several of them a day when a board is being
>>created or revised. At the end, we crosscheck the schematic and pcb
>>netlists and formally release the new letter rev. We always archive
>>all the released files of all the revs, and anything else that
>>controls the configuration or processing of anything shippable.
>
>What do you do with "what if" branches off a work in progress? What
>does Joerg do?

I'm not sure what you mean by that.

John

From: krw on
On Sun, 04 Oct 2009 17:28:59 -0700, John Larkin
<jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:

>On Sun, 04 Oct 2009 17:06:33 -0500, krw <krw(a)att.bizzzzzzzzzzz> wrote:
>
>
>>>The ECOs I'm talking about are just "differences" files that PADS
>>>makes whenever you edit a schematic and want to carry the changes over
>>>to the PCB. We can do several of them a day when a board is being
>>>created or revised. At the end, we crosscheck the schematic and pcb
>>>netlists and formally release the new letter rev. We always archive
>>>all the released files of all the revs, and anything else that
>>>controls the configuration or processing of anything shippable.
>>
>>What do you do with "what if" branches off a work in progress? What
>>does Joerg do?
>
>I'm not sure what you mean by that.

You apparently save/rename on any small layout change (with Joerg
taking the obsession to the schematic level). What do you do if you
just want to see how something will work out, not necessarily with the
intention of keeping the test? I often try things on a schematic
(don't do layout myself) just to see how it'll work. I certainly am
not going to do an ECO on every tweak. We're already beat up for the
number of ECOs generated (stupid, but reality often is).
From: John Larkin on
On Sun, 04 Oct 2009 22:06:35 -0500, krw <krw(a)att.bizzzzzzzzzzz> wrote:

>On Sun, 04 Oct 2009 17:28:59 -0700, John Larkin
><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Sun, 04 Oct 2009 17:06:33 -0500, krw <krw(a)att.bizzzzzzzzzzz> wrote:
>>
>>
>>>>The ECOs I'm talking about are just "differences" files that PADS
>>>>makes whenever you edit a schematic and want to carry the changes over
>>>>to the PCB. We can do several of them a day when a board is being
>>>>created or revised. At the end, we crosscheck the schematic and pcb
>>>>netlists and formally release the new letter rev. We always archive
>>>>all the released files of all the revs, and anything else that
>>>>controls the configuration or processing of anything shippable.
>>>
>>>What do you do with "what if" branches off a work in progress? What
>>>does Joerg do?
>>
>>I'm not sure what you mean by that.
>
>You apparently save/rename on any small layout change (with Joerg
>taking the obsession to the schematic level).

We do name and save every schematic change while we're working on a
board layout. The one we're doing now is up to rev 35 or so, after
maybe 2 weeks of layout.

>What do you do if you
>just want to see how something will work out, not necessarily with the
>intention of keeping the test?

I still don't follow the question. How would I "see if something will
work"? Do you mean simulate? We don't simulate from PADS schematics.
Actually, we don't simulate a lot at all, except FPGA logic and the
occasional small subcircuit.


I often try things on a schematic
>(don't do layout myself) just to see how it'll work. I certainly am
>not going to do an ECO on every tweak. We're already beat up for the
>number of ECOs generated (stupid, but reality often is).

The kind of ECO I was discussing is just a PADS .ECO file, the way to
communicate a schematic change from the schematic editor to the PCB
program. Those are essentially scratch files. There's also an OLE
mechanism for syncing the schematic and the board, but that's pretty
much guaranteed to tie things into knots.

That PADS .ECO file is different from a real, formal Engineering
Change Order document.

John

From: Joerg on
John Larkin wrote:
> On Sun, 04 Oct 2009 15:01:18 -0700, Joerg <invalid(a)invalid.invalid>
> wrote:
>
>> John Larkin wrote:
>>> On Sat, 03 Oct 2009 12:04:03 -0700, Joerg <invalid(a)invalid.invalid>
>>> wrote:
>>>
>>>> John Larkin wrote:
>>>>> On Fri, 02 Oct 2009 07:09:34 -0700, Joerg <invalid(a)invalid.invalid>
>>>>> wrote:
>>>>>
>>>>>> John Larkin wrote:
>> [...]
>>
>>>>>>> To calarify, this is rev 30 of the working layout. We haven't fabbed
>>>>>>> any boards yet.
>>>>>>>
>>>>>>> The PCB file will be formally released as 26D150A.PCB, to make rev A
>>>>>>> of the product. During layout, we number every iteration. If we change
>>>>>>> a net or add a resistor or whatever, we start with schematic
>>>>>>> 26S150A29.SCH, change it to 26S150A30.SCH and save that, make the
>>>>>>> differences file ECO30, apply that onto pcb 26D150A29.PCB, and save as
>>>>>>> 26D150A30.PCB. So we have all the iterations and all the ECO files,
>>>>>>> all organized. When we release the schematic and pcb as rev A, we
>>>>>>> delete all that working junk. Since we're iterating on the BGA pinout,
>>>>>>> we're spinning a lot of ECOs.
>>>>>>>
>>>>>>> If we go A to B, we start the sequence all over, 26S150B1.SCH etc.
>>>>>>>
>>>>>> I do it similarly, except adding X1, X2 and so on. And I usually cannot
>>>>>> erase the intermediates upon ECO-release because federal agencies often
>>>>>> require that a complete design history be kept. So if you do medical,
>>>>>> maybe better not to toss it.
>>>>> The next logical step would be to log every key and mouse click, and
>>>>> videotape everything that happens in Engineering.
>>>>>
>>>> Orwell ...
>>>>
>>>> But seriously, all they want is that you are able to show, for example,
>>>> why you dismissed a direct conversions scheme somewhere, how the old
>>>> schematic looked, and how the new one looks. An answer like "Oh, ahm,
>>>> well, I guess we must have purged the old files" raises some flags and
>>>> creates an urge to dig some more.
>>>>
>>>> They don't want to know the shoe size of all the people signing an ECO.
>>>> At least not yet :-)
>>> The ECOs I'm talking about are just "differences" files that PADS
>>> makes whenever you edit a schematic and want to carry the changes over
>>> to the PCB. We can do several of them a day when a board is being
>>> created or revised. At the end, we crosscheck the schematic and pcb
>>> netlists and formally release the new letter rev. We always archive
>>> all the released files of all the revs, and anything else that
>>> controls the configuration or processing of anything shippable.
>>>
>> That appears to be a sound procedure. As long as some prose is kept
>> alongside so you don't have to wonder in front of an inspector "Now why
>> did we change that?".
>
> Inspector?
>

Yep. Sometimes also called auditors. And they do surprise audits. Knock,
knock. "Good morning. I am Mr.So-and-so from the FDA and I would like to
review your complaint database and some engineering items."


> We keep a "next" file on a server, something like
>
> J:\NEXT\V470\AtoB.TXT
>
> where anybody who has anything to say about rev A adds whatever they
> want to say. Production will comment on a pad or drill size.
> Purchasing will note any part EOL notices or whatever. Engineering
> might suggest a circuit change or a possible feature. Like that. Keeps
> us from forgetting the little stuff. We check any effective ECOs and
> the NEXT file whenever we do a board spin, before we decide what to
> actually do.
>
> Everything on the servers gets archived regularly.
>

Sounds like a good method. I keep similar text files so nothing falls
through the cracks. Also helps if a Dodge Ram hits me head-on and
someone else would need to take over. No joke, this has happened. Not to
me but the motorcycle of a client engineer in Europe decided to develop
a crack in the frame at 100mph and then split into two parts. Sparks
flying, leather suit, skin, muscle tissue and some bone chafed off. He
survived but I had to take over for a while. This was only possible
because he documented as much as I do.

Later he bought a Mercedes Diesel and quit riding motorcycles ...


>> Can't do that in many of my fields because they are heavily regulated.
>> Aero (stuff that will actually be flown for decades) and medical have
>> their strict rules. In fact, I know of one large medical device
>> manufacturer where the FDA put the padlocks on the doors. Very
>> embarrassing. Luckily not a client :-)
>
> As far as I know, we have only one VME module flying, on a C130.
> Nobody bothered us about internal procedures. We have lots of stuff in
> test stands and deployable test sets, ditto.
>

But it's probably not something where the captain has to declare an
emergency if it quits ;-)


> Some people do sometimes request our quality procedure, so we send it
> to them.
>


--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.