Driver to drive?

[krw]

In article <MPG.23a76baff80d79d39896c7@172.16.0.1>,
paul@pcserviceselectronics.co.uk says...>

In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.

Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..

No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).

Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be

If you're in a lifetime buy situation the tools don't matter,
however documentation still matters.

Boeing 747
C130 (Hercules in UK)
Nimrod (originally Comet airframe circa late 1950's)

Why single them out?

Having recently looked at some testing equipment that has to work for
at least 10 years, I am aware of the issues and multiple paper/CD/network
storage of documents etc..

Why is test equipment a problem?

 

[John Larkin]

On Mon, 08 Dec 2008 15:29:58 +0000, John Devereux
<john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:


[...]

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).

That's not a problem, it's a feature!

John

 

[John Larkin]

On Mon, 8 Dec 2008 07:43:58 -0800 (PST), Richard Henry
<pomerado@hotmail.com> wrote:

On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

How do you define the difference between a "version" and a "revision"?

Are all version 3 products interchangeable, for example?

A dash number distinguishes an assembly option. This might be a board
stuffing version, a firmware difference (enabling a feature, for
example) or some other variant.

An assembly drawing might be 22A375 rev B. The product might be sold
with SMB, SMA, or LEMO connectors. So we might sell physical items
22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
assembly drawing and the associated products would roll to rev C. Note
that drawings don't have dash numbers, they describe dash numbers.
Physical parts have dash numbers.

A 22A375-3C gadget may well have some features that the 22A375-3B
didn't. We try to keep later revs supersets of older ones, so that
existing customers can buy the newer revs and not have problems.

In the aircraft industry, and odd dash numbered thing (like part
12345-1A) was a part, and the following even dash number 12345-2A was
its mirror image. We don't build airplanes, so we just use sequential
dash numbers to identify versions of a basic assembly.

An assembly or fabrication drawing, unless otherwise noted, assumes
"-1 shown". A flag note on that drawing might say "for -2, drill 0.125
thru, 4 places." For electronic assemblies, dash numbers are usually
just associated with different BOM's (parts lists), so that we can
just release a new parts list to create a new dash number at any time,
without having to revise the released assembly drawing.

We use dash numbers for customer-specific versions, too. 22A375-11B
might be a standard version with an ECO applied.

All the above is pretty much mil/aerospace standard documentation
control.

Lots of people use the next available integer for the drawing number
of anything that's drawn. Then they need some side mechanism, like a
product structure document, to correlate things. We use

22A375      assembly drawing. "22" is our VME series.
            A customer might order a "V375" module.
22D375      pc fab ("drill") drawing
22M375      front panel fab. M = mechanical fab dwg
22M376      cover plate fab maybe
22R375      reference drawing, design notes maybe

22E375      embedded firmware. Source is 22E375C.MAC;
            obj is 22E375C.ROM

22C375      FPGA design. Config file is 22C375A.RBT

like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John

Providing that you still have a computer that can read 5.25" disks.

Everything is released to the library server, a big RAID thing. We do
nightly backups to another server and weekly DVD backup, stored in
multiple off-sites.

We submit files to the librarian on floppies or CDs, and after the
files are copied those originals are also stored off-site. We have had
media go obsolete, like tapes, and we always make sure we have good
copies on current-generation media.

We have had a few files corrupted on the server, not many, and it was
easy to recover them from backups. Our inventory database file has
been in continuous use for over 10 years.

I do have some old 8" floppies that might be hard to read.

John

 

[Joerg]

John Larkin wrote:

[...]

In the aircraft industry, and odd dash numbered thing (like part
12345-1A) was a part, and the following even dash number 12345-2A was
its mirror image. We don't build airplanes, so we just use sequential
dash numbers to identify versions of a basic assembly.

Then I wonder what the mirror of the Dash-8 was

http://www.airliners.net/aircraft-data/stats.main?id=121

[...]

--
SCNR, Joerg

http://www.analogconsultants.com/

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

 

[Joerg]

John Larkin wrote:

On Mon, 08 Dec 2008 09:56:05 +0000, John Devereux
john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.
How do you define the difference between a "version" and a "revision"?

Are all version 3 products interchangeable, for example?
A dash number distinguishes an assembly option. This might be a board
stuffing version, a firmware difference (enabling a feature, for
example) or some other variant.

An assembly drawing might be 22A375 rev B. The product might be sold
with SMB, SMA, or LEMO connectors. So we might sell physical items
22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
assembly drawing and the associated products would roll to rev C.
Do the revision letters *all* get bumped up together for all
"drawings"? For example if you modify the PCB, does the version letter
of the front panel get changed too? (I would assume not). Or just the
assembly drawing and the pc board?

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

