Hola. Me gustaría tener la posibilidad de establecer la USL igual a la LSL. Actualmente estoy usando JMP Pro 17.2.0. Si intento establecer los límites iguales entre sí en la ventana Propiedades de columna, aparece el error "USL debe ser mayor que LSL y el objetivo". Error similar si lo intento usando la plataforma Administrar límites.
Consulte este hilo para ver una discusión original:
https://community.jmp.com/t5/Discussions/Setting-Spec-Limits-with-USL-LSL/mp/717822#M89952
¿Qué inspiró esta solicitud de lista de deseos?
Si intento establecer límites iguales entre sí en la ventana Propiedades de columna o en la plataforma Administrar límites, aparece un error. Puedo establecer los límites mediante programación para que sean iguales usando el mensaje << Establecer propiedad, pero no puedo volver a leerlos usando Administrar límites. Este guión ayuda a ilustrar:
Names Default to Here(1);<BR />dt = Open("$SAMPLE_DATA/Big Class.jmp");
dt:Height << Set Property("Spec Limits", USL(1), LSL(1)); //I can set USL=LSL in a script<BR />//I can confirm they've been set by manually opening the Column Properties window.
//At some later date I need to reopen the table and get the limits to evaluate yield:
msl = dt << Manage Limits(Process Variables(:Height)); //The limits are now missing.
dtlim = msl << Save to Tall Limits Table;
A veces también veo una pequeña ventana emergente que dice algo como "Límites inconsistentes" con todas las columnas ofensivas enumeradas, pero aún no he descubierto cómo reproducir esto.
¿Cuál es la mejora que le gustaría ver?
Me gustaría poder establecer límites iguales entre sí en las ventanas Propiedades de columna y Administrar límites. Sin embargo, quiero seguir evitando que USL
¿Por qué es importante esta idea?
Nuestros datos contienen miles de columnas. Algunas columnas (pero no todas) representan códigos (enteros), donde solo un valor significa "ok" y todos los demás indican un tipo diferente de falla. Por ejemplo, un "1" es correcto, un "0" = no se realizó la prueba y los valores 2 o más indican algún otro error. Deseamos calcular los rendimientos y otros análisis de estos datos utilizando scripts. Pero descubrimos que estas columnas donde USL=LSL no se verifican porque cuando el script vuelve a leer los límites usando Administrar límites, faltan.
Cosas que hemos considerado:
1. Establezca los límites en (x-0.1, x+0.1) en lugar de (x,x). No puedo hacerlo porque eso requeriría modificar cientos de límites multiplicados por varios pasos de fabricación multiplicados por varios programas, y afectaría a muchas otras organizaciones de nuestra empresa.
2. Establezca solo el LSL para estas columnas, sin incluir el USL. Luego, en nuestro script de análisis de rendimiento, agregue una cláusula que verifique el nombre de la columna con una lista de columnas cuyos valores están "codificados" y, si coinciden, simplemente verifique si el valor coincide con el LSL en lugar de verificar si el valor se encuentra entre LSL y USL. Es problemático porque requeriría que codifiquemos qué columnas deben verificarse de una forma u otra dentro del script, actualizando constantemente los scripts a medida que la lista de nombres cambia a lo largo del desarrollo. Además, tendrían que mantenerse listas separadas para cada paso de fabricación y cada programa, ya que no comparten las mismas pruebas. También es problemático porque otros utilizan diferentes scripts de análisis de los datos, que pueden no saber si hemos eliminado la USL y hemos conservado solo la LSL.
3. Establezca los límites mediante programación como en el script anterior. Luego, cuando deseemos volver a leerlos de la tabla de datos en una fecha posterior, use el mensaje << Obtener propiedad en lugar de Administrar límites. Todavía estoy trabajando en un guión para intentar esto, pero ya tengo dudas sobre este tacto. En primer lugar, necesitaría un bucle For para leer y analizar las especificaciones de cada columna, lo que podría llevar un tiempo para más de 10.000 columnas. En segundo lugar, tengo dificultades para analizar los límites del mensaje << Obtener propiedad("Spec Limits"). (1) Simplemente devuelve USL(1) (sin comillas) y no me queda claro cómo extraer el número de esto. (2) no parece devolver el LSL, aunque confirmé en la ventana Propiedades de columna que también estaba configurado en 1. El siguiente script ilustra:
Names Default to Here(1);<BR />dt = Open("$SAMPLE_DATA/Big Class.jmp");
dt:Height << Set Property("Spec Limits", USL(1), LSL(1)); //confirm limits set in col props window.<BR />specs = dt:Height << Get Property( "Spec Limits" ); //returns USL(1) only
lsl = specs["LSL"]; //returns .
usl = specs["USL"]; //returns .
Disculpas de antemano si hay otras soluciones obvias en las que no he pensado (u olvidé mencionarlas). También me disculpo si he pasado por alto algún detalle crucial. He estado trabajando en esto por un tiempo, así que estoy bastante metido en la maleza.
Gracias por considerarlo.
@nikles estamos planeando realizar una actualización de la tabla de datos en JMP v18.1 que permitiría LSL=USL. Sin embargo, tenga en cuenta que las columnas que tienen esa configuración de propiedad no funcionarán en los informes de capacidad.
Hola @nikles, leí el hilo de discusión de la comunidad relacionado y esta solicitud. Me parece que lo que realmente necesitas es una forma de definir y almacenar una "especificación categórica". Por ejemplo, si la prueba del producto simplemente produce un resultado de Pasa/Falla y "Pasa" es la especificación, querrás poder almacenar eso como la especificación en una propiedad de columna. También pude ver otros tipos de especificaciones categóricas, como que el resultado de la prueba es Excelente, Bueno, Deficiente, Fallo y "Excelente" o "Bueno" es la especificación de aprobación.
Actualmente, el USL y el LSL para la propiedad de la columna Límites de especificación están destinados a respuestas continuas y, por eso, no tiene sentido para LSL>=LSL. La plataforma Administrar límites en Analizar > Calidad y proceso está destinada a administrar los límites utilizados en los análisis JMP. No conozco ninguna plataforma JMP que utilice un límite categórico como este.
Para su necesidad inmediata, puede crear una propiedad de columna personalizada (elija "Otro" en propiedades de columna) para almacenar la especificación categórica. O podría usar el mensaje << Establecer propiedad () en JSL en la tabla de datos. Entonces podrías utilizar esa propiedad en tus scripts.
Corrección importante. Las segundas líneas en los dos scripts que se muestran arriba deberían ser:
dt:Height << Set Property("Spec Limits", {USL(1), LSL(1)}); //forgot to add {}Disculpas por el descuido. Esto explicaría por qué tenía dificultades para usar los mensajes << Establecer propiedades y << Obtener propiedades. Ahora veo que *puedo* volver a leer los límites usando la ventana Administrar límites. Sin embargo, todavía aparece la siguiente ventana emergente cuando se abre Administrar límites:
Además, si intento "Guardar en la tabla de límites altos", aparece este error:
Por último, en mi publicación original en "Cosas que hemos considerado", elemento 3 ( leer los límites de la tabla de datos usando el mensaje << Obtener propiedad en lugar de Administrar límites), este método ahora funciona para mí. Todavía prefiero usar la plataforma Administrar límites para leer mis límites, ya que crea automáticamente una tabla, pero al menos esta es una solución viable.
@SamGardner ¡Gracias por la ayuda! Me alegra que hayan decidido permitir LSL=USL. No había considerado su otra solución sobre definir una propiedad de especificación categórica, así que gracias también por eso. Sin embargo, diría que un problema con esa solución sería similar a mi otra solución de definir únicamente el LSL para estas columnas. Es decir, necesitaría que mis scripts trataran esas columnas de manera diferente al calcular los rendimientos, lo que requiere que mis scripts sepan para qué columnas hacer esto. Permitir LSL=USL me permite tratar todas las columnas por igual.
