How could this Hole Diameter and True Position problem have been Detected & Prevented

F

Frank T.

I have an issue I'm hoping fellow covers can give some guidance on how to correct this type of issue.

We manufactured a part, on a waterjet, that has a 0.281" diameter hole. The location of the hole should be at 3.7165" and 2.2441". The actual hole size is 0.2840" with a location of 3.7195" and 2.4435". As you can see the hole location of 2.2441" is out-of-spec. by approx. 0.1994". When I went back and checked the program used to manufacture this part the hole location was entered as 2.4410". The programmer acknowleged the numbers were accidentally entered incorrectly. When I checked the Inspection report for this part I discovered the same issue had occured, "dimension enter was 2.4410" instead of 2.2441". Both occurences resulted in the part being accepted.

I know the immediate correction would be to change the program and reverify that the dimensions meet the print (i.e. new FAI). The issue I have is how could this problem have been prevented/detected?

FYI, actual requirement is:
0.281" Diameter +/-.010"
True Position to be within 0.005" MMC relative to datum "C" MMC.
 
S

sjared

Re: How could this have been prevented/detected?

Would some type of assembly with mating parts prevented this situation? That is routinely part of our FAI process to act as an additional gut-check.
 
F

Frank T.

Re: How could this have been prevented/detected?

Would some type of assembly with mating parts prevented this situation? That is routinely part of our FAI process to act as an additional gut-check.

Assembly to the mating part is not an option we have.
 

Steve Prevette

Deming Disciple
Leader
Super Moderator
Re: How could this have been prevented/detected?

A good trick on data entry is to specify a check sum, the addition of all of the digits of the data entry.

For example, the check sum on 2.2441 is 13

The check sum on 2.441 is 11

If the specification for the data entry said "2.2441 check sum 13" and if the data entry screen calculated the check sum and displayed it, it would be caught.

Of course, this doesn't help much for transposition errors (right digits in the wrong place), but there are fancier check sum algorithms that could deal with that.

For example, when you enter your credit card number, there is some form of check sum routine, because the data entry forms "know" whether or not you've entered a valid card number.
 
Q

Qualgal

Re: How could this have been prevented/detected?

In our process, we check the 1st piece to the print before proceeding.
 
S

sjared

Re: How could this have been prevented/detected?

A good trick on data entry is to specify a check sum, the addition of all of the digits of the data entry.

For example, the check sum on 2.2441 is 13

The check sum on 2.441 is 11

If the specification for the data entry said "2.2441 check sum 13" and if the data entry screen calculated the check sum and displayed it, it would be caught.

Of course, this doesn't help much for transposition errors (right digits in the wrong place), but there are fancier check sum algorithms that could deal with that.

For example, when you enter your credit card number, there is some form of check sum routine, because the data entry forms "know" whether or not you've entered a valid card number.

That's an interesting idea, but does it work when there is a range of acceptable values like a dimension with a tolerance?

The check sum for 2.443 is also 13, but is almost .2" from 2.2441
 

Steve Prevette

Deming Disciple
Leader
Super Moderator
Re: How could this have been prevented/detected?

Checksum isn't perfect. But you are basically trying to collapse a number down to a smaller value for an easy check. If there error is "random" it is likely to catch it.

I would assume with tolerances you enter the center value and the allowed error (two different data entries with two different check sums) or you enter the high and low values (again, two data entries, two different check sums).

Googling around, I found this artilce:

http://mcom.cit.ie/staff/computing/cmanning/pod/ISWD24.pdf

It shows some fairly sophisticated examples, such as one for credit card data entry.
 
Q

Qualgal

Re: How could this have been prevented/detected?

Measure it to the print. We always measure the 1st piece prior to proceeding. Depending on the hardness of the material or the variance of the stock, our programs may have to be adjusted.
 
F

Frank T.

Re: How could this have been prevented/detected?

Measure it to the print. We always measure the 1st piece prior to proceeding. Depending on the hardness of the material or the variance of the stock, our programs may have to be adjusted.

The part was measured to print but the number 2.2441 was transposed as 2.441.

A good trick on data entry is to specify a check sum, the addition of all of the digits of the data entry.

For example, the check sum on 2.2441 is 13

The check sum on 2.441 is 11

If the specification for the data entry said "2.2441 check sum 13" and if the data entry screen calculated the check sum and displayed it, it would be caught.

Of course, this doesn't help much for transposition errors (right digits in the wrong place), but there are fancier check sum algorithms that could deal with that.

For example, when you enter your credit card number, there is some form of check sum routine, because the data entry forms "know" whether or not you've entered a valid card number.

This is a niffty thought. The only dilemma is as sjared mentioned, what if the incorrect values added to the checksum value, or if numbers were transposed.
 
Last edited by a moderator:
Top Bottom