You almost have to, at least if there is as much as one little iota in
assembly change cause by the artwork change. With assembly rev changes
the PCB rev does not need to change, and often doesn't in my cases.

[...]

I learned all this from having to do MIL stuff. It must be formally
documented somewhere.

Same in medical. If the federales waltz in for a spot check you have x
minutes to produce a requested document such as a design history for the
inspector. With "x" being single-digit.

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[Michael A. Terrell]

John Larkin wrote:

On Mon, 8 Dec 2008 07:43:58 -0800 (PST), Richard Henry
pomerado@hotmail.com> wrote:

On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

How do you define the difference between a "version" and a "revision"?

Are all version 3 products interchangeable, for example?

A dash number distinguishes an assembly option. This might be a board
stuffing version, a firmware difference (enabling a feature, for
example) or some other variant.

An assembly drawing might be 22A375 rev B. The product might be sold
with SMB, SMA, or LEMO connectors. So we might sell physical items
22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
assembly drawing and the associated products would roll to rev C. Note
that drawings don't have dash numbers, they describe dash numbers.
Physical parts have dash numbers.

A 22A375-3C gadget may well have some features that the 22A375-3B
didn't. We try to keep later revs supersets of older ones, so that
existing customers can buy the newer revs and not have problems.

In the aircraft industry, and odd dash numbered thing (like part
12345-1A) was a part, and the following even dash number 12345-2A was
its mirror image. We don't build airplanes, so we just use sequential
dash numbers to identify versions of a basic assembly.

An assembly or fabrication drawing, unless otherwise noted, assumes
"-1 shown". A flag note on that drawing might say "for -2, drill 0.125
thru, 4 places." For electronic assemblies, dash numbers are usually
just associated with different BOM's (parts lists), so that we can
just release a new parts list to create a new dash number at any time,
without having to revise the released assembly drawing.

We use dash numbers for customer-specific versions, too. 22A375-11B
might be a standard version with an ECO applied.

All the above is pretty much mil/aerospace standard documentation
control.

Lots of people use the next available integer for the drawing number
of anything that's drawn. Then they need some side mechanism, like a
product structure document, to correlate things. We use

22A375 assembly drawing. "22" is our VME series.
A customer might order a "V375" module.
22D375 pc fab ("drill") drawing
22M375 front panel fab. M = mechanical fab dwg
22M376 cover plate fab maybe
22R375 reference drawing, design notes maybe

22E375 embedded firmware. Source is 22E375C.MAC;
obj is 22E375C.ROM

22C375 FPGA design. Config file is 22C375A.RBT

like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John

Providing that you still have a computer that can read 5.25" disks.

Everything is released to the library server, a big RAID thing. We do
nightly backups to another server and weekly DVD backup, stored in
multiple off-sites.

We submit files to the librarian on floppies or CDs, and after the
files are copied those originals are also stored off-site. We have had
media go obsolete, like tapes, and we always make sure we have good
copies on current-generation media.

We have had a few files corrupted on the server, not many, and it was
easy to recover them from backups. Our inventory database file has
been in continuous use for over 10 years.

I do have some old 8" floppies that might be hard to read.

I have a couple half height 8" drives in storage. I saved them,
because they were some of the last built, and have all DC motors.


--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you're crazy.

 

[Joerg]

Tim Wescott wrote:

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "asdf" <sadf@sdff.com> wrote:

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some
hardware). Is it an arbitrary system? I've tried searching for it, but
come up empty handed. I've been able to query on this:

IEEE standard taxonomy for software engineering standards

but, I keep coming up with sites that want me to pay for the article.
Not to mention the fact that the above article will have way more
information that I'm looking for. I can't think of what else to search
on.

Any help?

Thanks,

Scott




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.
It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.
_Any_ revision control system is only as good as the discipline and
integrity of the people running it.
It can be much worse, though.


If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.
Only manufacturing builds and ships stuff. They get their docs only from
the company library. Stuff gets into the library only by formal release.
There are no sneak paths.

At your company, perhaps yes.

.... and pretty much all the clients I work for. Else I would most likely
decline to consult for them. Without a formal release process you'd be
only a few footsteps away from a major lawsuit should something happen.
Because plaintiff's counsel will dig that out.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[Richard Henry]

On Dec 8, 9:37 am, Paul Carpenter <p...@pcserviceselectronics.co.uk>
wrote:

In article <MPG.23a706ae1955768d989...@news.individual.net>,
k...@att.zzzzzzzzz says...





