----- Original Message -----
From: "JaMi Smith" <[EMAIL PROTECTED]>
To: "Protel EDA Forum" <[EMAIL PROTECTED]>
Cc: "JaMi Smith" <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 8:52 PM
Subject: Re: [PEDA] Placement Data


 ----- Original Message -----
> From: "John A. Ross [Design]" <[EMAIL PROTECTED]>
> To: "Protel EDA Forum" <[EMAIL PROTECTED]>
> Sent: Monday, September 16, 2002 5:31 AM
> Subject: Re: [PEDA] Placement Data
> > ----- Original Message -----
> > From: "JaMi Smith" <[EMAIL PROTECTED]>
> > To: "Protel EDA Forum" <[EMAIL PROTECTED]>
> > Cc: "JaMi Smith" <[EMAIL PROTECTED]>
> > Sent: Saturday, September 14, 2002 10:51 PM
> > Subject: Re: [PEDA] Placement Data
> >
> >
> > Hi JaMi
> >
> > > You bring up many many valid points, but I would say that the vast
> > majority
> > > of them aside from the issue of "orientation" (or "rotation") fall
into
> > the
> > > category of "machine dependant setup and fine tuning", as opposed to
> > > "required engineering data".
> >
> > I disagree on this, as the 'originator' of the data it is MY
> responsibility
> > to remove the areas where error can occur.
> >
>
> I agree totally with the responsibility part respecting giving him all of
> the necessary (and valid) data to build the board, but it is not your
> responsibility to tell him how to run the machine.

Dear JaMi,

With regards to DFM and other issues regarding the manufacturing costs &
budgets and what savings and/or benifets can be gained, you need to know
what the machine can do, capability wise, as well as the line as a whole.
For small(ish) runs you can skip a lot, for cost sensitive consumer products
it makes a difference.

Sorry if it sounded like I would go and set it up for them, I would not,
although I have completed all the user courses for all the machines we use
here/or off site.

But I still feel I am better enabled with that knowledge, and apply design
rules (technical or cost oreientated) accordingly because of this.

It takes me less time to prepare this data for them (in a presentable state)
to the machine programming s/w than it does for the production guys as I am
more familiar with the product than them.

> > At the moment for 3rd party houses I need to document all the parts in
the
> > BOM and merge it with the PP data. If I had these fields available, I
> could
> > simply 'export' with the PP file in one process within Protel.
> >
>
> Granted he needs an assembly drawing and parts list, but you can give him
> that seperately.
>
> The point here is that being able to "merge" all of that data into the P&P
> file would be a nice conveinence, and it would be nice to have. But
putting
> "roataion" data in the P&P file that is invalad or bogus, is just simply
an
> ERROR, and it needs to be FIXED.

JaMi, I think this is where we differ or are getting our lines crossed, ALL
my libraries are designed so that the rotation MATCHES the orientations of
the machines. I do not have an issues with that at all. I maintain single
libraries and strict library control (a good practice anyway) for each site.

The bogus rotations come from either using standard lib parts from Protel,
or NOT knowing the machine requirements in the first place when creating the
lib parts.

Only issue I really have, covered before, is that a non-polarised 0603 part
might be placed at 0 or 180 deg for route reasons. But for placement that
means a single operations placement (0 deg) and a two operation placement
(rotate 180 then place) and in the case of turret or linked heads that could
mean rotating up to 20 heads at the same time, so you lose some of the
benifets of multi-pick.

> The other is a real problem with delivering VALID required engineering
data.

I have a documentation profile for all sites we have, built up the hard way,
so I do not get bogged down with questions after release. I hate to travel,
especially with my butt in an Aircraft for 8 hrs plus, because I have not
went that extra mile, or have to overcome the language barrier because a
small file or feild is missing.

> While there is much to be said regarding everyones different philosophy
over
> just who is responsibile for what, and just how far you can trust things,
> etc., etc., etc., all of this has little to do with the fact tha tthe
> current P&P files generated by P99SE and DXP have BOGUS "rotation" data,
and
> this needs to be fixed.

The rotation data is not bogus if the libraries are correctly maintained and
built up with the placement machines in mind.

If the library feilds were available within the PP file, in a format like
the BOM generator in SCH, you could then assign feilds on a machine basis
for rotations, which would let me maintain ONE master library.

I know I am not alone in this wish. It does save time ($$$) as well as
streamline processes and remove the possibility of error by manual data
modifications.


Best Regards

John A. Ross

RSD Communications Ltd
8 BorrowMeadow Road, Springkerse Industrial Estate
Stirling, Scotland FK7 7UW

Tel (Office)  +44 [0]1786 450572 Ext 225
Tel ( Lab  )  +44 [0]1786 450572 Ext 248
Fax              +44 [0]1786 474653
GSM           +44 [0]7831 373727

Email        [EMAIL PROTECTED]
WWW     http://www.rsd.tv
==========================================


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to