Límites de especificaciones para la plataforma de detección de procesosHola a todos,
Tengo una pregunta sobre los límites de especificación en aplicaciones de detección de procesos. Por ejemplo, tengo una métrica para el espesor de una pieza. El objetivo es 0,7 con un límite inferior de 0,6 y un límite superior de 0,8. Todo lo que esté dentro de estos límites inclusive pasará la prueba. Sin embargo, como se muestra en el gráfico a continuación, los valores de 0,8 se cuentan como reprobados. Al mismo tiempo, los valores de 0,6 se incluyen como aprobados.
¿Hay alguna manera de controlar si los límites son inclusivos o exclusivos? ¿Se trata de una configuración dentro de la pestaña de preferencias o se puede realizar dentro de la plataforma de evaluación de procesos caso por caso?
Actualmente estoy usando JMP 16, pero es posible que pase pronto a 18, por lo que cualquier sugerencia para cada versión será apreciada.
Análisis y modelado de datos básicosIngeniería de Calidad y ProcesosVentanasRe: Límites de especificaciones para la plataforma de detección de procesos¿Está seguro de que los valores son exactamente 0,8? En este ejemplo simple, ningún valor se considera fallido (aunque estoy usando JMP18, por lo que tal vez esto haya cambiado)
Re: Límites de especificaciones para la plataforma de detección de procesosHola @AdditiveRange10
Intente comprobar si sus datos tienen un decimal demasiado pequeño. He tenido conjuntos de datos que presentaban problemas de importación extraños que conducían a un decimal demasiado pequeño que alteraba mi análisis de capacidad. Puede probar Round(dt:col,2) para deshacerse de él.
Re: Límites de especificaciones para la plataforma de detección de procesosNo, definitivamente los valores han sido redondeados antes por lo que no hay decimales pequeños.
Realicé el análisis utilizando la plataforma de detección de procesos en JMP 16 y es como indiqué anteriormente y los valores que son 0,80000 se cuentan como reprobados. Sin embargo, en JMP 18, utilizando la plataforma de capacidad de proceso, obtengo esto. Al seleccionar todos los puntos que están incluidos dentro de 0,6-0,8, obtengo 93/107 = 87 %, que es la tasa de aprobación como se muestra en el análisis.
Aún queda la duda de que visualmente el histograma parece engañoso con el intervalo [0,8-0,9) que parece estar fuera del límite superior de la escala. ¿Tiene alguna sugerencia sobre cómo cambiar eso? Sé que la herramienta de mano puede ser útil, pero no parece una buena opción para crear un análisis para muchas métricas.
Re: Límites de especificaciones para la plataforma de detección de procesosCon la herramienta manual puedes cambiar Bin Span y deberías poder programarlo, pero es posible que requieras algo de conocimiento.
Re: Límites de especificaciones para la plataforma de detección de procesosHola @AdditiveRange10
Quizás entre estos dos puedas llegar allí
Es posible que sea necesario utilizar la ubicación xpath para asignarlo al gráfico correcto.
Re: Límites de especificaciones para la plataforma de detección de procesosNo es posible configurar las especificaciones como inclusivas o exclusivas. Parece que las mediciones son discretas, por lo que establecería un LSL ligeramente inferior (p. ej., 0,599) y un USL ligeramente superior (p. ej., 0,801). No estoy seguro de JMP 16, pero en JMP 18 veo que las mediciones = especificaciones se consideran en la especificación, pero la comparación de valores de punto flotante a veces es problemática debido a la representación imprecisa. Siempre es mejor hacer comparaciones > o < en lugar de == para los flotantes.
Re: Límites de especificaciones para la plataforma de detección de procesosHmm, acabo de probar algo diferente. Usé la plataforma de capacidad de proceso y grafiqué 10 puntos de datos con los mismos límites de especificación LSL = 0,6, Target = 0,7 y USL = 0,8. Según los datos, hay 3 puntos que son 0,9 o 1. Si escribo los límites de especificación manualmente, obtengo una tasa de incumplimiento del 30 %, es decir, 3/10.
Sin embargo, si utilizo los límites de especificación de importación con una tabla de datos, obtengo una tasa de incumplimiento del 60 %, es decir, 6/10. ¿Podría deberse esto al tipo de propiedades de la columna LSL? Es una columna numérica continua con formato "Mejor" con un ancho de 12. Intenté variar el ancho y volver a calcularlo, pero no hay diferencia.
Nuevamente, el punto es que uso valores de LSL y USL de una tabla ya que estoy haciendo un análisis para muchas variables y no puedo escribirlas individualmente.
Re: Límites de especificaciones para la plataforma de detección de procesosSí, esto confirma que se trata de un problema de precisión al comparar dos valores de punto flotante. Es mejor evitarlo con el método que describí anteriormente.
Re: Límites de especificaciones para la plataforma de detección de procesos¿Entonces, estás sugiriendo no utilizar los formatos de planificación de capacidad de proceso o de evaluación de proceso? ¿La tabla de especificaciones se genera mediante un script de Python, por lo que tengo cierta libertad para jugar con el formato? ¿Sugieres algo en particular?
Re: Límites de especificaciones para la plataforma de detección de procesosSugiero que apliques una banda de protección a tus especificaciones para tener en cuenta la imprecisión de la comparación de valores de punto flotante. Un float64 (número de punto flotante de doble precisión) puede representar números reales con aproximadamente 15 a 17 dígitos decimales de precisión, lo que significa que, si bien puede representar una amplia gama de números, habrá un pequeño grado de imprecisión en los últimos decimales debido a las limitaciones de la representación binaria; esencialmente, la mayoría de los números reales solo se pueden aproximar con un float64, no se pueden representar de manera exacta.
Esto implica que la banda de protección debe ser al menos 1e-15.
Re: Límites de especificaciones para la plataforma de detección de procesosVolví a mi script de Python y cambié todos los valores flotantes de la lista de especificaciones de float64 a float16. Al usar la plataforma de pantalla de proceso y los límites de especificaciones importados de la tabla de especificaciones, parece que los valores fuera de especificación se cuentan correctamente. Esta podría ser la solución actual para este problema.