In article <8f4bbb1b-c188-4ede-b2de-
f406e934a...@r36g2000prf.googlegroups.com>, pomer...@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.

Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..

Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be

        Boeing 747
        C130 (Hercules in UK)
        Nimrod (originally Comet airframe circa late 1950's)

Having recently looked at some testing equipment that has to work for
at least 10 years, I am aware of the issues and multiple paper/CD/network
storage of documents etc..

--
Paul Carpenter          | p...@pcserviceselectronics.co.uk
http://www.pcserviceselectronics.co.uk/>    PC Services
http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
http://www.badweb.org.uk/> For those web sites you hate- Hide quoted text -

- Show quoted text -

In my first job, all released documents were paper, even computer
source-code listings which would be impractical to retype and unlikely
to be redone without error. PCB artwork soource documents were hand-
taped vellum.

In my last job, all released documents were electronic files archived
on the local network, backed up on the corporate network across the
country, and periodically archived on "tape" at a local disaster
backup business. Most documents produced were part of the natural
design flow (schematic diagrams, part lists (with some massaging), PCB
artwork "Gerber" files, FPGA source code, etc). The most difficult
and time-consuming documents to produce were Source Control Documents,
a way of assigning our part number to someone else's product, which
usually consisted of a cover sheet followed by pages copied from a
vendor data sheet or catalog.

 

[John Devereux]

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:

On Mon, 08 Dec 2008 15:29:58 +0000, John Devereux
john@devereux.me.uk> wrote:

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:


[...]

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).

That's not a problem, it's a feature!

Aha. I see!

--

John Devereux

 

[Paul Carpenter]

In article <87oczmfzwp.fsf@cordelia.devereux.me.uk>, john@devereux.me.uk
says...

John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:


[...]

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).

I often use two+ digit revisions for circuit etch/revisions

A original etch and circuit match
A1 Etch level A modified to circuit rev A1

B Etch level B rollup match circuit Rev B

To facilitate this the ident layer has etch and circuit rev shown
as letter for etch and white block for circuit rev added as part of
the manufacturing/testing process.

Make sure I keep reference of what revisions are shipped.


--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

 

[Eino]

S.K.22.05.2008."Pölyttäjien täyskato uhkaa viedä kesän marjat. Omenapuut ja
herukat kukkivat monin paikoin jo täysillä, mutta puutarhoissa on hiljaista.
Pölyttäjiä ei ole liikkeellä. Sään lämpeneminenkään ei lupaa helpotusta,
sillä luonnonvaraisten pölyttäjien kannat ovat romahtaneet lähes
OLEMATTOMIIN! vaarassa ovat myös metsämarjat, sielä esim. mustikan, puolukan
ja vadelman pölytys on lähes yksinomaan kimalaisten varassa.

Mehiläistenhoidonneuvoja Ari Seppälä on kartoittanut pölyttäjien tilannetta
koko Suomessa. Uutiset ovat olleet yksinomaan HUONOJA! -arvioisin, että
kimalaisia ja ampiaisia on nyt korkeintaan KYMMENESOSA normaalista tasosta.
Tutulla omenanviljelijällä on tarhassaan tuhat kukivaa puuta. Hän ei ole
nähnyt tänä keväänä ensimmäistäkään kimalaista. Kimalaiset ja ampiaiset
katosivat yllättäen Suomesta viime kesämä. Syytä katoon ei tiedetä. Seppälä
ei usko tilanteen korjaantuvan edes seuraavana kesänä!"

Niin TUSKIN tarvitsee jatkaa? Poriin on ylätuuleen matkaa TVO:lle jo yli
50km. Ja kuten todettiin 90% katoaluetta aina kukkakärpäsiä myöten on aivan
hurjaa. (Huvittavinta, että kyseiselle kaverille lähetin vain parisen viikoa
sitten tiedot ydinaavikoitumisfaktasta, ja KAS oivalteli! Ei sanan sanaa
siitä, ettei Suomella olisi mehiläisistä ongelmia. Kiitokset Ari näin netin
kautta, oikeesti! no toisaalta kaverin netit kuulema turpoavat kiukkuisen
kentän kommentteja aiemmasta virhetiedotuksista! Taisi ryhmäkuri olla
mukana. ))) .. Ydinvoimalan päästöt tappaa siis todetusti jo kautta Suomen!
Joten HÄVETKÄÄ muuta täällä aiemmin vedätelleet!

