If you want to read more about GenCAM take a look at these websites:
http://www.gencam.org/html/standards/standards.html
http://www.fis.marc.gatech.edu/gencam/
and if you want to read a lot more, ask Google to show you the way towards
"GenCAM".
The latest information indicates that GenCAM is going to be merged into
ODB++. All I can hope for is that my preferences for GenCAM are going to
survive this merger and hopefully this whole thing will be "controlled" by
IPC.
Regards, Ahne.
-----Original Message-----
From: TechNet [mailto:[log in to unmask]]On Behalf Of Seth Goodman
Sent: Thursday, January 31, 2002 15:54
To: [log in to unmask]
Subject: Re: [TN] ODB++
Gary,
Thanks so much for adding the GenCAM part of the story. Here are a couple
of questions concerning the points you made:
> Today, with intelligent data such as ODB++ and IPC's GenCAM we are
facing the same issues.
> Yes, IPC has again provided a compliance test module to verify the
output/input of GenCAM data.
> Yes, some of the output software is being offered for free. Yes,
companies are offering tooling
> discounts for intelligent data files. And yes many companies are using
either of the two formats.
Could you pass on information as to who is offering free output
software? Also, I would like to know about fabrication shops that offer
discounts for use of intelligent tooling. When you say many companies are
using either format, are you talking about fabrication shops?
> Will either format take 100% market share? No! The fact remains that
there will be followers of
> both formats, followers of new formats, and then a large group that will
do nothing but sit around
> and wait for who knows what to happen.
This is the real tragedy. Right now, all fabrication shops accept
Gerber, as far as I know. The more different intelligent formats we
standardize, the more expensive and complicated the software for the fab
shops will become since they will be forced to deal with multiple formats.
That will eat up much or all of the possible savings the smart format was
intended to provide. Consider that a CAM engineer at the fab shop will have
to be conversant in each format as well as be familiar with the bugs, tricks
and workarounds for each format on his/her importing software. IMHO, one
new format would be a boon to the industry, while several new formats would
be a drain on resources. In that case, we may be better off turning RS-274X
into a real standard and create a validation suite for it. I can't believe
I just suggested that in public, but it's better than dealing with a Tower
of Babel due to multiple standards.
Another issue that I've heard bandied about is the possible merging of
ODB++ and GenCAM. Can't recall where I heard this, but it is an interesting
idea. Is this rumor correct and if so, what is the status of that effort?
We can look at the personal computer industry and see examples of how
single and multiple standard solutions fared. In the early 1980's, IBM
released the workings of the ISA bus. Though their information was not
totally complete and there was no validation mechanism that I remember, it
wasn't too hard to fill in the blanks and it became the de facto standard
for about 10 years. Even after the initial period of heavy use, motherboard
and software vendors were compelled to provide backward compatibility for
this standard. Toward the end of the useful life of the ISA bus, it became
a bottleneck for increased performance and there was a huge amount of
pressure to come up with an alternative. A number of companies extended the
ISA architecture and released the EISA standard. About the same time, the
industry formed the VESA consortium and came up with an architecture that
gave better access to the processor local bus. Also around the same time,
IBM released the MicroChannel Architecture because, well, they were IBM.
Despite their technical superiority to ISA, none of these solutions lasted
more than a couple of years.
Enter the PCI special interest group who took the best of MicroChannel,
VESA and EISA and came up with an extensible bus architecture that served
the industry well up through the present. By the time it is superceded, the
PCI bus will have been useful for about 10 years. If you look at the period
when ISA, EISA, VESA and MicroChannel coexisted, progress in the industry
was stymied by the multiple standards. Both hardware and software companies
were hamstrung and tried to hedge their bets by producing the same product
on multiple bus platforms. In contrast, during both the stable ISA years
and the stable PCI years, technical advancements and total sales took off.
Everyone could work efficiently as there was a single hardware platform and
the market for every product was larger due to the single standard. The
software situation was not as good because a single company controlled the
de facto standard. This is not inherently bad, but due to their mindset and
the lack of broader industry control, they made frequent, undocumented
changes to their interfaces and tools that made software development a very
expensive endeavor. Those with limited resources were slowed to a crawl or
eliminated.
There's a lot we can learn from this.
1) It is to our mutual advantage to select a single standard, even if it
is not optimal. Having several similar competing solutions will slow down
industry progress. IMHO, we will do better with a single mediocre standard
than several more advanced but competing approaches.
2) It is dangerous to have a single company in a position to control the
standard. If their market share is great enough, they could, like
Microsoft, participate in industry standards efforts and sign off on the
results (i.e. HTML, Java), then go ahead and violate the standard so
competing products were not interoperable. If the standards were not
controlled by a couple of players who had large competitive axes to grind,
this probably wouldn't have happened. This is not meant as a criticism of
Valor and does not discourage ODB++ from becoming the new standard. It does
have implications as to how the new standard should be managed.
Regards,
Seth Goodman
Goodman Associates, LLC
tel 608.833.9933
fax 608.833.9966