Un escape intermitente del carro es un evento de seguridad de la máquina

Un eje que se mueve sin la orden esperada no presenta una avería rutinaria de puesta en marcha. Es un evento de movimiento incontrolado que puede dañar herramientas, estructuras de la máquina, piezas de trabajo, utillajes y personas. El riesgo se vuelve más difícil de gestionar cuando el carro funciona con normalidad durante muchas horas antes de moverse repentinamente a una velocidad o en una dirección inesperadas.

La máquina considerada en este caso utiliza una Siemens SIMATIC S7-200 CPU 226, una unidad SIMOVERT MASTERDRIVES para los ejes de los carros, un MICROMASTER 440 para el husillo y un panel de operador TP 170A. Los datos de órdenes y estados se transmiten a través de una red de comunicación serie USS.

El problema indicado se produce en uno o ambos carros. Un incidente puede aparecer una o dos veces durante una jornada laboral, seguido de dos o tres días de funcionamiento normal. Entre los intentos anteriores se incluyeron separar el variador de frecuencia del husillo del armario de control principal y mejorar la puesta a tierra. Esas acciones no eliminaron la avería.

Este patrón suele fomentar una resolución de problemas especulativa. Los ingenieros pueden sustituir un encoder, redirigir un cable, ajustar un parámetro del variador o añadir otro conductor de puesta a tierra. Un cambio puede alterar temporalmente el síntoma, creando la impresión de que el problema se ha resuelto. El evento vuelve a producirse porque nunca se demostró la ruta real de la orden.

Una investigación fiable debe identificar el primer punto en el que el comportamiento esperado se vuelve anómalo. El equipo necesita saber qué solicitó la HMI, qué aceptó el PLC, qué transmitió el PLC, qué recibió el variador, qué activó internamente el variador y qué hizo realmente el motor.

Comience por confirmar todos los dispositivos instalados

Los sistemas Siemens antiguos suelen seguir en funcionamiento mucho tiempo después de que el equipo original de puesta en marcha se haya retirado. Los planos pueden contener cambios manuscritos. Las copias de seguridad de parámetros pueden estar incompletas. Es posible que se hayan instalado módulos de sustitución sin actualizar la documentación. Por lo tanto, la identificación del hardware debe preceder a la interpretación de los parámetros.

Registre el número de pedido completo de cada placa de identificación. No se base únicamente en una lista de equipos escrita a máquina. El número de CPU S7-200 indicado contiene caracteres que podrían haberse copiado incorrectamente. El controlador real podría corresponder al Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, pero la fuente de alimentación y la variante de salidas deben confirmarse directamente en la unidad instalada.

Un solo carácter incorrecto puede conducir al manual, diagrama de terminales o pieza de repuesto equivocados. La letra O se confunde frecuentemente con el cero. El número uno puede confundirse con la letra I. La falta de un sufijo también puede ocultar una opción de hardware importante.

La misma disciplina se aplica a la unidad SIMOVERT MASTERDRIVES. MASTERDRIVES es una familia amplia, no un único diseño fijo de accionamiento. Las tarjetas de control, las versiones de software, las opciones de encoder, las tarjetas tecnológicas y las configuraciones de Vector Control o Motion Control pueden cambiar los parámetros disponibles y el encaminamiento interno de las señales.

También debe verificarse el número de pedido del MICROMASTER 440. Aunque el MM440 controla el husillo en lugar de los carros, comparte el entorno del armario y puede compartir la ruta de comunicación USS. Sus eventos de conmutación, el tendido de los cables, la configuración de la dirección y la temporización de la comunicación pueden influir en el sistema general.

Registre el modelo del TP 170A, la versión del proyecto de la HMI, los ajustes de comunicación y las direcciones del PLC conectado. El panel puede contener eventos de botones, funciones de recetas, valores de arranque o comportamientos de etiquetas que no pueden identificarse únicamente a partir del programa del PLC.

Antes de cambiar cualquier parámetro, cree copias de seguridad completas del programa del PLC, el proyecto de la HMI, el juego de parámetros del MASTERDRIVES y el juego de parámetros del MM440. Fotografie las pantallas de los cables, los interruptores de las placas, las conexiones de los terminales y los módulos opcionales. Esta referencia permite comparar y revertir todas las modificaciones posteriores.

Defina qué entienden los operadores por embalamiento

La palabra «embalamiento» puede describir varios eventos diferentes. Una aceleración a velocidad máxima es distinta de un jog breve no intencionado. El movimiento durante el arranque es distinto del movimiento durante una secuencia automática. La ruta de diagnóstico cambia según el evento exacto.

Entreviste a todas las personas que presenciaron la falla. Pida observaciones en lugar de conclusiones. «El encoder falló» es una conclusión. «El carro se movió rápidamente en la dirección positiva mientras la HMI mostraba velocidad cero» es una observación.

Registre el eje implicado, la dirección, la velocidad estimada, la duración, la posición inicial, el modo de la máquina, el estado del husillo, el paso activo del programa y el método que detuvo el movimiento. Determine si el movimiento comenzó desde el reposo o se desarrolló durante un movimiento ya existente.

Si el carro se acelera hacia la velocidad máxima, investigue la polaridad de la realimentación, las fuentes activas de consigna, la secuencia de habilitación y la regulación del accionamiento. Si se mueve solo una distancia corta, investigue los bits de jog, los disparos duplicados por flanco, las órdenes obsoletas y las transiciones de estado de la secuencia.

Si el evento aparece únicamente en modo automático, la lógica de la secuencia adquiere mayor importancia. Si también ocurre en modo manual, concéntrese en la arbitraje de comandos compartida por ambos modos. Si el eje se mueve durante el encendido, la transición de la CPU, el reinicio del accionamiento o la reconexión de la HMI, la inicialización de arranque merece atención inmediata.

