Designed & Made in the USA Since 1983
Un número de canal le indica qué transmisor envió la lectura. GageSync le dice qué medidor la tomó y si ese medidor estaba calibrado.
This post is also available in:
MicroRidge Systems se complace en anunciar el lanzamiento de GageSync y TriggerSync, dos nuevos conjuntos de capacidades para la API de MobileCollect EVO que permiten que el software SPC y de calidad se comunique en ambas direcciones con el transmisor y el medidor MobileCollect. Ambos están disponibles ahora en el firmware 6.30 de MobileCollect EVO Base y el firmware 6.12 de Mini Mobile Module EVO. Actualice su firmware aquÃ.
Hasta ahora, la API de MobileCollect EVO permitÃa que el software de terceros configurara un sistema inalámbrico: emparejar transmisores, asignar canales, establecer formatos de salida. Los datos seguÃan fluyendo en una dirección, del medidor al host. GageSync y TriggerSync cambian la dirección de la conversación.
GageSync proporciona al software acceso directo al propio instrumento en medidores compatibles con Mitutoyo S1. Una aplicación puede leer el número de serie del medidor, las fechas de la última y próxima calibración, el número de modelo y el código del medidor, y puede enviar comandos de vuelta al medidor, incluido un cero remoto.
TriggerSync permite que el host solicite una lectura en lugar de esperar a que un operador presione un botón, y funciona sin un medidor S1. También añade el modo TIR remoto, un ciclo de lectura continua para la excentricidad total del indicador que devuelve el recuento de lecturas, el mÃnimo, el máximo y el rango como un único resultado, además de comandos para identificar un transmisor mediante sus LED.
Dos preguntas deciden si una medición es fiable, y hasta ahora el flujo de datos no respondÃa a ninguna de ellas.
¿Qué medidor produjo esta lectura? En una implementación inalámbrica convencional, la respuesta se infiere. El registro lleva un número de canal, y el canal identifica un transmisor, no un medidor. Todo lo demás es una suposición sobre qué medidor estaba conectado a ese transmisor en ese momento, y es una suposición que sobrevive hasta que se intercambia un medidor entre accesorios, se mueve un cable durante un cambio de turno o se pone en servicio un repuesto sin que nadie actualice una hoja de cálculo.
El número de serie del medidor es la única respuesta positiva. GageSync lo lee del instrumento y permite que el software lo adjunte a la medición, una vez a petición o con cada lectura. Eso convierte la identidad del medidor de algo reconstruido posteriormente en un campo del registro.
¿Estaba ese medidor calibrado en ese momento? GageSync lee las fechas de la última y próxima calibración del medidor junto con el número de serie. El software puede comparar la fecha de la próxima calibración con el reloj del sistema y rechazar una lectura de un medidor no calibrado antes de que llegue a la base de datos, en lugar de descubrir el problema durante una revisión de registros tres meses después.
Los dos funcionan juntos. Una fecha de calibración solo es significativa si se sabe a qué medidor pertenece, y un número de serie solo indica que el medidor era el correcto, no que era apto para su uso. LeÃdos juntos y adjuntos a la lectura, convierten un registro de trazabilidad de algo que un ingeniero de calidad reconstruye durante una auditorÃa en algo que llega ya ensamblado. Para cualquiera que ejecute un sistema de recuperación de calibración bajo ISO 9001, IATF 16949 o AS9100, esa es la diferencia práctica.
El número de modelo y el código del medidor se devuelven de la misma manera. Ambos son más útiles en el lado de la adquisición, cuando un medidor debe ser emparejado y reordenado.
Leer datos del medidor es una mitad. Enviar comandos al mismo abre un conjunto diferente de problemas.
Considere un accesorio de varios medidores colocado en una pieza. Antes de realizar cualquier medición, el software puede consultar el número de serie de cada medidor en el accesorio y confirmar que los medidores correctos están realmente en él. Luego puede poner a cero cada medidor y leer cada uno para verificar que el cero se realizó correctamente. Puede recopilar una serie de lecturas de cada posición para confirmar que el accesorio es estable antes de registrar el valor que cuenta.
Cada uno de esos pasos era anteriormente un procedimiento manual, una suposición o ambos. Ahora, ninguno de ellos requiere que un operador toque nada.
TriggerSync significa que el host decide cuándo ocurre una lectura. Esto es más importante donde presionar un botón es inconveniente, poco fiable o imprudente.
Un medidor montado en una celda de lavado, dentro de una carcasa de máquina o en cualquier lugar donde un operador no deba tener la mano durante la medición, ahora se puede leer por comando desde el software. El modo TIR extiende la misma idea a una comprobación de excentricidad completa: el software inicia el ciclo, la pieza gira y el recuento, el mÃnimo, el máximo y el rango se devuelven como un solo resultado, sin que nadie esté en el indicador observando la aguja y sin presionar ningún botón entre el operador y la medición.
GageSync y TriggerSync a través de la API de MobileCollect EVO están diseñados para las empresas que desarrollan software SPC y de calidad. Los comandos son la interfaz, y la experiencia en torno a ellos pertenece a la aplicación, no a una utilidad de MicroRidge que el operador tenga que aprender.
Cada capacidad se expone a través de la API de MobileCollect EVO como un comando serie documentado a través de un puerto COM virtual. No hay ninguna utilidad separada que instalar ni ningún cuadro de diálogo de configuración que sus usuarios tengan que aprender. Los comandos se almacenan en la Base y se entregan al transmisor en su siguiente registro, con una respuesta en dos etapas: una confirmación de que el comando se puso en cola y una segunda respuesta cuando el transmisor lo ha ejecutado. Un único paso de habilitación única en el transmisor activa la comunicación bidireccional, y todo lo demás está bajo control del software.
La gestión inteligente de la baterÃa se incluye junto con ellos. En lugar de mantener un intervalo de registro fijo, el transmisor modula su propia tasa de registro en función de la actividad del medidor: más rápido mientras el medidor está en uso para que la latencia de los comandos se mantenga baja, más lento a medida que se inactiva para que el consumo de corriente disminuya. Tres esquemas apuntan a 9 meses, 1,5 años y más de 2 años de duración de la baterÃa, y el software que necesita una latencia determinista puede establecer un intervalo fijo en cualquier lugar desde 500 milisegundos hasta 60 segundos.
Esto es más una base que un conjunto de caracterÃsticas terminado. La comunicación bidireccional con el medidor fue la parte difÃcil, y ahora que existe, las capacidades que se basan en ella son considerablemente más fáciles de añadir. Tampoco se limita a un solo módulo: la estructura de comandos fue diseñada para la plataforma MobileCollect en lugar de para un solo transmisor, y más de la lÃnea de productos la hablará con el tiempo. Una integración escrita contra la API se amplÃa a medida que esto sucede, sin necesidad de reescribirla.
Tenemos la intención de seguir ampliando el conjunto de comandos, y preferirÃamos hacerlo con un trabajo de integración real que de forma aislada. Si su aplicación necesita algo del medidor que no está en esta versión, dÃganoslo.
GageSync y TriggerSync están disponibles ahora y requieren el firmware 6.30 de MobileCollect EVO Base y el firmware 6.12 de Mini Mobile Module EVO. Ambas son descargas gratuitas para el hardware MobileCollect EVO existente. No hay hardware nuevo que comprar ni tarifa de licencia para la API.
La documentación completa de comandos, las tablas de parámetros y los formatos de respuesta se encuentran en la página de la API de MobileCollect EVO, junto con la GuÃa de implementación descargable.
Desarrolladores de software SPC y de calidad: la página de la API tiene todo lo necesario para definir el alcance de una integración. Si desea hablar sobre un caso de uso especÃfico, MicroRidge proporciona soporte de ingenierÃa directo y hardware de demostración sin coste alguno.
Gerentes de calidad y usuarios finales: GageSync y TriggerSync son capacidades que su software SPC debe implementar. Si la identidad del medidor y el estado de calibración que llegan con cada lectura cambiarÃan la forma en que funciona su proceso de trazabilidad o recuperación de calibración, pregunte a su proveedor de SPC sobre su integración y dirÃjalos a la documentación de la API. Estaremos encantados de trabajar directamente con ellos.
Debido a que cada comando es texto ASCII simple a través de un puerto COM virtual, todo el conjunto de caracterÃsticas se puede probar manualmente antes de que exista una sola lÃnea de código de integración.
Comience con <$A:ICLA. Un comando, y la base informa de todos los canales que tiene: qué transmisores están emparejados dónde, y si cada canal tiene GageSync disponible, solo TriggerSync o ninguno. Antes de enviar algo a un medidor, sabe con qué está trabajando. En este ejemplo, el transmisor está emparejado con el canal A, y el canal A vuelve sin ninguno, porque la comunicación bidireccional aún no se ha activado.
Activarlo es el único paso que implica el hardware. Ponga ese transmisor en modo de configuración en el módulo y envÃe <$A:GSAMD1. Esto se hace una vez por transmisor, y a partir de ahà ya está en marcha, con todo escrito en ComTestSerial. <$A:GSASN2 devuelve el número de serie del medidor, <$A:GSANC2 devuelve la fecha de la próxima calibración, <$A:GSAGR1 solicita una lectura, <$A:GSAZG1 pone a cero el medidor, y <$A:GSAMD4 informa del estado de ese canal en cualquier momento que desee comprobarlo. EnvÃe <$A:ICLA de nuevo y el canal que hace un minuto se leÃa como ninguno ahora informa de GageSync.
Los doce botones definibles por el usuario de ComTestSerial contendrán un conjunto de comandos de trabajo, de modo que un desarrollador que esté definiendo el alcance de una integración puede cargar los comandos que le interesan, hacer clic en toda la secuencia y ver las cadenas de respuesta exactas que el código tendrá que analizar. Esa es la forma más rápida de responder a las dos preguntas que surgen primero: qué devuelve realmente mi medidor y cuánto tiempo tarda un comando en ir y volver a la velocidad de registro que he configurado. También es la herramienta a la que recurrir cuando una integración se comporta mal en el campo, ya que muestra si el problema está en el cable o en el software.
El conjunto completo de comandos, las tablas de parámetros y los formatos de respuesta se encuentran en la página de la API de MobileCollect EVO.
Contacto:
MicroRidge Systems
541-593-1656
info@microridge.com