Brad is right. In Oz and NZ and possibly some other places there are many
PCB makers that are happy to receive PCB files. Some of them take it in a
number of formats (not just Protel, but this is the dominant one).
In some cases the PCB makers prefer it in the native format as they can
then optimise for their process, thought patterns and phase of moon.
I am always nervous about doing it and usually send gerbers. I have heard,
though, that many gerbers that PCB makers receive are pretty poorly
generated and this step is a source of confusion and bad boards for those
new to this game. So the PCB makers here feel they can give better boards
to their clients by accepting PCB files.
Users then have to trust that the PCB maker doesn't make changes that
affect the working of the design (which they can do with gerber anyway) and
that they are comfortable with releasing all that IP. (This is one of the
reasons I wrote my little IP stripping script.).
Seems like reasonable service to me - offer something extra to the client
so they don't have to do a step that many find fraught with problems. In my
case though I don't like releasing all that IP and I am pretty comfortable
with releasing and checking gerbers so I almost always go this path - the
last time I released a native PCB file would have been years ago -
certainly when P99SE was pervasive.
With the newer file formats, with their non-backwards compatible features,
it is a risk I certainly no longer take. I would hate to try to manage the
risk of a critical entity being dropped.
I have been on a bit of a one man crusade to try to get the PCB makers here
to support some more intelligent formats like ODB++ for some time now.
The difference between a native file fully supported by a PCB maker and an
intelligent interchange format (ODB++) or even a full set of gerbers,
netlist and drill file is pretty small really in terms of their ability to
be messed up by a poor PCB maker. Or their IP content for that matter.
(Reduced releases like just gerber and drill do provide some masking but
hands up those that have *not* reverse engineered a design from
gerber/actual PCB?)
I think the issue of PCB file being more dangerous in terms of being
hacked/edited by the PCB maker is a little wide of the mark. Most CAM
systems these days effectively reconstruct the full board and changes can
just as easily be done within them (make traces smaller, move this, add
copper balancing ...). The bigger issue for me is controlling the release
of the IP - which will become an increasing issue with things like ODB++
where descriptive net names can add quite a bit of intelligence to a
manufacturing pack. I will be continuing to update my IP removal script
(not for P99SE though I am afraid) to try to balance the manufacturing pack
intelligence at different points of release with the benefits in providing
smarter export files (a PCB maker can use a netlist for electrical check
but the net names can be NET1, NET2, .....). A contract board assembler
doesn't need the netlist but does require (effectively) the parts list
(possibly somewhat masked if you provide the kit) but they have so much IP
at this point that you will have to be operating on a trust basis anyway -
so the release of a native file at this point of the process is something
of a moot point IMO.
Certainly if you are chasing cheapest PCB pricing by regularly changing PCB
makers, then some industry standard manufacturing pack is the only way to
go practically.
Ian
On 06:09 AM 6/09/2005, Brad Velander said:
Terry (?),
From what we have heard over the years, this is an Oz phenomenon.
Seems in Oz most of the fabricators have Protel in-house and can
tweak things themselves. Maybe historically they have had too many
designers that were screwing up the Gerber/Drill fab output so the
fabricators started doing it themselves. Or was it actual
design/fabrication issues that they needed to tweak, who knows?
Recently, this seems to be becoming more of an issue. Since by
the number of posts there seems to be one or more of these fabricators
that are not upgrading their software to DXP. Thus the slow but steady
flow of questions about converting back to P99Se for their fabricators.
Hope the designers aren't using any of the new features that don't
transfer back to 99SE. That could be a disaster.
I am with you though Tony, all other issues considered, once you
turn over the database you have no control over what you are actually
getting. The board may be great one time from one fabricator, turn it
over to another fabricator and get a different flavour altogether.
Sincerely,
Brad Velander
Senior PCB Designer
Northern Airborne Technology
#14 - 1925 Kirschner Road,
Kelowna, BC, V1Y 4N7.
tel (250) 763-2329 ext. 225
fax (250) 762-3374
-----Original Message-----
From: TDK [mailto:[EMAIL PROTECTED]
Sent: Monday, September 05, 2005 7:16 AM
To: [EMAIL PROTECTED]; 'Protel EDA Discussion List'
Subject: RE: [PEDA] Protel2004 into 99SE
You are right. They don't need the native data base.
Regards
TDK
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Tony Karavidas
Sent: Monday, September 05, 2005 1:05 AM
To: 'Protel EDA Discussion List'
Subject: RE: [PEDA] Protel2004 into 99SE
What is with people using fabricators who require the native database? Why
do they need anything besides the gerber files and a drill file?? I've asked
this question before, but I don't recall anyone giving a reasonable
explanation. I would never use a fabricator who requires my Altium files. I
actually don't even give my assembly house access to the programmable
devices. If I did, I would probably be selling more stuff in China and not
even getting any money for it.
Tony
____________________________________________________________
You are subscribed to the PEDA discussion forum
To Post messages:
mailto:[email protected]
Unsubscribe and Other Options:
http://techservinc.com/mailman/listinfo/peda_techservinc.com
Browse or Search Old Archives (2001-2004):
http://www.mail-archive.com/[email protected]
Browse or Search Current Archives (2004-Current):
http://www.mail-archive.com/[email protected]