El comportamiento al detenerse proporciona pruebas valiosas. Si al retirar la señal de habilitación del accionamiento procedente del PLC se detiene el eje, es posible que la etapa de potencia siga respondiendo a la ruta de habilitación prevista. Si el movimiento continúa hasta aislar la alimentación principal, investigue el hardware del accionamiento, el cableado de habilitación externo, el comportamiento de los contactores y las fuentes de comandos ajenas al PLC.

Determine también si el accionamiento generó una advertencia o un fallo. Un evento sin fallos no demuestra que el accionamiento estuviera en buen estado, pero sugiere que pudo haber considerado válidos el comando y la realimentación.

Trate la máquina como una cadena de comandos completa

El comando de movimiento puede comenzar en el panel del operador TP 170A. Un botón, una entrada numérica, una receta, un evento de pantalla o una secuencia automática establece un valor de memoria del PLC. El S7-200 valida esa solicitud y calcula una velocidad o consigna de movimiento. A continuación, una rutina de comunicación USS construye un telegrama que contiene datos de control y de proceso.

La unidad MASTERDRIVES recibe el telegrama y pasa la palabra de control y la consigna a través de su estructura interna de señales. El comando activo final también puede incluir velocidades fijas, entradas analógicas, comandos de terminal, consignas suplementarias, entradas de avance lento o bloques de funciones internos.

La ruta de retorno es igualmente importante. El motor o la carga pueden utilizar un encoder incremental, un resolver, un tacómetro u otro dispositivo de realimentación. El accionamiento interpreta esa señal como velocidad o posición. A continuación, algunos valores reales pueden transmitirse al PLC.

Los interruptores de límite mecánicos, sensores de origen, interruptores de sobrerrecorrido, contactores, frenos y contactos de accionamiento listo crean rutas adicionales. Cada ruta puede afectar a si el movimiento comienza, continúa o se detiene.

Cada etapa debe tener un valor medible. En el PLC, registre la solicitud bruta de la HMI, el modo de funcionamiento seleccionado, el estado de la secuencia, la consigna final validada, la dirección, el comando de habilitación y el resultado de la comunicación. En el accionamiento, observe la palabra de control recibida, la consigna recibida, la consigna interna activa, la velocidad real, el estado de la realimentación, la corriente, las advertencias y los fallos.

Un cero mostrado en la HMI no demuestra que el PLC haya transmitido un cero. Un cero en un registro del PLC no demuestra que otra fuente de comandos estuviera inactiva. Un telegrama USS correcto no demuestra que el accionamiento estuviera configurado para utilizar dicho telegrama como única fuente de consigna.

La investigación debe identificar el primer punto en el que el valor esperado y el valor registrado no coinciden. Ese punto divide el problema en lógica de la HMI, aplicación del PLC, comunicación, configuración del accionamiento, realimentación, hardware de potencia o mecánica.

La división diagnóstica más importante

La primera pregunta técnica es sencilla: ¿recibió el accionamiento una orden legítima de movimiento?

Compare cuatro valores durante el evento:

• La consigna final de movimiento del PLC.
• La consigna recibida por el accionamiento.
• La consigna interna activa del accionamiento.
• El movimiento real medido del motor o del carro.

Si la consigna final del PLC pasa a ser distinta de cero y el accionamiento la sigue, es posible que el accionamiento funcione correctamente. El movimiento no deseado se generó aguas arriba. Investigue los eventos de la HMI, la lógica de secuencia, los valores retenidos, las transiciones de modo y las múltiples escrituras en la orden final.

Si la consigna final de movimiento del PLC permanece en cero, pero el accionamiento recibe un valor distinto de cero, investigue la construcción del telegrama, el mapeo de memoria, el escalado, la gestión del búfer y la ejecución del bloque de comunicación. El valor inesperado exacto puede identificar el mecanismo. Un valor fijo repetido suele indicar datos retenidos u obsoletos. Un valor positivo o negativo extremo puede indicar un problema de número con signo o de orden de bytes.

Si el accionamiento recibe cero, pero su consigna interna activa pasa a ser distinta de cero, examine la configuración del accionamiento. Puede haber una velocidad fija, una referencia analógica, una función de jog, una entrada de terminal, una consigna suplementaria, un potenciómetro motorizado o una opción tecnológica activos.

Si la consigna del PLC, la consigna recibida y la consigna interna permanecen todas en cero mientras el motor acelera, el evento es más grave. Investigue el comportamiento de la realimentación, la regulación del accionamiento, la alimentación de la tarjeta de control, el hardware del accionamiento, el comportamiento de la etapa de salida y el acoplamiento mecánico.

Este método de cuatro señales evita sustituir piezas sin control. También permite establecer una conclusión técnica defendible. El fallo se asigna según las pruebas registradas y no según suposiciones.

La realimentación es un sospechoso prioritario, pero no un veredicto automático

Un fallo intermitente del encoder o tacómetro es verosímil, especialmente cuando el evento cambia con la vibración, la temperatura, el movimiento del cable o la posición del carro. Sin embargo, la suposición de que cualquier pérdida de realimentación provoca automáticamente la velocidad máxima es demasiado general.

Un accionamiento configurado correctamente debería detectar normalmente la ausencia de realimentación o una realimentación inverosímil y responder según sus ajustes de supervisión y fallos. La respuesta exacta depende de la versión del control, la opción de realimentación, la configuración y la aplicación.

El comportamiento peligroso aún puede producirse cuando la señal de realimentación está presente, pero es incorrecta. La polaridad invertida, una secuencia de fases incorrecta, una amplitud de señal inestable, canales dañados, un tipo de encoder incorrecto, un escalado incorrecto, acoplamientos flojos o una configuración inadecuada del regulador pueden hacer que el accionamiento reaccione en la dirección equivocada.

