Artículo en redacción / HMI / Pantalla / es-ES
Reparar o cambiar una HMI: qué enviar al banco de reparación
El banco de reparación no sabe nada de tu máquina salvo lo que envías. Empaqueta identidad, síntomas y contexto, y el presupuesto llega antes.
La pregunta que responde esta guía
¿Qué ve primero el banco de reparación cuando recibe una HMI?
1. Qué ve primero el banco
Un banco de reparación recibe tu panel como una caja con una historia adjunta, y la historia empieza con la identidad. El trío de identidad es el número de pedido y la revisión completos exactamente como están impresos, una foto enfocada de la etiqueta trasera y una foto del marco. Para un PanelView Plus 7 eso significa la cadena 2711P completa, como 2711P-T7C22D9P, no una referencia 2711P acortada. Un banco que recibe la variante equivocada pierde un ciclo completo de diagnóstico.

Esquema no disponible.
Por qué importa tanto la cadena completa en el banco: el bloque final separa los paquetes de hardware y de opciones, y el banco los necesita para reproducir correctamente el equipo. Dos terminales que se ven igual por el frontal pueden querer cables de pantalla distintos, superficies táctiles distintas o pasos de firmware distintos. La cadena es la única forma fiable de saber qué equipo se abrió en el banco de trabajo.
Si la etiqueta es ilegible, usa una foto de la página de diagnóstico y dilo. La mayoría de los paneles imprimen en pantalla su número de pedido exacto y su versión de firmware, y esa foto más una nota sobre por qué falló la etiqueta vale más que una referencia adivinada. Lo que el banco no puede aceptar en silencio es un número seguro que resulta pertenecer a otro equipo.
Un límite pertenece al principio. El trío de identidad le dice al banco qué está sosteniendo. No le dice qué falla, y no compromete a nadie con un resultado de reparación. Eso viene del registro de síntomas y de las comprobaciones que el banco realice.
Fuentes y alcance (1)
- Rockwell Automation: PanelView Plus 7 Performance Terminals User Manual, publicación 2711P-UM008. Muestra cómo los números de catálogo 2711P-xxx22x9P separan los paquetes de hardware y de opciones. Apoya el registro de identidad, no un diagnóstico de reparación.
2. Cómo escribir el registro de síntomas
El registro de síntomas describe qué cambió, cuándo cambió y qué sigue funcionando. Mantén separados los síntomas de táctil, de imagen y de alimentación, como muestra la guía de síntomas enlazada, porque apuntan a componentes distintos. Escríbelo como una lista corta, no como un relato. Un banco lee listas; una narración les obliga a releerlo todo dos veces.

Esquema no disponible.
Incluye las pruebas de aislamiento que ya hayas hecho, con sus resultados. Una comprobación con ratón USB que movió el cursor mientras la capa táctil seguía muerta, o una prueba con linterna que mostró contenido tenue en una pantalla oscura, recortan cada una una rama entera del diagnóstico. Da el resultado y la fecha, y marca tu conclusión como provisional en lugar de fundirla con la observación.
Las fechas pesan más de lo que parecen. Un fallo que apareció tras un corte de luz, una limpieza del armario eléctrico o una tormenta eléctrica se lee de forma distinta a uno que se instaló durante meses. El banco ve muchos paneles por semana, y una historia fechada les permite comparar tu equipo con casos similares con honestidad.
Una disciplina mantiene útil el registro: nunca resumas hasta borrar un detalle que parecía irrelevante. Un comportamiento de arranque extraño que se detuvo solo, un fallo que solo aparece cuando el armario está caliente o un mensaje que apareció una vez pueden ser el detalle que ahorra un día de diagnóstico. Las listas son baratas. Omitir cosas es caro.
3. Qué notas de entorno e historia importan
Las notas de entorno responden a las preguntas que el banco no puede hacerle a tu máquina. ¿Cómo está montado el panel, y qué ve el armario eléctrico en temperatura y limpieza? Un panel de una línea alimentaria con lavado cuenta una historia distinta a la de uno de una sala de control seca, incluso con síntomas idénticos. Dos frases llevan casi todo esto.

Esquema no disponible.
El historial de reparaciones anteriores pertenece también al paquete. Si el panel se reparó antes, di quién y qué se sustituyó. Un banco que abre un equipo con piezas no originales presupuesta el trabajo de forma distinta, y una reparación previa puede explicar un fallo que de otro modo no tiene sentido para ese modelo. Si el panel venía de un repuesto de estantería, registra cuánto tiempo estuvo almacenado y dónde.
Las condiciones de almacenamiento explican algunos síntomas de equipo muerto al llegar, y por eso existe la pregunta del repuesto de estantería. Un equipo guardado diez años en un almacén sin calefacción tiene condensadores distintos a uno guardado en un local acondicionado. Los bancos lo ven a menudo, así que la nota vale el minuto que cuesta.
El límite de las notas de historia: informan la inspección, no la deciden. Una reparación previa no hace que el banco culpe a las piezas viejas, y un entorno severo no reserva de antemano una causa. Escribe qué ocurrió, y deja que el equipo abierto lo confirme o lo descarte.
4. Qué cambia la clase de fallo
La clase de fallo mueve la recomendación más que cualquier otra cosa que envías. Una retroiluminación averiada o una capa táctil resistiva gastada en un Comfort Panel es una reparación de componente definida. Un equipo que se enciende sin mostrar ninguna imagen puede ser un fallo de placa base o de alimentación. Un panel inundado o quemado normalmente no es rentable de reparar. Registra a qué clase apunta la evidencia, y márcala como provisional.