Vaikka täällä yritetään pajunköyttää ties mitä "varmaa"
virus,punkki,bakteri,mitälie tekaisua" toteennäytetyksi niin Seppälä kuittaa
tällaiset luulot jopa yllättäen ilmoittamalla, ettei syistä ole hajuja!
Porissa vain muutamasta talvipesästä on jokusia punkkeja löytynmyt ja
mehiläiskato on edelleen mysteeri. Niin.. .? Tai oikeammin tarkoittaa sitä,
että YKSIKÄÄN julkisuuden tautipelleilyharhautus ei vakuuta ketään! Eli jää
jäljelle jälleen keran VAIN ne joista kuiskitaan ovien takana.
Ydinionisaation aiheuttama suunnistuseksymiselle jälleen tutusti pojot!
Sanoi ydinklingonit mitä lystää! Outoa kapinointia kentältä, jopa musta,
ettei jotain ole tekaistu syyksi klassisista huijauksista, vaikka ydinala on
parisen vuotta puukottanut? Lieneekö vaan niin, ettei valheet
mehiläiskasvattajiin enää uoppoa, kun netissä puhelevat tietävämmät syyksi
ydinavikoitumisia, ja beetasoihtupäästöjä?)

 

[Paul Carpenter]

In article <MPG.23a72548c1ca82ce9896ee@news.individual.net>,
krw@att.zzzzzzzzz says...

In article <MPG.23a76baff80d79d39896c7@172.16.0.1>,
paul@pcserviceselectronics.co.uk says...
In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John

Providing that you still have a computer that can read 5.25" disks.

Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.

Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..

No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).

There is no point archiving data that is in 90% of the time (or more)
anything other than plain text, without the tools to read it, even if
it is just to print out new copies.

Any archiving is for evaluations and possible modifications later, this
could be many years later, that you need to rebuild then modify code
for software, FPGA or even modelling of circuits or pcbs in electronic
form. In some cases it is to prove again that the design process is
modelled correctly or run scenarios on old simulators first.

Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be

If you're in a lifetime buy situation the tools don't matter,
however documentation still matters.

Yes they do as any part may have to be modified later and
progrrammable parts may need revised coding, even parts on wafer
need alternative packaging requirements for later batches that
then means a new PCB or even heatsink arrangements.

Boeing 747
C130 (Hercules in UK)
Nimrod (originally Comet airframe circa late 1950's)

Why single them out?

They were not singled out, but as it showed above "classic examples".
I could have used many others.

One classic I had about 5 years ago was for an NMR scanner, where
I was looking at replacing a failing part of it, and the EARLIEST
date they could find for the machine was

"...in 1968 it moved to the NEW building.."

Having recently looked at some testing equipment that has to work for
at least 10 years, I am aware of the issues and multiple paper/CD/network
storage of documents etc..

Why is test equipment a problem?

Over the last 10 years more and more test equipment and test procedures
are computer controlled so the test equipment, procedures, test
programmes, and ancillary equipment, needs to be documented and archived.

Test equipment and for testing various parts, subsystems, or systems
sometimes requires dedicated testing equipment. This is part of the
manufacturing process. All parts of the procedures and methods from basic
pcb, loading code to test procedures or programme controlled tests, needs
to be archived and maintained. EVEN IF THE UNIT IS THIRD PARTY PURCHASE.

Changes in these also have to be reverified and ecrtified on changes,
some of which are due to equipment changes, others due to testing
modifications.

Four of my designs over the last two years are specialised ASIC
testers, and I have more to do in the pipeline.

--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

 

[John Larkin]

On Mon, 8 Dec 2008 21:47:25 -0000, Paul Carpenter
<paul@pcserviceselectronics.co.uk> wrote:

In article <87oczmfzwp.fsf@cordelia.devereux.me.uk>, john@devereux.me.uk
says...
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> writes:


[...]

We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.

I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).


I often use two+ digit revisions for circuit etch/revisions

A original etch and circuit match
A1 Etch level A modified to circuit rev A1

B Etch level B rollup match circuit Rev B

To facilitate this the ident layer has etch and circuit rev shown
as letter for etch and white block for circuit rev added as part of
the manufacturing/testing process.

Make sure I keep reference of what revisions are shipped.

That's not bad at all. Full MIL standards require an ECO to change
something, so your "A1" becomes "assy 12345-1A ECO 1412 ECO 1618",
with labels stuck on the poor thing somehow.

We are rarely forced to revise a drawing but keep it coherent with
other rev B drawings, so we re-issue it as rev B1. This is generally
to correct a drawing error.

John

 

[John Fields]

On Mon, 08 Dec 2008 16:56:44 -0600, Eino <schmitt@dehnung.net> wrote:

S.K.22.05.2008."Pölyttäjien täyskato uhkaa viedä kesän marjat. Omenapuut ja
herukat kukkivat monin paikoin jo täysillä, mutta puutarhoissa on hiljaista.
Pölyttäjiä ei ole liikkeellä. Sään lämpeneminenkään ei lupaa helpotusta,
sillä luonnonvaraisten pölyttäjien kannat ovat romahtaneet lähes
OLEMATTOMIIN! vaarassa ovat myös metsämarjat, sielä esim. mustikan, puolukan
ja vadelman pölytys on lähes yksinomaan kimalaisten varassa.