Un cable intermitente rara vez falla como un circuito perfectamente abierto. Un conductor puede separarse únicamente cuando el cable se dobla. Un pin del conector puede perder el contacto solo durante una vibración intensa. La alimentación del encoder puede caer cuando funciona un contactor. La corriente del apantallamiento puede distorsionar un canal diferencial sin eliminar por completo la señal.

Compare la velocidad real indicada por el accionamiento con una medición independiente. Un tacómetro portátil, un sensor temporal verificado o una medición adecuada con un osciloscopio pueden determinar si el valor real interno coincide con el movimiento físico.

Si el accionamiento indica velocidad cero mientras el eje gira, la ruta de realimentación es sospechosa. Si el accionamiento indica la velocidad correcta mientras la orden se vuelve incorrecta, es posible que la realimentación funcione normalmente.

Nunca realice una prueba de realimentación exponiendo al personal a una corredera en movimiento. Utilice barreras, velocidad reducida, condiciones de prueba controladas y un método de parada independiente.

Inspeccione todo el circuito de realimentación

Un sistema de realimentación incluye más que el encoder. El sensor, el acoplamiento mecánico, el cable, el conector, la alimentación, el apantallamiento, la disposición de la puesta a tierra, la tarjeta de entrada y la configuración del accionamiento contribuyen al valor medido.

Comience por la conexión mecánica. Confirme que el eje del encoder, la correa, el engranaje o el acoplamiento flexible no puedan patinar. Inspeccione los cubos del acoplamiento, las chavetas, los tornillos prisioneros, las grietas, la contaminación y la desalineación. Un encoder desconectado mecánicamente puede seguir produciendo una señal que ya no represente el movimiento real de la carga.

Inspeccione cada conector con buena iluminación y aumento. Busque contactos desplazados hacia atrás, crimps deficientes, pines doblados, corrosión, contaminación por aceite, alivio de tensión roto y tensión en el cable. Confirme que los conectores de repuesto utilicen el tipo de contacto correcto.

Compruebe la continuidad con la máquina aislada, pero no se base únicamente en una prueba de resistencia estática. Un conductor fracturado puede conducir cuando está recto y quedar abierto al flexionarlo. Durante una prueba aprobada de bajo riesgo, supervise la señal de realimentación mientras la cadena portacables recorre su desplazamiento normal.

Mida la alimentación del encoder en el propio encoder bajo carga operativa. Una tensión estable dentro del armario no demuestra que permanezca estable en el sensor. Registre el valor mínimo durante la aceleración del husillo, la inversión del eje, el frenado y el funcionamiento de los contactores.

En un encoder incremental, inspeccione la amplitud de los canales, la simetría entre canales, la relación de fase y el pulso de índice, si se utiliza. Los pares diferenciales deben mantenerse equilibrados. Las ráfagas de ruido, los pulsos ausentes o la disminución de la amplitud pueden indicar problemas en el cable, el apantallamiento, la alimentación o el sensor.

Verifique el tipo de encoder, el recuento de pulsos, la polaridad, la escala y la fuente de realimentación en el juego de parámetros instalado del accionamiento. No dé por supuesto que un número de parámetro de otro manual de MASTERDRIVES se aplica a esta tarjeta de control.

Los errores de USS no deben reducirse a simples cambios aleatorios de bits

La comunicación USS funciona mediante un telegrama estructurado. El protocolo incluye comprobación de errores, por lo que normalmente un telegrama dañado debería rechazarse en lugar de aceptarse como una consigna de velocidad válida no relacionada.

Esto no significa que se pueda ignorar USS. Los problemas de comunicación aún pueden contribuir a un funcionamiento descontrolado debido al comportamiento de la aplicación. El PLC puede formar una palabra de datos de proceso incorrecta. Un valor con signo puede interpretarse incorrectamente. Los bytes alto y bajo pueden intercambiarse. Es posible que queden datos antiguos en un búfer de transmisión. La ausencia de una respuesta puede dejar activa la consigna anterior.

Las direcciones de esclavo duplicadas también pueden generar un comportamiento confuso. Cada accionamiento de la red debe utilizar una dirección única. La secuencia de consulta del PLC debe asociar cada respuesta con el esclavo correcto y con el área de memoria correcta.

La palabra de control merece la misma atención que la consigna de velocidad. Un accionamiento puede permanecer habilitado mientras el programa del PLC supone que se ha detenido. El reconocimiento de fallos, los comandos de marcha/parada, los bits de dirección y la lógica de rearranque pueden procesarse incorrectamente durante la recuperación de la comunicación.

Cuente las transacciones correctas, los tiempos de espera agotados, las tramas rechazadas, los fallos consecutivos y los eventos de recuperación. Un único bit de «fallo de comunicación» proporciona muy poca información. Los datos de diagnóstico deben identificar qué esclavo se estaba consultando y qué transacción falló.

En el MICROMASTER 440, P2010 corresponde a la configuración de la velocidad en baudios de USS. No debe tratarse como un ajuste general del tiempo de espera del telegrama. P2011 suele estar asociado con la dirección USS. No obstante, todos los significados de los parámetros deben verificarse en el manual correcto del MM440 y en la configuración de la interfaz.

Un tiempo de espera más largo no es automáticamente más seguro. Si el accionamiento sigue utilizando una consigna distinta de cero anterior mientras espera el tiempo de espera, aumentar ese retraso puede prolongar el movimiento no deseado. Primero defina la respuesta necesaria ante una pérdida de comunicación.

La capa física RS-485 sigue siendo importante

Aunque se rechacen las tramas corruptas, una red RS-485 inestable puede provocar reintentos repetidos, datos obsoletos, actualizaciones de estado perdidas y una temporización irregular de la aplicación. Por lo tanto, la red física requiere una auditoría completa.