Esquema no disponible.
La clase importa porque cambia a la vez la primera hora del banco y tus expectativas. Una reparación de componente tiene una lista de piezas conocida y un coste acotado. Un fallo a nivel de placa empieza con diagnósticos que pueden acabar en cualquier parte. Saber en qué conversación estás evita tanto la esperanza falsa como la sustitución prematura de un equipo reparable.
Cuando la clase no está clara, di qué comprobaste y qué descartó. Una nota como la pantalla sigue negra, LED de alimentación encendido, la comprobación con ratón respondió, así que el runtime funciona pero el recorrido de imagen falla, da al banco una salida lanzada. Una nota que dice panel muerto les obliga a establecer lo básico desde cero.
Mantén un límite: tu estimación de clase es una hipótesis, no un hallazgo. El banco confirma la clase cuando se abre el equipo, y una clase provisional bien escrita que resulta equivocada sigue siendo una buena respuesta, porque cada prueba que documentaste les dice dónde ya buscaste.
5. Cómo el estado del proyecto decide el intercambio
El estado del proyecto decide si un intercambio es realista, y por eso comparte la portada del paquete con la identidad. Con una copia de seguridad verificada, una unidad de intercambio puede cargarse e instalarse, y reparar el original pasa a ser una cuestión de repuestos. Sin copia, el almacenamiento del panel guarda la única copia del proyecto de la máquina, y las rutas que preservan el almacenamiento pasan al frente.

Esquema no disponible.
Di en la solicitud que se prefiere una ruta que conserve el almacenamiento, cuando ese sea el caso. Esta única línea ahorra una ronda entera de preguntas, porque el revisor sabe de inmediato que un equipo de repuesto en blanco, por rápido que llegue, no resuelve tu problema. La misma línea explica también por qué podrías rechazar una oferta atractiva por lo demás.
El estado de la copia se empareja con el registro de la herramienta. Escribe qué herramienta construyó el proyecto y qué versión, por ejemplo una aplicación de FactoryTalk View Machine Edition archivada como .apa, o un proyecto de TIA Portal. Un intercambio cargado desde un archivo que nadie puede abrir no es un intercambio, es un segundo panel con el mismo problema un paso después.
Un límite se mantiene aquí también. El estado de la copia moldea la ruta, no garantiza una. Si la referencia exacta está disponible para intercambio, y qué cuesta una reparación que preserve el almacenamiento, siguen abiertos hasta que el proveedor los compruebe contra fuentes actuales.
6. Cómo se cierra la solicitud
Cierra el paquete con tu ruta preferida y la condición que hay detrás. Reparación preferida, intercambio, aprovisionamiento de la referencia exacta o sustitución completa inician cada uno una revisión distinta. Declarar la preferencia más su restricción, por ejemplo sin copia de seguridad del proyecto, deja que el revisor la confirme o la cuestione con evidencia. Una preferencia con razón es revisable. Una preferencia sin explicación suele relitigarse después.

Esquema no disponible.
Añade las cifras de operación que escalan la respuesta. La tolerancia al paro de producción y el número de unidades idénticas en servicio cambian el plan más que el propio fallo. Una sola línea parada sin repuesto empuja hacia la opción documentada más rápida, y una flota de la misma referencia hace valiosa una buena reparación como repuesto futuro.
Envía a través del formulario de solicitud con los archivos adjuntos, y guarda tu propia copia de todo lo enviado. Manda imágenes a resolución original en lugar de capturas comprimidas, porque los sufijos de las etiquetas son el primer detalle que desaparece en la compresión. Las fotos de la etiqueta trasera, del estado de la pantalla y de las páginas de proyecto o firmware cubren casi todo lo que necesita el paso siguiente.
El paquete prepara la revisión pero no fija el resultado. Presupuestos, éxito de la reparación y disponibilidad de intercambio dependen de comprobaciones que realiza el proveedor. Redacta la solicitud alrededor de evidencia y preferencias en lugar de promesas sobre coste o viabilidad. Un proveedor que recibe este paquete puede presupuestar, rechazar o redirigir en la primera pasada en lugar de pedir lo básico. Ese es todo el propósito del paquete.
Cómo funciona el flujo
Puntos clave
- Envía el número de pedido completo, la revisión y fotos enfocadas de la etiqueta y del marco.
- Registra los síntomas por capa, con resultados de pruebas y fechas.
- Di si existe una copia de seguridad de proyecto verificada. Decide la viabilidad del intercambio.
- Da la tolerancia al paro, el número de unidades instaladas y tu ruta preferida con su razón.
Páginas relacionadas
Notas editoriales y fuentes
Esta vista previa es una nota de trabajo delimitada, no un artículo técnico validado ni una afirmación de compatibilidad, existencias, precio, servicio o seguridad.
Registro de fuentes
Versión: docs/product/comparison-and-recovery-model.md|Repair capability evidence required
- docs/product/comparison-and-recovery-model.md
- Repair capability evidence required
Estado del proceso editorial
Estado: borrador / no indexado
Puntos sin resolver: las afirmaciones técnicas y comerciales necesitan pruebas atribuibles; la reparabilidad, la disponibilidad de intercambio y los precios son comprobaciones del proveedor que ningún paquete de evidencia resuelve por sí solo