Mehiläistenhoidonneuvoja Ari Seppälä on kartoittanut pölyttäjien tilannetta
koko Suomessa. Uutiset ovat olleet yksinomaan HUONOJA! -arvioisin, että
kimalaisia ja ampiaisia on nyt korkeintaan KYMMENESOSA normaalista tasosta.
Tutulla omenanviljelijällä on tarhassaan tuhat kukivaa puuta. Hän ei ole
nähnyt tänä keväänä ensimmäistäkään kimalaista. Kimalaiset ja ampiaiset
katosivat yllättäen Suomesta viime kesämä. Syytä katoon ei tiedetä. Seppälä
ei usko tilanteen korjaantuvan edes seuraavana kesänä!"

Niin TUSKIN tarvitsee jatkaa? Poriin on ylätuuleen matkaa TVO:lle jo yli
50km. Ja kuten todettiin 90% katoaluetta aina kukkakärpäsiä myöten on aivan
hurjaa. (Huvittavinta, että kyseiselle kaverille lähetin vain parisen viikoa
sitten tiedot ydinaavikoitumisfaktasta, ja KAS oivalteli! Ei sanan sanaa
siitä, ettei Suomella olisi mehiläisistä ongelmia. Kiitokset Ari näin netin
kautta, oikeesti! no toisaalta kaverin netit kuulema turpoavat kiukkuisen
kentän kommentteja aiemmasta virhetiedotuksista! Taisi ryhmäkuri olla
mukana. ))) .. Ydinvoimalan päästöt tappaa siis todetusti jo kautta Suomen!
Joten HÄVETKÄÄ muuta täällä aiemmin vedätelleet!

Vaikka täällä yritetään pajunköyttää ties mitä "varmaa"
virus,punkki,bakteri,mitälie tekaisua" toteennäytetyksi niin Seppälä kuittaa
tällaiset luulot jopa yllättäen ilmoittamalla, ettei syistä ole hajuja!
Porissa vain muutamasta talvipesästä on jokusia punkkeja löytynmyt ja
mehiläiskato on edelleen mysteeri. Niin.. .? Tai oikeammin tarkoittaa sitä,
että YKSIKÄÄN julkisuuden tautipelleilyharhautus ei vakuuta ketään! Eli jää
jäljelle jälleen keran VAIN ne joista kuiskitaan ovien takana.
Ydinionisaation aiheuttama suunnistuseksymiselle jälleen tutusti pojot!
Sanoi ydinklingonit mitä lystää! Outoa kapinointia kentältä, jopa musta,
ettei jotain ole tekaistu syyksi klassisista huijauksista, vaikka ydinala on
parisen vuotta puukottanut? Lieneekö vaan niin, ettei valheet
mehiläiskasvattajiin enää uoppoa, kun netissä puhelevat tietävämmät syyksi
ydinavikoitumisia, ja beetasoihtupäästöjä?)

---
Google translates it:

"SK22.05.2008. "Pollinators of complete depopulation threatens to take
the summer berries. Apple trees, and
Currants are blossoming in many places are already full, but the gardens
has been silent.
Pollinators are not moving. Warming weather does not permit relief,
as pollinators of wild stocks have plummeted nearly
Existent! are in danger in the forest berries, sielä such as
blueberries, lingonberry
and raspberry pollination is almost exclusively on bees for its revenue.
The treatment of bees Advice Ari Seppälä has mapped the situation of
pollinators
throughout Finland. News has been exclusively bad! -I estimate that
bees and bumble ampiaisia now has the highest one tenth of normal
levels.
Omenanviljelijällä familiar to them is tarhassaan one thousand kukivaa
wood. He is not
have seen this spring, the first kimalaista. Bumblebee and ampiaiset
suddenly disappeared from Finland in recent kesämä. Drop reason is not
known. Seppala
does not believe the situation to correct an even next summer! "

So I hardly need to continue? Drills have ylätuuleen trip TVO already
over
50km. And, as has been noted in 90% loss of the region always flower
flies lines is quite
wild. (Huvittavinta for that friend transmitter only a couple of viikoa
Then the information ydinaavikoitumisfaktasta, and KAS oivalteli! Not a
word about
the fact that Finland would have problems with bees. Ari thanks to the
net so
via Really! no other, the guy netit heard anger swells
Field comments from past virhetiedotuksista! The group would be a
discipline
along. ))) .. Nuclear power plant emissions to kill, therefore, been
said through Finland!
So, Shame else here in the past vedätelleet!