Documente el bus desde el puerto de comunicación del S7-200 hasta cada accionamiento. Confirme que el cableado utilice una topología de línea adecuada. Las derivaciones largas en estrella pueden generar reflexiones y deben evitarse, a menos que la documentación de la interfaz instalada las permita explícitamente.

Verifique que todos los dispositivos utilicen configuraciones de comunicación compatibles. Estas incluyen la velocidad en baudios, la paridad, la estructura del telegrama, la longitud de los datos de proceso y la dirección del esclavo. Registre la configuración en lugar de cambiarla de memoria.

La terminación debe cumplir los requisitos de las interfaces y los conectores Siemens reales. No se debe añadir automáticamente una resistencia genérica de 120 ohmios. Una terminación o polarización incorrectas pueden empeorar la señal.

Inspeccione el tipo de cable de comunicación, la continuidad del blindaje, la conexión equipotencial de los conectores y el tendido. El cable RS-485 no debe recorrer largas distancias junto a cables de salida de motores, conductores de resistencias de frenado, cableado de contactores u otros circuitos de potencia de alta frecuencia.

Cuando la separación sea limitada, cruce los cables de potencia y de señal aproximadamente en ángulo recto. Mantenga una unión equipotencial deliberada entre los armarios y las secciones de la máquina. Evite los tramos largos de blindaje que reducen la eficacia a alta frecuencia.

Cuando sea necesario, utilice una sonda diferencial de osciloscopio adecuada para inspeccionar la forma de onda. Busque reflexiones, tensión excesiva de modo común, oscilaciones, flancos lentos, ráfagas de ruido y cambios de amplitud durante la aceleración del husillo o el frenado del eje.

Un portátil conectado o un convertidor USB pueden alterar la puesta a tierra y la carga del bus. Registre si la falla cambia cuando se conecta el equipo de diagnóstico.

Los componentes utilizados en la comunicación y las redes industriales deben evaluarse junto con la topología, el blindaje, la terminación, el direccionamiento y la gestión de transacciones del PLC. Reemplazar un conector no corregirá una máquina de estados de comunicación inestable.

Revise el programa S7-200 como una máquina de estados

Las fallas intermitentes durante la puesta en marcha suelen aparecer durante las transiciones y no durante el funcionamiento estable. La máquina puede comportarse correctamente mientras funciona de manera continua, pero fallar al cambiar entre el modo manual y el automático, completar la búsqueda de origen, recuperarse de una alarma, cambiar una receta o restablecer la comunicación.

Busque en las referencias cruzadas del programa cada instrucción que escriba en las variables finales de velocidad, dirección y habilitación. Los programas antiguos suelen escribir la misma palabra de memoria V en varias redes. La última escritura ejecutada controla el resultado, lo que puede producir un comportamiento que parece aleatorio.

Cree una etapa clara de arbitraje de comandos. El movimiento manual por impulsos, el movimiento automático, la búsqueda de origen, las funciones de configuración y los comandos de mantenimiento deben ingresar a esa etapa como solicitudes independientes. El valor de consigna final debe generarse únicamente después de validar el modo, los límites, la realimentación, la comunicación y los permisos de seguridad.

Revise la lógica de pulsos únicos y detección de flancos. Un comando previsto para un solo ciclo de escaneo puede permanecer activo porque su memoria de flanco se reutilizó, retuvo o sobrescribió. Un comando también puede volver a activarse cuando cambia un bit de modo.

Examine cada enclavamiento. Identifique la condición que lo activa y cada condición que lo restablece. Un enclavamiento de movimiento que depende únicamente de un paso posterior de la secuencia puede permanecer activo cuando la secuencia se interrumpe por una falla.

Compruebe el tratamiento de los datos con signo. Un entero negativo interpretado como una palabra sin signo puede convertirse en un valor positivo grande. La multiplicación puede provocar un desbordamiento. Una palabra copiada con el orden de bytes incorrecto puede crear una consigna extrema.

Verifique la conversión de las unidades de ingeniería al valor de proceso USS. Aplique los límites positivo y negativo después del cálculo final, no solo en la entrada del HMI.

Los sistemas de control Siemens SIMATIC S7 antiguos pueden funcionar de forma fiable durante décadas, pero sus aplicaciones suelen contener modificaciones de varias etapas de puesta en servicio. Una revisión estructurada de referencias cruzadas es más valiosa que suponer que el hardware de la CPU se ha vuelto inestable.

Los estados de arranque y recuperación requieren pruebas independientes

Los datos no inicializados o retenidos pueden provocar movimientos imprevistos en raras ocasiones después de interrupciones de alimentación, descargas de software, transiciones de STOP a RUN de la CPU, reinicios del accionamiento o reconexiones del HMI.

Identifique todas las áreas de memoria retentiva utilizadas por el programa de movimiento. Determine el valor inicial del comando de velocidad, la dirección, la habilitación, el modo, el paso de secuencia, los bits de accionamiento manual y el estado de la comunicación después de cada tipo de reinicio.

La rutina de arranque debe forzar a cero todas las solicitudes de movimiento. Debe borrar los comandos de accionamiento manual y automático pendientes, validar la realimentación, confirmar el estado de los límites, establecer la comunicación y exigir una nueva secuencia deliberada de habilitación.

Un valor de consigna distinto de cero retenido nunca debe hacerse efectivo simplemente porque el accionamiento esté preparado antes de que el PLC complete la inicialización.

Pruebe el arranque en frío, el reinicio en caliente, el cambio de STOP a RUN de la CPU, el reinicio del accionamiento, la reconexión del HMI y la restauración de un esclavo USS que haya fallado. Realice estas pruebas con la máquina controlada mecánicamente y con la velocidad disponible reducida.

