프로세스 스크리닝 플랫폼에 대한 사양 한계안녕하세요 여러분,
프로세스 스크리닝 애플리케이션의 사양 한계에 대한 질문이 있습니다. 예를 들어, 부품 두께에 대한 메트릭이 있습니다. 목표는 0.7이고 하한은 0.6, 상한은 0.8입니다. 이러한 한계 내에 있는 모든 것은 통과합니다. 그러나 아래 플롯에서 볼 수 있듯이 0.8의 값은 실패로 계산됩니다. 동시에 0.6은 통과로 포함됩니다.
제한이 포괄적인지 배타적인지 제어할 방법이 있습니까? 환경 설정 탭 내의 설정인가요 아니면 케이스별로 프로세스 스크리닝 플랫폼 내에서 수행할 수 있습니까?
현재 JMP 16을 사용하고 있지만 곧 18로 전환할 수도 있으므로 각 버전에 대한 제안이 있으면 감사하겠습니다.
기본 데이터 분석 및 모델링품질 및 공정 엔지니어링윈도우Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계값이 정확히 0.8인지 확신하십니까? 이 간단한 예에서는 어떤 값도 실패로 간주되지 않습니다(저는 JMP18을 사용하고 있으므로 아마도 이것이 바뀌었을 것입니다)
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계안녕하세요 @AdditiveRange10
데이터가 미친 듯이 작은 소수점을 가지고 있는지 확인해 보세요. 이상한 가져오기 문제가 있는 데이터 세트가 들어와서 역량 분석이 엉망이 된 적이 있습니다. Round(dt:col,2)를 사용해 제거해 보세요.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계아니요, 값은 이미 반올림되었기 때문에 작은 소수는 없습니다.
저는 JMP 16에서 프로세스 스크리닝 플랫폼을 사용하여 분석을 실행했고, 제가 위에서 언급한 대로 0.80000인 값은 실패로 계산됩니다. 하지만 JMP 18에서 프로세스 역량 플랫폼을 사용하면 다음과 같은 결과가 나옵니다. 0.6-0.8 내에 있는 모든 포인트를 선택하면 93/107 = 87%가 나오는데, 이는 분석에서 표시된 합격률입니다.
여전히 히스토그램이 시각적으로 오해의 소지가 있고 [0.8-0.9) 빈이 USL 밖에 있는 것 같다는 의문이 남습니다. 이를 변경하는 방법에 대한 제안이 있습니까? 손 도구가 유용할 수 있지만 많은 메트릭에 대한 분석을 스크립팅하는 데는 좋은 옵션이 아닌 것 같습니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계손 도구를 사용하면 Bin Span을 변경할 수 있으며 스크립팅도 가능하지만 이해하는 데 약간의 시간이 필요할 수 있습니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계안녕하세요 @AdditiveRange10
어쩌면 이 둘 사이에 거기까지 갈 수 있을지도
올바른 차트에 할당하려면 xpath 위치를 사용해야 할 수도 있습니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계사양을 포함/배타적으로 설정할 수 없습니다. 측정값이 이산적인 것 같으므로 LSL을 약간 낮게(예: 0.599) 설정하고 USL을 약간 높게(예: 0.801) 설정할 것입니다. JMP 16에 대해서는 잘 모르겠지만 JMP 18에서는 측정값 = 사양이 사양에서 고려되지만 부동 소수점 값을 비교하는 것은 부정확한 표현으로 인해 문제가 될 때가 있습니다. 부동 소수점의 경우 == 대신 > 또는 < 비교를 하는 것이 항상 더 좋습니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계음, 방금 다른 걸 시도해 봤습니다. 프로세스 역량 플랫폼을 사용해서 동일한 사양 한계 LSL = 0.6, Target = 0.7, USL = 0.8을 갖는 10개의 데이터 포인트를 플로팅했습니다. 데이터에 따르면 0.9 또는 1인 포인트가 3개 있습니다. 사양 한계를 수동으로 입력하면 불일치율이 30%, 즉 3/10이 나옵니다.
하지만 데이터 테이블과 함께 수입 사양 한계를 사용하면 불일치율 60%, 즉 6/10이 나옵니다. 이는 LSL 열 속성의 유형 때문일 수 있을까요? "최상" 형식의 연속 숫자 열이고 너비가 12입니다. 너비를 변경하고 다시 계산해 보았지만 차이가 없습니다.
다시 말해서, 저는 여러 변수에 대한 분석을 하고 있고 개별적으로 입력할 수 없기 때문에 테이블에서 LSL 및 USL 값을 사용한다는 점이 요점입니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계네, 이는 두 개의 부동 소수점 값을 비교하는 데 있어 정밀도 문제가 있다는 것을 확인합니다. 위에서 설명한 방법으로 이를 피하는 것이 가장 좋습니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계그러니까 프로세스 역량이나 프로세스 스크리닝 플랜폼을 사용하지 말라고 제안하시는 건가요? 스펙 테이블은 파이썬 스크립트를 사용해서 생성했기 때문에 거기서 포맷팅을 자유롭게 할 수 있는 거죠? 특별히 제안하실 게 있나요?
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계부동 소수점 값을 비교하는 부정확성을 고려하기 위해 사양을 가드 밴딩하는 것이 좋습니다. float64(이중 정밀도 부동 소수점 숫자)는 약 15-17자리의 소수점 정밀도로 실수를 표현할 수 있습니다. 즉, 매우 광범위한 숫자를 표현할 수 있지만 이진 표현의 한계로 인해 마지막 소수점 몇 자리는 약간의 부정확성이 있습니다. 기본적으로 대부분의 실수는 float64로만 근사화할 수 있으며 정확히 표현할 수 없습니다.
이는 가드 밴드가 최소한 1e-15이어야 함을 의미합니다.
Re: 프로세스 스크리닝 플랫폼에 대한 사양 한계저는 Python 스크립트로 돌아가서 spec 목록의 모든 float 값을 float64에서 float16으로 변경했습니다. 프로세스 화면 플랫폼을 사용하고 spec 테이블에서 가져온 spec 제한을 사용하면 spec을 벗어난 값이 올바르게 계산되는 것 같습니다. 이것이 이 문제에 대한 현재 해결 방법일 수 있습니다.