Although I try to pajunköyttää knows what "no doubt"
virus, mites, bakteri, mitälie tekaisua "established the so-Seppala
offsetting
this one's boots up suddenly announcing that the reasons it is smells!
Pori of only a few winter nest is jokusia mites and löytynmyt
bee numbers is still a mystery. Yeah .. .? Or, more correctly refers to
it,
that none of publicity for the disease deceptive spoof will not convince
anybody! Eli left
the remainder re Keran only those whom kuiskitaan doors.
Ydinionisaation caused suunnistuseksymiselle again tutusti pojot!
, Said ydinklingonit what wants! Strangely rebellion the field, even in
black,
something that is not attributable to the self-styled classic scams,
even if nuclear is the
a couple of years puukottanut? Maybe, but so that no lies
mehiläiskasvattajiin longer uoppoa, when online puhelevat knowledgeable
as a reason
ydinavikoitumisia, and the Torch of the beta release?)"

---
Maybe a bot, but, in any case, here's what tears me up about Finland:

http://www.youtube.com/watch?v=ATXV3DzKv68

Look at the old lady, camera center, at 6:36.

Why do you think she's crying?


JF

 

[Joerg]

Paul Carpenter wrote:

In article <MPG.23a72548c1ca82ce9896ee@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <MPG.23a76baff80d79d39896c7@172.16.0.1>,
paul@pcserviceselectronics.co.uk says...
In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.
...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John
Providing that you still have a computer that can read 5.25" disks.
Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.
Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..
No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).

There is no point archiving data that is in 90% of the time (or more)
anything other than plain text, without the tools to read it, even if
it is just to print out new copies.

Not so. I once was called to a new client. The new design wasn't what
they tasked me with (but that happened immediately after this initial
job ...). They were way behind schedule, trade show coming up, so the
only avenue to save the bacon was to gussy up an old system. A really,
really old one. So I plunged in. Later in the day I presented my
findings to the CTO. Found out that a math function was completely
"missing" on a board where it definitely should have been. "What?!!" He
turned pale. Now came the real issue. This board hadn't been touched in
a decade or so, the SW guy was long gone but we managed to find him in a
phone book. Whew! Next night he agreed to come in. Luckily he brought a
stone-age compiler and computer that was able to read in the source
code. The reason we couldn't read any of the archives was that it needed
to be done under CP/M. I almost couldn't believe it. If they hadn't
archived those ancient files the trade show would have been gone and the
CEO mad as hell.

Any archiving is for evaluations and possible modifications later, this
could be many years later, that you need to rebuild then modify code
for software, FPGA or even modelling of circuits or pcbs in electronic
form. In some cases it is to prove again that the design process is
modelled correctly or run scenarios on old simulators first.

Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be
If you're in a lifetime buy situation the tools don't matter,
however documentation still matters.

Yes they do as any part may have to be modified later and
progrrammable parts may need revised coding, even parts on wafer
need alternative packaging requirements for later batches that
then means a new PCB or even heatsink arrangements.