Supervise la alimentación de control de 24 V durante los eventos de alimentación. El PLC, el encoder, el HMI, la interfaz de comunicación, los contactores y la electrónica de control del accionamiento pueden reiniciarse con distintos umbrales de tensión. Una breve caída de tensión puede dejar un dispositivo funcionando mientras otro se reinicia.

Registre la secuencia de alimentación de control, PLC en RUN, comunicación operativa, accionamiento preparado, liberación del freno y habilitación del movimiento. Ese orden debe ser explícito y repetible.

El HMI puede producir comandos que ya no son visibles

El proyecto del TP 170A debe revisarse junto con el programa del PLC. Es posible que se escriba un comando del HMI al pulsar o liberar un botón, al abrir o cerrar una pantalla, al descargar una receta, al actualizar una etiqueta o al restablecerse la comunicación.

Un botón de accionamiento momentáneo puede crear una condición peligrosa cuando la acción de pulsación establece un bit y la acción de liberación lo borra. Si la comunicación falla mientras el botón está pulsado, es posible que el comando de borrado nunca llegue al PLC.

Posteriormente, el operador ve un botón sin pulsar, pero el bit del PLC permanece activo. Otra transición de modo o condición de habilitación puede entonces permitir que la solicitud de avance manual obsoleta llegue al comando de movimiento final.

Una función de avance manual robusta no debe depender únicamente de una secuencia de pulsación y liberación. El PLC debe requerir una actualización continua del comando, aplicar un tiempo de expiración breve, validar el modo de funcionamiento y eliminar el comando cuando la comunicación deje de ser válida.

Compruebe cada evento del HMI asociado con el avance manual, la introducción de velocidad, la dirección, el restablecimiento, la selección de modo, la búsqueda de origen y el control del ciclo automático. Busque etiquetas duplicadas que apunten a la misma dirección del PLC.

Las entradas numéricas requieren comprobación de rango tanto en el panel como en el PLC. El PLC debe rechazar los valores fuera del rango de ingeniería permitido, aunque el campo del HMI parezca estar configurado correctamente.

Los sistemas HMI SIMATIC de Siemens antiguos pueden contener comportamientos a nivel de pantalla que no son visibles en la lógica del PLC. Registrar por separado la etiqueta sin procesar del HMI y el comando validado del PLC ayuda a identificar el origen real del comando.

El MM440 puede influir en el evento sin controlar el carro

El MICROMASTER 440 controla el husillo, pero aun así puede influir en el entorno de control del carro. Su rectificador de entrada, enlace de CC, salida al motor, circuito de frenado y frecuencia de conmutación pueden generar interferencias conducidas o radiadas.

La perturbación más intensa puede producirse durante la aceleración, la desaceleración, los picos de corriente o el frenado del husillo, y no durante el funcionamiento estable. Compare las marcas de tiempo del movimiento descontrolado con el estado del husillo.

Registre el arranque y la parada del husillo, los cambios de velocidad, la corriente, el estado del bus de CC, el historial de fallos y la actividad de frenado. Determine si cada evento ocurre durante una transición similar del husillo.

Si las unidades MM440 y MASTERDRIVES comparten el bus USS, el husillo también afecta a la temporización de las comunicaciones. El PLC debe consultar a cada esclavo de forma predecible y procesar cada respuesta en la estructura de memoria correcta.

Verifique que las áreas de datos USS del husillo y del carro no se solapen. En algunas aplicaciones compactas con S7-200 se reutiliza la memoria V sin una separación clara. Un bloque escrito para el husillo podría sobrescribir parte del comando del carro.

Mover el MM440 fuera del armario no elimina por completo su influencia. Los cables del motor, las rutas de puesta a tierra, el tendido de las comunicaciones y las fuentes de alimentación compartidas pueden seguir conectados.

Utilice mediciones en lugar de reubicaciones repetidas. Examine la separación de cables, la conexión de las pantallas, las reactancias de línea o los filtros especificados para el variador, la puesta a tierra del armario, la terminación del cable del motor y la relación temporal entre los eventos de conmutación y los errores de comunicación.

Auditar MASTERDRIVES por función de señal

Una auditoría de parámetros de MASTERDRIVES debe seguir toda la ruta de la señal. No comience con una lista de números de parámetros copiada de otra instalación.

Primero verifique la versión de control instalada, la versión de software, la tarjeta de control y la opción de realimentación. Después revise el modo de control, los datos del motor, el tipo de realimentación, la escala de la realimentación y la fuente de realimentación.

Identifique todas las fuentes que pueden controlar los comandos de encendido y apagado del accionamiento. Estas pueden incluir palabras de control USS, entradas de terminales, comandos fijos, conexiones internas de binector o funciones tecnológicas.

Identifique todas las fuentes que pueden contribuir a la consigna final de velocidad o posición. Compruebe la consigna principal, las consignas suplementarias, las velocidades fijas, las funciones de avance lento, las entradas analógicas, las funciones de potenciómetro motorizado y los bloques de funciones internos.

Revise los límites de velocidad positiva y negativa, las rampas de aceleración, las rampas de desaceleración, los límites de corriente, los límites de par y las restricciones de dirección. Unos ajustes temporales conservadores pueden reducir el riesgo durante el diagnóstico, pero no constituyen una protección de seguridad independiente.

Examine la supervisión de la realimentación y la respuesta ante fallos. Determine qué está configurado para hacer el accionamiento cuando la realimentación desaparece, se vuelve inestable, se invierte o resulta inverosímil.

Lea el historial de advertencias y fallos del accionamiento antes de borrarlo. Una advertencia que parezca no estar relacionada puede registrar el momento en que cambió la condición de control.

