microservicios y diferencia monolítica

¿Problemas de selección de servomotor?kpotenciaHablemos de cómo la arquitectura puede ayudarle a ahorrar preocupaciones

Hace poco tomé té con algunos viejos amigos y hablé sobre el proyecto de automatización en su fábrica. Un hermano que trabaja en una línea de embalaje se estaba rascando la cabeza: la nueva línea de producción necesita servomotores y los parámetros de rendimiento parecen buenos. Sin embargo, siempre hay fallos en el sistema cuando se ejecuta. O la respuesta es medio latido lenta o hay un problema de coordinación entre varios ejes. Se ajustan hacia adelante y hacia atrás, lo que no solo retrasa el período de construcción, sino que también cansa mucho a la gente. Me preguntó: "¿Ustedes, que se dedican a la tecnología, tienen alguna idea de 'de una vez por todas'? No siempre me dejen encontrar la aguja en el pajar entre docenas de modelos de motores".

me recuerda a nosotroskpotenciaUna metáfora que a menudo se discute dentro del equipo. Elegir un sistema de servidor es a veces como elegir una infraestructura para su pila de tecnología: ¿debería utilizar un sistema "monolítico" que empaquete todas las funciones juntas, o debería dividirlo en múltiples "microservicios" independientes y colaborativos?

¿Cuál es el problema? Probablemente no sea el motor en sí.

Cuando muchas personas encuentran un control de movimiento poco fluido, su primera reacción es reemplazarlo con un motor de gama alta o ajustar drásticamente los parámetros. Esto es un poco como una computadora que se congela. Solo desea actualizar la CPU, pero ignora que esto puede deberse a que hay demasiados programas en segundo plano que compiten por los recursos.

En el pensamiento tradicional de "gran general", se tiende a elegir un servocontrolador central extremadamente potente y se espera que maneje todo: desde el bucle de corriente de nivel más bajo, el bucle de velocidad, el control del bucle de posición, hasta la planificación de trayectoria de alto nivel e incluso protocolos de comunicación complejos con la computadora host. Es como un maestro todopoderoso en la fábrica que lo sabe todo. Pero una vez que las órdenes (tareas) se vuelven complejas y cambiantes, la asignación de energía del maestro puede salir mal. El retraso en el cálculo en un enlace puede afectar la sincronización de todo el sistema. Además, actualizar o modificar cualquier parte de las funciones puede afectar a todo el sistema, lo que requerirá que se apague todo el sistema para realizar pruebas, lo cual supone un alto riesgo.

Otra forma de pensar: dejar que cada parte “se especialice en una cosa”

Aquí es donde la idea de la arquitectura de "microservicios" puede inspirarnos. En lugar de depender de un núcleo de control grande y todopoderoso, es mejor dividir las tareas. Imagine que divide una tarea compleja de movimiento coordinado: uno es responsable del posicionamiento de alta velocidad y alta precisión (comokpotenciaAlgunas series) se centran en hacer que la posición en bucle cerrado sea extremadamente robusta; el otro es responsable del suplemento de par de respuesta rápida, centrándose en su rendimiento de par dinámico. Cada uno tiene un "cerebro" independiente (controlador), pero se comunican y trabajan juntos en tiempo real a través de protocolos estándar y eficientes (como EtherCAT, CANopen).

Al hacer esto, de repente quedaron claras muchas preguntas:

• flexibilidad:¿Es necesario actualizar o reemplazar cierto enlace? Sólo necesitas ajustar la unidad "especializada" sin afectar la situación general. Al igual que al actualizar una estación de trabajo en una línea de producción, no es necesario detener toda la línea.
• fiabilidad: Cuando una unidad encuentra interferencia temporal, otras unidades independientes pueden mantener mejor su propia estabilidad y el sistema no colapsará en su conjunto. Los problemas también son más fáciles de localizar y aislar.
• Escalabilidad: Si desea agregar una nueva función en el futuro, como compensación de posicionamiento visual, puede agregar directamente una unidad de "servo visual" dedicada para integrarse perfectamente en el sistema existente en lugar de volcarlo y comenzar de nuevo.

¿Cómo elegir? Mire el límite del "servicio"

Después de hablar de esto, mi amigo preguntó: "Entiendo el principio, pero volviendo a la selección, ¿cómo puedo juzgar si debo utilizar la solución 'integrada' o la solución 'distribuida'?"

Realmente depende de dónde esté el "límite de servicio" de su proyecto. Aquí hay algunas preguntas que puede hacerse:

1. ¿Sus tareas motoras están muy acopladas?Si varios ejes deben engranarse estrechamente como engranajes, sin ninguna desviación, y la lógica es relativamente fija, entonces un sistema de accionamiento "integrado" altamente integrado puede ser más conciso y eficiente. Optimiza toda la coordinación internamente, solo le das una orden general.
2. ¿Su sistema requiere cambios o ampliaciones frecuentes?Si su oficio cambia constantemente, haga esto hoy y agréguelo mañana, o estará seguro de que agregará más módulos en el futuro. Luego, elegir esos servoproductos de "microservicio" que sean fáciles de conectar en red y que tengan interfaces de comunicación abiertas será más fácil a largo plazo. Kpower presta especial atención a esta capacidad de colaboración "plug and play" al diseñar algunas líneas de productos.
3. ¿Qué importancia tiene para usted la resolución de problemas?En una arquitectura distribuida, debido a la modularidad funcional, una vez que ocurre un problema, puede determinar rápidamente si el "Servicio de ubicación" es lento o el "Servicio de torsión" es inestable. En lugar de enfrentarse a una enorme caja negra, todas las luces son normales, pero todo está mal.

Deje que la tecnología adecuada sirva para alcanzar el objetivo final

En el análisis final, ya sea que se trate de arquitectura de software o selección de hardware, no existe ninguna ventaja o desventaja absoluta, solo idoneidad. Cuando Kpower brinda soporte de productos y sugerencias de soluciones, se descubre que cada vez más clientes comienzan a prestar atención a la flexibilidad colaborativa a nivel del sistema, no solo a la velocidad máxima o el par nominal de un solo motor.

Al igual que un buen equipo, no es necesario que cada miembro sea un campeón en todos los aspectos, pero debe tener sus propias fortalezas y una comunicación fluida. La próxima vez que esté preocupado por la selección del servosistema, tal vez pueda salir de la lista de comparaciones de parámetros únicos y pensar en ello desde la perspectiva de la "arquitectura": ¿Qué tipo de "equipo" está formando? ¿El modelo de colaboración de este equipo es comando centralizado o colaboración distribuida?

Desmantelar problemas complejos de control de movimiento y dejar que unidades profesionales se encarguen de tareas profesionales a menudo puede conducir a soluciones más estables, flexibles y orientadas al futuro. Después de todo, nuestro objetivo siempre es hacer que la máquina se mueva de manera suave y confiable, y hacer que el producto sea bueno, en lugar de deambular repetidamente en el atolladero de la depuración y el mantenimiento. Espero que este pensamiento aleatorio pueda brindarte algunas perspectivas diferentes.

Fundada en 2005, Kpower se dedica a la fabricación profesional de unidades de movimiento compactas, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.