TECHNET Archives

June 2016

TechNet@IPC.ORG

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ken Barton <[log in to unmask]>
Reply To:
TechNet E-Mail Forum <[log in to unmask]>, Ken Barton <[log in to unmask]>
Date:
Wed, 1 Jun 2016 20:28:50 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (119 lines)
Thanks to all for the quick response. I do know what I'm going to push for in this process, most decidedly Company PNs. I wanted to see arguments against, and for how this MRP setup can work, it pulls all mechanical & electrical together & has the proper modules in place for the modeling & electrical tools, EBOMs, in place. Linking to data sheets in place. The CAD admins are also willing to set up any CIS attribute necessary, and have stated that MFR sub numbers are not a problem. This is long term classification & tracking.

We have lots of folks here that react like, what's the point, we did it, we can do it again, but they are not the ones having to take CCAs down to the lab to fix. Even the CAD admins reacted like, wow, that's a lot of "work". That's why I'm here, it's a lot of "making sure CCAs come back as intended due to an efficient process".

Ken Barton
Technical Designer, 
Vehicles & GSE/
Avionics HW

Blue Origin, LLC
21218 76th Avenue S.
Kent, WA 98032
(253) 437-5625 x625
[log in to unmask]


-----Original Message-----
From: TechNet [mailto:[log in to unmask]] On Behalf Of Joyce Koo
Sent: Wednesday, June 01, 2016 1:08 PM
To: [log in to unmask]
Subject: [Possible Spam] Re: [TN] Part numbering, MRPs & reality
Importance: Low

The beauty of assign your own P/N is control the device change (ex. die shrink parts with form fit function all the same, you use std p/n would be no change... you would not have traceability after the assembly, except date code at assembly).  your own P/N you can add dash to control that- just in case the die shrink causes reliability variation... Change location of MFG is another... dash or OEM P/N will catch that.  if you only use common MRP, you might missing some detail that is critical for end of life prediction for example.
my 2 cents.  (the data is so cheap, if you set up properly, few more link would save the day sometime down to the road).
    jk
> June 1, 2016
>
> Although I recognize that some OEMs assign their own unique part 
> numbers to EEE parts but I am not in favor of doing this because it 
> complicates things and makes it difficult if you are using the drawing 
> or separate parts list for a competitive bid situation.  For example, 
> if a semiconductor is being purchased as JANTX XXXXXX per 
> MIL-PRF-19500/XXX, with a detailed description of the part in the 
> drawing remarks column, this is normally sufficient for ordering the 
> part using the MRP electronic system.
> However,
> if only the OEMs P/N XXXXXX is listed, then this normally requires a 
> detailed drawing or parts card to capture the part ordering information.
> Using an OEM number makes it difficult to search to determine if a 
> suspect counterfeit part may have been used on an assembly unless 
> there is an electronic method to translate the OEMs part number to the 
> military specification part number.  I also believe that the practice 
> may violate standard drawing practices.  Normally, per standard 
> drawing practices, OEM documents can be  listed as references along with the base requirement.
> As
> example, Solder per J-STD-001 Class 3 [OEM XXXXX] where the OEM XXXXX 
> is the local OEM procedure that implements the soldering requirements.  
> If the BOM includes both the OMs part numbers and the generic part 
> numbers such as the military part numbers, this may be an acceptable 
> practice. Normally, detail or source control drawings for an EEE part 
> are not needed unless the part cannot be purchased without invoking 
> additional requirements via a detail or source control drawing.
>
> On Wed, Jun 1, 2016 at 12:02 PM, Ken Barton <[log in to unmask]>
> wrote:
>
>> Greetings TechNet gurus,
>>
>> Just arrived at my present employer charged with creating process for 
>> PCB/CCA libraries. We have a turnkey layout vendor, this relationship 
>> is somewhat problematic: Wrong footprints & component subs. We have 
>> absolutely no correlation with Orcad CIS & our MRP/ECAD system. All 
>> board components are using vendor PNs. So, I want to toss this out to 
>> all for a reality
>> check: My experience over a wide range of OEMs I have worked for is 
>> to issue each component a "Company" 10 digit PN. All critical 
>> attributes will be entered & fall into CIS explorer. The MRP/ECAD we 
>> have has all capability for handling the mechanical AND electrical 
>> assy structures.
>> As
>> my employer is the first time I have seen vendor PNs go on EBOMs & 
>> released out into the wild, I've been informed that other huge 
>> companies have done the same.
>>
>> Am I just an old guy using the "We always do it this way, it works?" 
>> I am willing to hear the pros & cons, has anybody else been in the 
>> middle of this?
>>
>> Ken Barton
>> Technical Designer,
>> Vehicles & GSE/
>> Avionics HW
>>
>> Blue Origin, LLC
>> 21218 76th Avenue S.
>> Kent, WA 98032
>> (253) 437-5625 x625
>> [log in to unmask]<mailto:[log in to unmask]>
>>
>>
>>
>> _____________________________________________________________________
>> _ This email has been scanned by the Symantec Email Security.cloud 
>> service.
>> For more information please contact helpdesk at x2960 or 
>> [log in to unmask] 
>> _____________________________________________________________________
>> _
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please contact helpdesk at x2960 or 
> [log in to unmask] 
> ______________________________________________________________________
>


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please contact helpdesk at x2960 or [log in to unmask] 
______________________________________________________________________

ATOM RSS1 RSS2