El diseño de la retroalimentación para controles táctiles capacitivos debe distinguir cuatro eventos: se ha detectado un toque, se ha aceptado un comando, se ha completado una acción o se ha producido un error o una advertencia. Asigne un significado definido a cada señal y haga que el componente que sabe que el evento ha ocurrido autorice esa señal. Un pitido, un icono iluminado o una vibración nunca deben dar a entender que la máquina ha realizado correctamente una operación solo porque se ha detectado un dedo.
Esta guía se centra en botones y teclados capacitivos con funciones fijas. La precisión de las coordenadas de una pantalla, la correspondencia de coordenadas en los bordes y la validación multitáctil son tareas distintas. Al especificar paneles táctiles capacitivos a medida, incluya el mapa de estados de retroalimentación junto con la distribución de las teclas y la interfaz eléctrica.
- Separe la detección de entrada de la finalización del comando
- Elija una confirmación visual, sonora o háptica
- Confirmación visual
- Confirmación sonora
- Confirmación háptica
- Tenga en cuenta el ruido, los guantes y la atención del operador
- Asigne responsabilidades a los circuitos de accionamiento, el firmware y el sistema anfitrión
- Valide el significado y la temporización de la retroalimentación
- Mida la cadena de eventos
- Defina la prioridad y la recuperación
- Compruebe la interpretación del operador
- Preguntas frecuentes
- ¿Debe el panel emitir un pitido antes de que responda el sistema anfitrión?
- ¿Puede un solo LED indicar tanto el toque como el estado de la máquina?
- ¿Puede un pulso de vibración confirmar que un motor ha arrancado?
- ¿Debe generar retroalimentación cada toque detectado?
- ¿Qué debe ocurrir cuando los usuarios desactivan los sonidos de las teclas?
- ¿Puede un solo actuador identificar qué tecla se ha tocado?
- ¿Basta con añadir un circuito de accionamiento háptico para completar el sistema de retroalimentación?
- Prepare un plan de retroalimentación para el operador como parte de la RFQ
Separe la detección de entrada de la finalización del comando
Trate la detección, la aceptación, la finalización y los fallos como eventos independientes, incluso cuando el funcionamiento normal haga que parezcan simultáneos. Un controlador táctil puede comunicar una entrada; la aplicación responsable del comando debe decidir si este está permitido y si se ha obtenido el resultado previsto.
El siguiente mapa de eventos es ilustrativo; no prescribe un código de colores ni de sonidos.
| Evento | Significado de la retroalimentación | Responsabilidad de los circuitos de accionamiento y del firmware | Estado visible para el operador |
|---|---|---|---|
| Toque detectado | Se ha producido un evento de tecla que cumple los criterios de detección; aún no se ha establecido la validez del comando | El firmware táctil comprueba que el evento cumple los criterios de detección; el firmware local de la interfaz puede activar una señal LED, sonora o háptica acordada mediante su circuito de accionamiento | Respuesta breve de la zona objetivo; a la espera de la decisión del sistema anfitrión |
| Comando aceptado | La aplicación ha aprobado la solicitud; la ejecución puede seguir pendiente | La aplicación del sistema anfitrión autoriza la aceptación; el firmware de la interfaz controla los circuitos de accionamiento correspondientes | Aceptado, en cola o en ejecución, distinguiendo estos estados cuando sea necesario |
| Acción completada | Se ha confirmado el resultado definido | La lógica del sistema anfitrión o del proceso verifica el resultado y ordena su indicación | Completado, o el estado resultante del equipo que se haya verificado |
| Error o advertencia | Se ha rechazado una solicitud, ha fallado la ejecución o una condición requiere atención | El subsistema que detecta la condición la comunica; la lógica del sistema anfitrión le asigna significado y prioridad; el firmware de la interfaz la presenta | Rechazado, fallido, no disponible o advertencia con una explicación que permita actuar |
No clasifique automáticamente todas las advertencias como acciones fallidas. Registre si la operación continúa, se pausa o se rechaza.
En un comando de arranque ilustrativo, el resaltado de la zona objetivo puede confirmar el toque; una indicación de funcionamiento puede seguir a la aceptación por parte del sistema anfitrión, y una indicación de finalización puede seguir a la verificación de que el proceso ha terminado. Un acuse de recibo del transporte de mensajes demuestra que se ha recibido un mensaje, no que la aplicación lo haya aceptado. Del mismo modo, activar eléctricamente una salida no demuestra que un mecanismo haya alcanzado su posición objetivo.
Mantenga las indicaciones de preparado, deshabilitado y ocupado separadas de la confirmación del toque. Especifique qué debe hacer el operador a continuación en cada estado, especialmente cuando otro toque pueda generar incertidumbre.
Elija una confirmación visual, sonora o háptica
Seleccione la retroalimentación en función de la información que debe transmitir, no del número de efectos disponibles. Utilice señales transitorias para eventos discretos e indicaciones persistentes para estados que el operador pueda necesitar consultar más adelante.
Confirmación visual
Para la confirmación visual de un botón táctil, defina la zona objetivo iluminada, el texto del estado, la persistencia y la condición de desactivación de la indicación. La retroiluminación que solo ayuda a localizar un botón no debe implicar también que su comando se ha aceptado.
Combine el color con un símbolo reconocible, un texto u otra distinción visual. Las directrices del W3C sobre el uso del color describen este principio para el contenido web; aplicarlo a indicadores de equipos es una adaptación de diseño, no una declaración de conformidad del equipo. Compare prototipos con el ángulo de visión, la iluminación ambiental y la obstrucción por los dedos previstos. Registre si los operadores distinguen los estados pendiente, completado y de fallo sin tener que deducirlos a partir del color.
Confirmación sonora
Para la retroalimentación sonora de un teclado capacitivo, especifique qué evento produce el sonido, su patrón, repetición, control de volumen y comportamiento de silenciamiento. Compárelo con otros sonidos del equipo en la posición de trabajo del operador, teniendo en cuenta la protección auditiva exigida. No se limite a aumentar el volumen hasta que una demostración en banco resulte convincente.
Utilice una explicación visual persistente cuando un sonido breve no pueda comunicar el motivo del rechazo. Documente si la confirmación habitual puede silenciarse y qué requisitos de alarma definidos por separado permanecen inalterados.
Confirmación háptica
La detección capacitiva no genera vibración por sí misma. La retroalimentación vibrotáctil requiere actuador, electrónica compatible, alimentación, acoplamiento mecánico y una política de activación. DRV2605L es un ejemplo de controlador para motores de masa excéntrica rotatoria y actuadores resonantes lineales; DRV2667 utiliza otra arquitectura para actuadores piezoeléctricos. Son ejemplos de componentes, no soluciones intercambiables ni evidencia de un panel suministrado.
Evalúe la respuesta háptica capacitiva en la carcasa ensamblada. Especifique posición y montaje del actuador, forma de onda, zona de contacto prevista y ruido de vibración permitido. La parada controlada ayuda a obtener un clic diferenciado. Compare la separación entre efectos consecutivos, no solo un pulso aislado.
Tenga en cuenta el ruido, los guantes y la atención del operador
Elija una combinación que siga siendo interpretable cuando un canal no esté disponible o pase inadvertido. Las siguientes combinaciones son puntos de partida ilustrativos para comparar prototipos, no prescripciones universales.
| Condición de funcionamiento | Combinación que evaluar | Aspectos principales que comparar y registrar |
|---|---|---|
| El operador observa el panel en una zona silenciosa | Confirmación visual local con sonido discreto opcional | Reconocimiento del estado, obstrucción por los dedos y sonidos repetidos innecesarios |
| Ruido de maquinaria o protección auditiva | Estado visual persistente; háptica opcional durante el contacto | Reconocimiento sin sonido disponible y con el equipo en funcionamiento |
| La atención se centra principalmente en la pieza de trabajo | Señal sonora o háptica breve más una indicación persistente del resultado | Si se percibe la señal y si el estado final puede consultarse más adelante |
| Se requieren guantes aprobados | Confirmación visual; comparar el sonido y la háptica en el montaje instalado | Detección del toque y percepción de la retroalimentación como resultados independientes para cada condición de los guantes |
| Ajustes frecuentes o entradas repetidas | Señales de evento moderadas más una indicación actualizada del valor o estado | Solapamiento de señales, incrementos no registrados, comandos duplicados y molestia del operador |
| Vibración de la máquina o contacto intermitente de la mano | Información de estado visual o sonora; háptica solo después de evaluarla | Confusión con la vibración de fondo y pérdida de la vía de contacto táctil |
Una prueba satisfactoria de detección con guantes no demuestra que el mismo usuario pueda percibir claramente un actuador. A la inversa, una vibración más intensa no puede corregir un toque que no se ha detectado. Registre la especificación, el ajuste y el estado de los guantes, la postura, la ubicación del contacto y el resultado de reconocimiento correspondiente.
En las acciones que terminan después de que la mano abandone el panel, no dependa únicamente de la vibración del panel para comunicar la finalización. Incluya la duración real de la tarea y el movimiento del operador en la evaluación.
Asigne responsabilidades a los circuitos de accionamiento, el firmware y el sistema anfitrión
Asigne tanto un responsable del evento como un responsable de la salida. Un circuito de accionamiento puede generar luz, sonido o movimiento sin saber si un comando es válido. La especificación del proyecto debe relacionar explícitamente estas responsabilidades.
Los responsables de la cubierta y del sensor definen los gráficos de las zonas objetivo, la visibilidad de los indicadores, la geometría del sensor y la superficie de contacto una vez instalada. En el caso de la háptica, el responsable mecánico también define el soporte del actuador y la trayectoria de vibración prevista. Registre las revisiones de los planos y del conjunto.
Los responsables del controlador táctil y del firmware definen los eventos de pulsación y liberación que cumplen los criterios de detección, el comportamiento de pulsación mantenida, la repetición, el filtrado y el acceso al diagnóstico. Especifique si un comando se genera al pulsar, al liberar o al completar una pulsación mantenida. Una indicación del progreso de la pulsación mantenida no debe parecer una aceptación del comando.
Los responsables de la electrónica de salida y de la visualización definen los circuitos de accionamiento de los LED, los emisores sonoros y los actuadores, los requisitos de alimentación, las salidas al arrancar y los diagnósticos de fallo, cuando estén disponibles. El hardware de visualización presenta la información; el firmware de la interfaz asocia los eventos procedentes de sus fuentes responsables con estados visuales, sonidos y formas de onda. Identifique al responsable de esa correspondencia y su revisión.
Los responsables del sistema anfitrión o de la aplicación definen los permisos, la gestión del estado ocupado, la aceptación del comando, las pruebas de finalización, la cancelación, el tiempo de espera y la recuperación. Cuando los mensajes atraviesen un bus, defina identificadores de comando y el tratamiento de mensajes obsoletos para que un mensaje de finalización tardío no pueda parecer la confirmación de un comando más reciente.
En una compra integrada, el alcance del ensamblaje HMI debe identificar los componentes físicos incluidos y sus interfaces. Especifique por separado la programación del controlador, el software del sistema anfitrión, la selección del actuador y la validación del sistema, en lugar de considerar que «ensamblaje» implica automáticamente asumir esas tareas.
Pruebe también la detección mientras funcionan las salidas de retroalimentación. Los estados de accionamiento de los LED pueden cambiar la capacitancia y provocar falsas detecciones. Aplique las directrices del controlador seleccionado y, a continuación, haga funcionar conjuntamente la iluminación, el sonido y la háptica en el sistema instalado. Reserve la revisión más amplia de la estructura de capas para la guía de diseño de paneles táctiles capacitivos.
Valide el significado y la temporización de la retroalimentación
Valide lo que entienden los operadores y cuándo se produce la salida física, no solo si el firmware ha emitido un comando de reproducción. Establezca criterios de aceptación específicos del proyecto antes de realizar las pruebas; una especificación de arranque del circuito de accionamiento no equivale al retardo completo entre el toque y la retroalimentación.
Mida la cadena de eventos
Registre una referencia acordada de entrada física, el evento de tecla que cumple los criterios de detección, la aceptación por parte del sistema anfitrión, la finalización verificada y el inicio real de cada salida asociada. Utilice una base de tiempo común o documente la alineación de los relojes. Correlacione los registros eléctricos con un fotodetector para la luz, un micrófono para el sonido o un acelerómetro para la vibración, según corresponda. Registre la ubicación de los instrumentos y los umbrales de detección de eventos.
Utilice la siguiente plantilla de registro ilustrativa. Las celdas de resultados en blanco están destinadas a las mediciones del conjunto real.
| Comprobación | Temporización o comportamiento que registrar | Criterio de aceptación | Resultado real |
|---|---|---|---|
| Respuesta inicial | De la referencia de entrada al evento que cumple los criterios de detección y al inicio de la señal física | Límite de respuesta acordado y significado correcto de la señal local | |
| Aceptación | De la aceptación por parte de la aplicación al inicio de la señal correspondiente | Ninguna señal de aceptación antes de la aprobación; asociación correcta con el comando | |
| Finalización | Del resultado verificado a la indicación persistente del resultado | Resultado definido verificado; no afirmar un éxito físico basándose solo en un temporizador | |
| Entrada repetida | Número de eventos, número de comandos aceptados, inicio y final de las señales | Política de repetición acordada; efectos distinguibles | |
| Rechazo o pérdida de comunicación | Detección de la condición, cambio de la indicación y duración del estado pendiente | Tiempo de espera definido; ninguna indicación falsa de éxito ni instrucción de reintento sin fundamento |
Repita las pruebas en las condiciones pertinentes de arranque, suspensión y reactivación, carga del sistema anfitrión, alimentación y funcionamiento simultáneo de las salidas. Registre los intervalos observados y las excepciones, en lugar de limitarse a una media o a la demostración más rápida.
Defina la prioridad y la recuperación
Para la retroalimentación del funcionamiento habitual, dé prioridad a los fallos y a las explicaciones de comandos rechazados frente a las confirmaciones ordinarias. Defina qué indicaciones permanecen, qué efectos pueden interrumpirse y cuáles quedan obsoletos. No reproduzca confirmaciones de toque en cola cuando ya no describan el estado actual.
Someta el diseño a pruebas con el sistema anfitrión desconectado, mensajes retrasados o duplicados, toques rápidos, una tecla mantenida, un reinicio durante la ejecución y un canal de salida no disponible. Decida si los comandos adicionales se ignoran, se rechazan o se ponen en cola mientras el sistema está ocupado. Un tiempo de espera agotado puede significar que el resultado es desconocido, no que no haya ocurrido nada; exija comprobar y conciliar el estado antes de recomendar un reintento.
La retroalimentación ordinaria no sustituye una función de seguridad. Mantenga los controles relacionados con la seguridad y el comportamiento de las alarmas dentro del proceso específico de evaluación de riesgos y conformidad del equipo.
Compruebe la interpretación del operador
Pida a usuarios representativos que expliquen qué significa cada señal y qué harían a continuación. Registre las confusiones, los toques repetidos, las advertencias inadvertidas y las suposiciones incorrectas de finalización. Combine un vídeo autorizado del funcionamiento del prototipo con los registros de eventos; el vídeo por sí solo no permite establecer una temporización precisa. Repita las comprobaciones afectadas después de modificar el firmware, los patrones, el montaje del actuador o el conjunto de la cubierta.
Preguntas frecuentes
Resuelva estas preguntas de implementación antes de aprobar la especificación de retroalimentación.
¿Debe el panel emitir un pitido antes de que responda el sistema anfitrión?
Solo cuando el pitido se haya definido explícitamente como detección local del toque. No debe sonar como una aceptación o finalización del comando. Cuando esa distinción no resulte clara para los usuarios, utilice una respuesta visual local neutra y reserve el sonido afirmativo para la aceptación por parte del sistema anfitrión.
¿Puede un solo LED indicar tanto el toque como el estado de la máquina?
Sí, siempre que sus estados sigan siendo distinguibles y las reglas de prioridad sean explícitas. Defina cómo interactúa una indicación breve de toque con los estados persistentes de funcionamiento, completado, deshabilitado y fallo. Pruebe toques rápidos mientras esté activo cada estado persistente.
¿Puede un pulso de vibración confirmar que un motor ha arrancado?
Solo cuando el pulso esté autorizado por el evento definido como funcionamiento verificado del motor. Un pulso activado por el sensor táctil confirma la entrada, no el movimiento del motor. Especifique las pruebas de proceso necesarias en lugar de equiparar un comando de salida con el éxito físico.
¿Debe generar retroalimentación cada toque detectado?
No necesariamente. Defina el comportamiento de las teclas deshabilitadas, el bloqueo para limpieza, las pulsaciones mantenidas no válidas y las entradas rechazadas. Un toque que cumple los criterios de detección puede producir una respuesta neutra o una explicación, pero no debe generar la misma señal afirmativa que un comando aceptado cuando no se ha producido la aceptación.
¿Qué debe ocurrir cuando los usuarios desactivan los sonidos de las teclas?
Conserve otro canal de confirmación comprensible e información persistente sobre el resultado. Trate los sonidos habituales de las teclas por separado de los requisitos de alarma. Verifique que el silenciamiento se conserva tras un reinicio y asegúrese de que el ajuste mostrado coincide con el comportamiento real.
¿Puede un solo actuador identificar qué tecla se ha tocado?
No lo dé por supuesto. Evalúe si los operadores pueden distinguir la tecla prevista a partir de la respuesta vibratoria del conjunto instalado. Cuando la identidad de la tecla siga siendo ambigua, proporcione una indicación visual local u otro identificador explícito en lugar de afirmar que la háptica está localizada.
¿Basta con añadir un circuito de accionamiento háptico para completar el sistema de retroalimentación?
No. El diseño sigue necesitando un actuador compatible, montaje, alimentación, configuración de la forma de onda, correspondencia de eventos, integración con el sistema anfitrión y validación del conjunto instalado. Incluya esos elementos y sus responsables en el alcance de compra; un circuito de accionamiento o un panel físico por sí solos no definen el sistema completo.
Prepare un plan de retroalimentación para el operador como parte de la RFQ
Envíe el mapa de eventos junto con la especificación del panel para que el presupuesto pueda diferenciar el hardware físico de las responsabilidades de electrónica y software.
Utilice Revisar mi plan de retroalimentación para el operador para compartir la distribución de las teclas, los planos de la cubierta y la carcasa, los patrones de retroalimentación, el controlador y la interfaz con el sistema anfitrión, los circuitos de accionamiento o actuadores propuestos, las condiciones de funcionamiento, las cantidades de prototipos y de producción y los criterios de aceptación. Identifique los componentes suministrados por el comprador y los límites de integración solicitados, especialmente para el sonido y la háptica.
¿Listo para iniciar su proyecto?
Cuéntenos sus requisitos de interruptores de membrana, teclados o láminas gráficas. Nuestro equipo de ingeniería revisará sus especificaciones y le proporcionará una cotización detallada.