Boeing 747
C130 (Hercules in UK)
Nimrod (originally Comet airframe circa late 1950's)
Why single them out?

They were not singled out, but as it showed above "classic examples".
I could have used many others.

One classic I had about 5 years ago was for an NMR scanner, where
I was looking at replacing a failing part of it, and the EARLIEST
date they could find for the machine was

"...in 1968 it moved to the NEW building.."

ROFL! That is amazing.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

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

 

[John Larkin]

On Mon, 08 Dec 2008 08:51:05 -0800, Tim Wescott <tim@seemywebsite.com>
wrote:

John Larkin wrote:
On Sun, 07 Dec 2008 14:35:12 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:

On Sun, 07 Dec 2008 13:43:34 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Fri, 05 Dec 2008 17:25:32 -0800, John Larkin wrote:

On Fri, 5 Dec 2008 16:57:02 -0500, "asdf" <sadf@sdff.com> wrote:

Hi all,

Can anyone tell me the format behind "Revision/Release" notation? For
example: Rev. 1.30.35; which is so common in software (and some
hardware). Is it an arbitrary system? I've tried searching for it, but
come up empty handed. I've been able to query on this:

IEEE standard taxonomy for software engineering standards

but, I keep coming up with sites that want me to pay for the article.
Not to mention the fact that the above article will have way more
information that I'm looking for. I can't think of what else to search
on.

Any help?

Thanks,

Scott




The 4.00.02b notation is crap, and I can't see any patterns in actual
use.
It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.

But as soon as Marketing starts using them, they get pretty close to
crap...

As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.

A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.

Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!

We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.
_Any_ revision control system is only as good as the discipline and
integrity of the people running it.
It can be much worse, though.


If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap.
Only manufacturing builds and ships stuff. They get their docs only from
the company library. Stuff gets into the library only by formal release.
There are no sneak paths.
At your company, perhaps yes.

If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.

So I don't buy your assertions in the least.
Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing stuff,
and at some point marketing/management can't stand it any longer and
spins off a release.
At a poorly-run company, yes.

I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and firmware
included.

One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any given
hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.

This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.

John
So, let's change the venue, and reiterate what you're saying, and analyze
it's validity:

"Apples are picked in the next farm over from me, placed in wicker
baskets and hand carried to the farm stand. I buy them and they taste
delicious."

"Oranges are picked all the way over there in Florida, put into cardboard
crates along with sharp rocks, and are shipped by unsprung trucks on dirt
roads. Then they are tossed off of these trucks into my local
supermarket's produce aisle. I buy them and they are bruised up and
taste terrible."

"Therefore stuff that comes in crates is crap and stuff that comes in
wicker baskets is excellent."

Does that sound like your claim?

So I agree with your _evidence_, but I disagree with your _conclusion_.
You may as well say that because you paint your office blue that only
blue-painted offices can generate high quality work.

If you have a software code base that has more than a couple of dozen
source files and more than one developer, then you simply aren't going to
be able to adequately keep track of modifications with anything other
than a good version control system. The stack-o-floppies works for one
or two source files and one developer, but even then it works if and only
if discipline is exerted in the development and archiving process.

(Note that I _always_ use version control for all my client's projects,
even though I'm the only developer and some of my client's code bases are
only a few files).

Trying to maintain any sort of order in a software development effort
that has multiple source files and multiple developers _without_ a good
version control system is damn near impossible. If your source is
distributed between a dozen people and resides on multiple directories,
floppies, CDs, and memory sticks, then you'll never build the same thing
twice, and you'll never get a coherent handle on what you're doing.

I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.

What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.

We manage software the same way we manage hardware, with the same
revision control procedures, the same release procedures, the same
rules, the same numbering system.

Good for you. An old employer of mine that I still occasionally work
for treats mechanical design work as real engineering, electrical design
work as slightly mysterious real engineering, and software design work
as strange, wacky black magic that can only be done under the light of a
lunar eclipse with the aid of a freshly dead chicken.

Hence, when a mechanical guy has a preliminary design review everyone
shows up with the expectation that they'll understand what's said, when
an electrical guy has a design review everyone shows up with the
expectation that they'll understand what's said, and when a software guy
has a review only software people show up -- if you can drag them away
from coding long enough to do so.

Drives me up the wall.

We require that every shipped
product will be exactly reproducable and maintainable for decades.

Good for you.

Since disciplined hardware configuration management has been solidly
successful for 60 years or so, and is mandatory when lives and
gigabucks are involved, why not?

Thank goodness that most embedded product programs don't need an army
of programmers and a VCS to keep them under control.

The process that seems to work when you have "big" embedded software is
to use the VCS and the platoon (_not_ army) of developers to generate
release candidates, release the binary image through the same part
numbering system that you speak of, and keep the VCS up to date (through
discipline, again) in the background to insure reproducible code.

Part of this is done by never, ever, letting a developer submit a binary
image for release -- you go out and hire at least one person who knows
how to start a build, but doesn't want to play with the code. Their job
is to build and test software, and to kick the developer in the shins if
it doesn't build or test out. If they can't check code out of the VCS
into a virgin directory, build it and have it work, then the software is
broken -- with no allowance for the developer insisting on special
gyrations to make that particular build work.

VCS is OK with me (one of my guys uses one) as long as each formal
release is exported and released as a self-contained package of
sources, scripts, and tools, sufficient to do a full build without the
VCS.

Personally, I can control my revs and versions without one. Sometimes
we pass a file-ownership token between guys. It's a piece of wood with
TOKEN painted on.

John

 

[Paul Carpenter]

In article <C2k%k.6422$hc1.2452@flpi150.ffdc.sbc.com>,
notthisjoergsch@removethispacbell.net says...

Paul Carpenter wrote:
In article <MPG.23a72548c1ca82ce9896ee@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <MPG.23a76baff80d79d39896c7@172.16.0.1>,
paul@pcserviceselectronics.co.uk says...
In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.
...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John
Providing that you still have a computer that can read 5.25" disks.
Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.
Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..
No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).

There is no point archiving data that is in 90% of the time (or more)
anything other than plain text, without the tools to read it, even if
it is just to print out new copies.


Not so. I once was called to a new client. The new design wasn't what
they tasked me with (but that happened immediately after this initial
job ...). They were way behind schedule, trade show coming up, so the
only avenue to save the bacon was to gussy up an old system. A really,
really old one. So I plunged in. Later in the day I presented my
findings to the CTO. Found out that a math function was completely
"missing" on a board where it definitely should have been. "What?!!" He
turned pale. Now came the real issue. This board hadn't been touched in
a decade or so, the SW guy was long gone but we managed to find him in a
phone book. Whew! Next night he agreed to come in. Luckily he brought a
stone-age compiler and computer that was able to read in the source
code. The reason we couldn't read any of the archives was that it needed
to be done under CP/M. I almost couldn't believe it. If they hadn't
archived those ancient files the trade show would have been gone and the
CEO mad as hell.

