| 
	
 | 
 Posted by Thomas Bihn on 12/22/05 07:45 
Thanks for the additional replies.  
 
I realize this has got to be an unusual occurrence. This particular 
product is an RF transmitter that has the seven serial numbers 
programmed into the microcontroller EEPROM at the programmer station at 
the same time. To avoid violating NDA with the customer, suffice it to 
say that these are serials for multiple companies products.  
 
The reason for a board ID is not so much for this particular product but 
does come in useful if we want to cross reference a particular serial 
number and what other serial numbers were assigned to that board. It 
serves as a common tie to all the serial numbers assigned to a board. I 
had originally concepted simply tracking the singular serial number 
through the process, primarily test and packout and RMAs, but we have 
some "boards" that actually are more accurately referred to as 
"assemblies" with sub-assemblies, each with their own serial numbers. 
The original concept I had was to identify a "primary serial number" to 
which secondary serial numbers would be assigned. The problem with this 
was that when other engineer's go to implement this, or more 
importantly, if an operator is prompted to scan the serials at a testing 
station, you have to add all sorts of validations to ensure the proper 
serial number is scanned. We have so many different variations from a 
wide array of customers that I decided it would be easier to go with the 
board ID. It also will help to implement some form of tracking for 
boards that actually have no serial number assigned to them. 
 
Additionally, the current method of barcoding for one of our customers 
has us using multiple pieces of information within the barcode. If it 
comes back as an RMA for a software update or kludge (in electronics, 
this can involve adding jumper wires, piggy backing FETs, etc), we have 
been scanning in the old barcode to retreive the serial number part and 
printing out a completely new barcode with the same serial part. The 
problem with this method is a new label is printed (cost) and the 
operator has to remove the old label, clean the board, and apply the new 
one (additional handling = bad). Hopefully, I'll be able to get this 
practice stopped sooner than later and allow the tracking and validation 
of proper RMA handling to occur by tracking the board in the database by 
whatever serial number is scanned. Eventually, I'd like to see the 
practice of encoding so much information in the barcode ended and 
utilizing the serial number barcode as a unique assembly identifier and 
that only. This is a greatly condensed description of what we are trying 
to accomplish here, but hopefully sheds some light on the logic of the 
seperation between serial number ID and board ID. 
 
As a side, we also do complete box builds of an assembly that has as 
many as three circuit boards (each with their own serial number), our 
company's unique identifier for the assembly, and as many as three 
stinking serials on the outside of the assembly as mandated by our 
customer that we are building the assembly for and the end-customer 
where we are shipping them.  
 
For this particular product, which is very unique from the others, I am 
thinking of adding a table, call it Type_4_Order that has: 
 
PK Type_4_Order_ID bigint Identity 
Board_ID  
Serial_Number_ID -- From the Serial_Numbers_Generated table 
Serial_Number_Position -- 1,2, or 3 
 
I will be able to then create a two column SELECT resultset with 
Board_ID, Serial_Number_ID for each of the ordinal positions. With this 
resultset, I'll Inner Join with the other nested SELECT statements 
returning their individual results.  
 
I know this may look ugly to many of you, but  you should see the Access 
databases we are using for much of the manufacturing end of our company. 
Our IS department is directed towards business applications by 
management and we in engineering and maunfacturing are left to our own 
devices.  
 
Any additional comments/suggestions are welcome. 
 
Thanks again. 
 
 
 
 
*** Sent via Developersdex http://www.developersdex.com ***
 
  
Navigation:
[Reply to this message] 
 |