Utilice el método de ingeniería instalado, como DriveMonitor, la PMU, OP1S u otra interfaz aprobada, para observar los conectores internos y los valores reales. Seleccione los valores según la versión específica del control.

Este enfoque funcional se aplica a los sistemas Siemens de accionamiento y control de movimiento antiguos y actuales. El software de control, las opciones de realimentación y el enrutamiento interno pueden diferir aunque dos accionamientos parezcan físicamente similares.

Crear un registrador de eventos activado por disparo

Un evento que ocurre una vez al día no puede resolverse observando continuamente la HMI. El sistema necesita un registrador de diagnóstico que capture el periodo anterior y posterior al movimiento anómalo.

Cree un búfer circular en el PLC que contenga el comando sin procesar de la HMI, el comando validado, la consigna de velocidad final, la dirección, la habilitación, el modo, el estado de la secuencia, las entradas de los límites, el estado de accionamiento listo, el resultado de la transacción USS y un contador de muestras.

En el accionamiento, capture la palabra de control recibida, la consigna recibida, la consigna interna activa, la velocidad real, el estado de la realimentación, la corriente de salida, la corriente que produce par cuando esté disponible, las advertencias y los fallos.

El disparo puede basarse en una velocidad real superior a un umbral pequeño mientras el comando final del PLC es cero. Otro disparo puede detectar movimiento fuera de un estado de secuencia aprobado. Una discrepancia entre la dirección comandada y la medida también puede activar el registro.

Conserve los datos previos al disparo. Si el registro comienza solo después de que la corredera se haya movido, es posible que la condición que lo inició ya haya desaparecido.

Los diagnósticos de comunicación deben distinguir entre transacciones correctas, respuestas no recibidas, mensajes rechazados, fallos consecutivos y eventos de recuperación. Registre qué esclavo estaba activo durante el error.

Mantenga compacta la lógica de diagnóstico. El S7-200 tiene memoria y capacidad de ciclo limitadas. Confirme que el registro no altere la temporización de las rutinas USS existentes.

Exporte los datos después de cada evento. Guárdelos con la fecha, el estado de la máquina, el informe del testigo y cualquier observación física. Una secuencia de varios eventos puede revelar un patrón que un solo evento no mostraría.

Utilice contadores de diagnóstico que respondan a preguntas específicas

Los contadores solo son útiles cuando su significado está claro. Un contador general de órdenes y un contador general de realimentación pueden divergir por muchas razones normales.

Cuente cada solicitud de movimiento aceptada por la HMI. Cuente cada orden de movimiento aceptada por la arbitraje final del PLC. Cuente cada transmisión USS completada correctamente. Cuente cada respuesta válida recibida del accionamiento del eje.

Cuente también los tiempos de espera agotados de comunicación, los eventos de accionamiento no preparado, las activaciones de límites, los cambios de modo y las expiraciones de órdenes.

Guarde el último valor de velocidad transmitido y la palabra de control. Guarde el último valor real válido recibido y la palabra de estado. Añada un número de secuencia a la estructura de la orden cuando sea práctico.

Cuando ocurre un evento, los contadores pueden responder a varias preguntas:

• ¿La HMI generó una solicitud?
• ¿El PLC aprobó esa solicitud?
• ¿El PLC transmitió un nuevo telegrama?
• ¿El accionamiento devolvió una respuesta válida?
• ¿Comenzó el movimiento real sin una nueva orden aprobada?

No se debe restablecer automáticamente un contador en cada arranque a menos que su valor histórico sea innecesario. Considere guardar un contador de eventos en memoria retentiva y forzar todas las órdenes de movimiento a un valor seguro de arranque.

La protección independiente contra el sobrepaso del recorrido no puede depender de la lógica normal

Los límites de posición por software son valiosos, pero no pueden ser la única defensa contra un fallo que pueda originarse en el programa del PLC, la ruta de comunicación o el controlador normal del accionamiento.

Cada eje debe contar con una protección contra el fin de carrera diseñada correctamente. Según la evaluación de riesgos de la máquina, esto puede incluir interruptores de límite cableados, sensores de posición con clasificación de seguridad, relés de seguridad, circuitos de inhibición del accionamiento, contactores, frenos u otra arquitectura validada.

Una entrada estándar del PLC que escribe una orden de velocidad cero no es automáticamente una función de seguridad. El mismo fallo lógico que provocó el movimiento puede impedir que se procese esa orden de parada.

Eliminar la consigna de velocidad tampoco garantiza la eliminación del par. El accionamiento puede seguir habilitado, puede permanecer activa una consigna secundaria o la energía mecánica almacenada puede continuar moviendo la carga.

Pruebe de forma independiente la parada de emergencia, los enclavamientos de los resguardos, los interruptores de sobrerrecorrido, los contactos de fallo del accionamiento, los frenos y los contactores. Confirme que el rearranque requiere una acción deliberada después de que haya actuado la protección.

Durante las pruebas de diagnóstico, reduzca la velocidad máxima, la aceleración, el par y el recorrido disponible siempre que sea técnicamente posible. Los topes mecánicos temporales solo deben utilizarse si están diseñados para la posible energía del impacto.

Ningún objetivo de diagnóstico justifica exponer a una persona a un eje que ya ha demostrado un movimiento incontrolado.

Caso práctico: Un cable que falla solo durante la inversión

Considere un carro que se comporta normalmente durante las pruebas estáticas lentas, pero se mueve violentamente durante una inversión rápida de dirección. El registro del PLC muestra un comando estable. La traza del accionamiento muestra una perturbación repentina en la velocidad medida, seguida de una gran salida correctiva.