Well actually if you think about you have proved my point, that the
customer was lucky that SOMEBODY had archived the tools and systems
otherwise the data was almost useless.


--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

 

[John Larkin]

On Mon, 08 Dec 2008 17:42:55 -0800, Joerg
<notthisjoergsch@removethispacbell.net> wrote:

Paul Carpenter wrote:
In article <MPG.23a72548c1ca82ce9896ee@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <MPG.23a76baff80d79d39896c7@172.16.0.1>,
paul@pcserviceselectronics.co.uk says...
In article <MPG.23a706ae1955768d9896ec@news.individual.net>,
krw@att.zzzzzzzzz says...
In article <8f4bbb1b-c188-4ede-b2de-
f406e934aaaa@r36g2000prf.googlegroups.com>, pomerado@hotmail.com
says...
On Dec 7, 11:46 am, John Larkin
jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux

j...@devereux.me.uk> wrote:
John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.
...
like that. It keeps things together.

Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.

John
Providing that you still have a computer that can read 5.25" disks.
Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.
Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..
No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).

There is no point archiving data that is in 90% of the time (or more)
anything other than plain text, without the tools to read it, even if
it is just to print out new copies.


Not so. I once was called to a new client. The new design wasn't what
they tasked me with (but that happened immediately after this initial
job ...). They were way behind schedule, trade show coming up, so the
only avenue to save the bacon was to gussy up an old system. A really,
really old one. So I plunged in. Later in the day I presented my
findings to the CTO. Found out that a math function was completely
"missing" on a board where it definitely should have been. "What?!!" He
turned pale. Now came the real issue. This board hadn't been touched in
a decade or so, the SW guy was long gone but we managed to find him in a
phone book. Whew! Next night he agreed to come in. Luckily he brought a
stone-age compiler and computer that was able to read in the source
code. The reason we couldn't read any of the archives was that it needed
to be done under CP/M. I almost couldn't believe it. If they hadn't
archived those ancient files the trade show would have been gone and the
CEO mad as hell.

We do archive tools to a server, which gets weekly backups. And we
rolled all our old DOS PADS jobs forward into the newer Windows format
before we retired the DOS machines.

We also release duplicate PDFs of drawings in proprietary formats, so
that anyone can see them, roughly forever.

John

 

[Otto J. Makela]

Ladies and gentlemen of sci.electronics.design, the message you are
replying to is a part of an ongoing campaign to disrupt the whole of
sfnet, the Finnish-language Usenet hierarchy, by means of cross-
posting Finnish-language garbage messages to other hierarchies.

Several bots are currently being run to try to remove these messages,
but unfortunately it is quicker to randomly generate than to find and
then remove messages.

The users of sfnet would much appreciate if you do not post followups
to these messages (specially cross-posting to the sfnet hierarchy),
the original garbage messages will be removed shortly. Thank you.
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * * * * * * * */
/* Phone: +358 40 765 5772, FAX: +358 42 7655772, ICBM: 60N 25E */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki, FINLAND */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * */

 

[D from BC]

On Mon, 8 Dec 2008 23:22:17 -0800, DaveC <me@bogusdomain.net> wrote:

This is a partial wiring diagram for an early 80's (West) German guillotine
paper cutter:

http://freefilehosting.net/show/42l0i

The goal of this circuit is to energize an electromagnetic clutch coil (m27)
that takes rotational energy from a flywheel to do a task (bring down the
knife blade). This circuit is currently not working.

This machine has no ICs. There are some monolithic rectifier bridges and
discrete transistors (the common symbol for which I cannot find *one* in the
diagram), and plenty of passives.

The transformer (m) primary center tap is connected to 24vdc. Do I interpret
this correctly that the primary is run by a switched dc voltage? (This on a
machine that runs on 3-phase 245vac.) Why?

I can say from experience that other machines of this same manufacturer use a
voltage derived directly from the 3-phase input to drive the electromagnetic
clutch. Why use a switched voltage, I cannot understand.

Is the triangle within a square symbol some sort of odd representation of a
transistor? And the "arrow thing" that feeds them? Ideas?

Help!

Thanks,

Alien technology from the planet
/\
/__\

Sorry, beats me...but it's interesting.

Wasn't there a single global schematic for the transistor in 1980??


D from BC
myrealaddress(at)comic(dot)com
British Columbia
Canada