Una prueba de continuidad del cable del encoder resulta satisfactoria mientras la máquina está detenida. Sin embargo, el cable pasa por una cadena portacables móvil. Un conductor está fracturado cerca del radio de curvatura mínimo y se abre solo cuando la cadena alcanza una posición determinada.

Una medición con osciloscopio en la entrada del accionamiento muestra que un canal del encoder colapsa durante la inversión. El comando sigue siendo correcto y no se registra ninguna avería USS.

Se sustituye el cable por el tipo correcto para flexión continua. Se restablecen el alivio de tensión y la terminación del blindaje. La alimentación del encoder y la calidad de la forma de onda se prueban en todo el recorrido del carro.

La verificación final incluye inversiones repetidas a velocidad reducida, seguidas de una operación controlada a velocidad normal de producción. Se almacena una nueva forma de onda correcta como referencia.

Este caso muestra por qué una avería de realimentación debe demostrarse de forma dinámica. Una prueba estática de resistencia puede resultar satisfactoria incluso cuando el cable falla durante el servicio.

Caso práctico: Un comando de avance lento sobrevive a la pérdida de comunicación con la HMI

En otra máquina, al pulsar un botón de avance lento se establece un bit del PLC. Al soltar el botón, se borra. La HMI pierde la comunicación mientras se mantiene pulsado el botón, por lo que el comando de liberación nunca llega al PLC.

En ese momento, otro enclavamiento impide el movimiento. El bit de avance lento obsoleto permanece oculto. Más tarde, el operador cambia el modo de la máquina. La lógica final del PLC ahora acepta la solicitud de avance lento antigua y el carro se mueve inesperadamente.

El accionamiento sigue una consigna legítima del PLC. La comunicación USS funciona correctamente cuando comienza el movimiento. Sustituir el encoder o añadir otra conexión del blindaje no corregirá el problema.

La lógica revisada del PLC requiere una solicitud de avance lento que se actualice continuamente. El comando caduca después de un intervalo breve. Solo se acepta en el modo correcto, con comunicación válida y la condición de habilitación requerida.

La lógica de arranque borra todas las solicitudes de movimiento. La acción de liberación de la HMI permanece, pero ya no es el único mecanismo que elimina el comando.

El registrador de eventos confirma que el bit sin procesar de la HMI permaneció activo después del fallo de comunicación anterior. La causa raíz no fue la corrupción de la comunicación, sino la gestión insegura de un comando válido, pero obsoleto.

Ejemplo de caso: el ruido pone de manifiesto una gestión deficiente del búfer USS

Una tercera máquina experimenta tiempos de espera agotados de USS cuando el husillo acelera. Los telegramas dañados se rechazan, por lo que la red no convierte directamente un comando de velocidad en otro.

Sin embargo, la aplicación del PLC no invalida el comando anterior del eje después de una transacción fallida. La rutina USS también se ejecuta de forma condicional, lo que crea intervalos de sondeo irregulares.

Durante una transición de secuencia, el nuevo comando de cero se escribe en una ubicación de memoria mientras el búfer de transmisión aún contiene un valor antiguo distinto de cero. El siguiente telegrama correcto envía datos válidos, pero obsoletos.

El accionamiento recibe un comando estructurado correctamente y responde con normalidad. La perturbación de la capa física puso al descubierto una debilidad del software, en lugar de generar directamente la consigna.

La acción correctiva mejora el tendido de los cables y la conexión del blindaje. A continuación, se rediseña la rutina de comunicación del PLC para que cada accionamiento utilice memoria dedicada. La consigna final validada se copia en el búfer de transmisión inmediatamente antes de la transacción.

Una respuesta ausente marca los datos como no válidos. La respuesta programada ante la pérdida de comunicación se verifica mediante pruebas controladas.

Este caso demuestra por qué la resolución de problemas de comunicación debe abarcar tanto la forma de onda eléctrica como el ciclo de vida de los datos de la aplicación.

Una secuencia práctica de investigación en el lugar

Paso 1: Asegure la máquina. Establezca una protección independiente contra el sobre recorrido, reduzca la energía de prueba y limite el acceso del personal.

Paso 2: Confirme el hardware. Registre los números de pedido completos, las versiones de software, las placas opcionales, los dispositivos de realimentación y los módulos de interfaz.

Paso 3: Cree copias de seguridad. Guarde el programa del S7-200, el proyecto del TP 170A, el conjunto de parámetros del MASTERDRIVES y los parámetros del MM440.

Paso 4: Defina el evento. Registre la dirección, la velocidad, la duración, el modo de funcionamiento, la posición, el estado del husillo y el comportamiento de parada.

Paso 5: Trace la cadena de comandos. Identifique todas las fuentes de consigna, habilitación, dirección, velocidad fija, avance a impulsos y referencia suplementaria.

Paso 6: Añada un registro sincronizado. Registre los comandos del PLC, los datos USS, los valores internos del accionamiento, la realimentación, la corriente, los límites, las advertencias y los fallos.

Paso 7: Pruebe los estados de arranque. Examine el arranque en frío, el reinicio en caliente, las transiciones de CPU RUN, la reconexión de la HMI y la recuperación de las comunicaciones.

Paso 8: Inspeccione dinámicamente la realimentación. Compruebe la tensión de alimentación, la calidad de la forma de onda, el acoplamiento, los conectores, el blindaje y la flexión de los cables.

Paso 9: Audite USS y RS-485. Compruebe el direccionamiento, la topología, la terminación, las áreas de datos, la temporización y el manejo de errores.

Paso 10: Revise la referencia cruzada del PLC. Encuentre cada elemento que escriba en la consigna final, la dirección y la habilitación del accionamiento.

Paso 11: Audite el enrutamiento de las señales del accionamiento. Verifique cada fuente de comandos y cada elemento que contribuya a la consigna activa.

Paso 12: Cambie un elemento a la vez. Registre el estado anterior, el nuevo estado, el motivo, el resultado de la prueba y el método de reversión.

El refuerzo a largo plazo debe abordar la arquitectura

Después de encontrar la causa inmediata, pregúntese por qué una sola falla pudo producir un movimiento dañino. Un único tiempo de espera de comunicación, una rotura de cable o un error de la HMI no debería eludir todas las capas de protección.

Separe la generación de comandos, la validación de comandos, el transporte de comunicaciones, el control del accionamiento y la protección de seguridad. Cada capa debe tener una responsabilidad definida.

El PLC debe generar un comando acotado y validado según el estado. La rutina de comunicación debe transmitir datos actuales con una validez y vigencia claras. El accionamiento debe aplicar los límites operativos configurados y la supervisión de la realimentación. Las funciones de seguridad independientes deben controlar el movimiento peligroso.

Considere si la arquitectura S7-200 y USS sigue siendo compatible. La migración a una plataforma de PLC y accionamientos más nueva puede mejorar el diagnóstico, el sellado temporal, la disponibilidad de componentes, la visibilidad de la red y la gestión de copias de seguridad.

Una red más nueva no hace que una máquina sea segura automáticamente. PROFINET por sí solo no corrige una arbitraje deficiente de comandos, una lógica de arranque inadecuada ni una protección insuficiente contra el sobre recorrido.

La modernización debe incluir la HMI, los planos, el control de versiones del software, la arquitectura de seguridad, la estrategia de repuestos y la capacitación del personal. Reemplazar únicamente el PLC puede trasladar el problema a otra plataforma.

Para aplicaciones de posicionamiento exigentes, evalúe si el perfil de movimiento debería ejecutarse dentro de un accionamiento o controlador de movimiento dedicado, en lugar de mediante comandos de velocidad serie repetidos. La decisión correcta depende de la precisión de posicionamiento, la sincronización, el tiempo de ciclo, la arquitectura de realimentación y el riesgo de la máquina.

La verificación es más que esperar a que vuelva a producirse la falla

Siete días sin incidentes es alentador, pero no demuestra que se haya eliminado la causa raíz. La verificación debe reproducir deliberadamente las condiciones que anteriormente aumentaban el riesgo.

Ejecute ciclos repetidos de recorrido completo a velocidad controlada. Incluya inversiones rápidas, aceleración del husillo, frenado del husillo, condiciones de armario caliente, carga normal máxima y movimiento del portacables.

Repita las pruebas de arranque y recuperación. Realice ciclos de la alimentación de control según un procedimiento aprobado. Pruebe la transición de PARADA a MARCHA de la CPU, el reinicio del accionamiento, la reconexión de la HMI, la pérdida de un esclavo USS y la restauración de la comunicación.

Verifique la respuesta ante un fallo de realimentación mediante un método de prueba aprobado. No desconecte un encoder de producción mientras haya personal expuesto al movimiento.

Pruebe cada límite de hardware, límite de software, entrada de fallo del accionamiento, parada de emergencia, freno y dispositivo independiente de sobrecarrera. Confirme la respuesta de parada requerida y el comportamiento de reinicio.

Compare la orden final del PLC, la orden recibida por el accionamiento, la consigna interna activa y el movimiento real durante todas las pruebas.

Defina los criterios de aceptación antes de realizar las pruebas. Entre los criterios adecuados pueden incluirse:

• Ningún movimiento no intencionado durante ninguna condición de arranque o recuperación.
• Ningún fallo de comunicación USS sin gestionar.
• Ninguna orden de movimiento retenida tras la pérdida de comunicación con la HMI.
• Alimentación y forma de onda de la realimentación estables durante todo el recorrido.
• Funcionamiento correcto de todos los dispositivos independientes de sobrecarrera.
• Concordancia registrada entre la orden, la consigna recibida, la consigna activa y el movimiento real.

Mantenga el registrador de eventos durante las primeras operaciones de producción. Una acción correctiva exitosa debe eliminar tanto el síntoma físico como el patrón de diagnóstico anómalo que lo provocó.

La causa raíz aparecerá donde las señales discrepen por primera vez

La marcha descontrolada intermitente del carro en un sistema Siemens S7-200 y MASTERDRIVES no debe atribuirse al «ruido», al «encoder» ni a «USS» sin pruebas.

El método decisivo consiste en correlacionar la orden final del PLC, la orden recibida por el accionamiento, la consigna interna activa y la respuesta mecánica real.

Si la orden del PLC se vuelve incorrecta, investigue la HMI y la lógica de la aplicación. Si el valor transmitido o recibido se vuelve incorrecto, investigue la gestión de memoria, el escalado, la construcción del telegrama y la red RS-485.

Si el accionamiento activa una fuente de órdenes que el PLC no pretendía utilizar, audite la configuración interna del accionamiento. Si todas las órdenes siguen siendo seguras mientras el motor acelera, investigue la realimentación, la alimentación de la tarjeta de control, el hardware del accionamiento y la mecánica.

Los fallos de realimentación siguen siendo plausibles, pero deben probarse como circuitos completos. Los problemas de USS siguen siendo plausibles, pero los datos válidos obsoletos y una lógica de recuperación deficiente suelen ser más probables que un telegrama dañado al azar que se convierta en una orden válida de velocidad máxima.

La máquina solo debe volver al servicio normal después de que la protección independiente sea efectiva, el mecanismo iniciador esté respaldado por pruebas registradas y las pruebas controladas hayan verificado tanto la acción correctiva como la respuesta ante fallos futuros.

Este enfoque disciplinado requiere más preparación que sustituir componentes de forma especulativa. También produce un resultado más valioso: una máquina cuya trayectoria de movimiento se comprende, registra, documenta y protege frente al siguiente fallo aislado.