Control de versión PLC

Necesito crear un process CM para código PLC.

Actualmente, el sistema se desarrolla utilizando RSLogix 5000. El producto de compilation es un file monolítico que puede cargarse en un PLC para su ejecución y editarse directamente en el entorno de desarrollo. Con múltiples desarrolladores, esto se ha convertido en un problema. Están pisando los cambios de los demás.

Como analogía, es como si, al hacer el desarrollo de Java, la única manera de editar y save la fuente fuera cargar un file * .jar en su IDE, realizar el cambio y luego savelo de nuevo en el file jar. Esto es less que ideal.

¿Cómo puedo coordinar los cambios entre múltiples desarrolladores que trabajan con PLC?

Si estamos hablando de un gran file binary, entonces un VCS (centralizado o descentralizado) no es la mejor herramienta para el trabajo.
Una reference externa (un disco compartido, por ejemplo) donde un lote copyrá y labelrá el estado PCL actual es mejor.
Consulte " Historial de software de seguimiento "

Para evitar discontinuidades en el logging histórico de revisiones, se deben almacenar las versiones anteriores de los progtwigs.
"Sin embargo, damos un paso más. Usando nuestro AutoSave MDT , realmente salimos e interrogamos al equipo. De la noche a la mañana o a la frecuencia especificada, el software lee los progtwigs en los PLC y luego compara esa información con el último progtwig conocido. El software de control de versiones copyrá el nuevo progtwig y lo almacenará y [luego] lo comparará con el último.

Lanzar el control de la versión es bastante simple. Se requiere installation de software y luego configuration de hardware. "Necesitarías un server y un par de semanas de ingeniería y estarás listo", dice Perysyn. Sin embargo, su empresa utiliza un "enfoque de envoltura retráctil" que involucra la installation del software y la personalización por parte de los usuarios que rellenan los espacios en blanco.

Dicho esto, cuando tiene múltiples cambios de múltiples desarrolladores, necesita un entorno de integración donde se pueda realizar y validar una primera entrega antes de enviarla al server real.

Ver también esta publicación .

Uso Unity Pro, por lo que es posible que esto no se aplique a otras marcas.

Unity puede exportar un file "de file" que es XML que describe el progtwig de PLC y la configuration de IO en su totalidad. Después de encargar los cambios, creo una export y la compruebo en mi repository local de Git. Esto me da un historial anotado de cambios, pero no una comparación visual. Siempre puedo usar UnityDiff para comparar.

Consulte http://www.mdtsoft.com/ también

Sobre RSLogix5000 específicamente, he visto a los desarrolladores usar un PLC emulado y hacer sus cambios en línea. El producto final una vez desarrollado se combina con todos los comentarios (ya que no están contenidos en el PLC) y luego se ponen en marcha. Hay problemas con los cambios que no se pueden hacer en línea, como AOI. Existen herramientas para evitar que dos personas editen la misma lógica en línea a la vez y se apropien de las secciones. Las copys de security pueden realizarse en forma de cargas, pero no hay forma de seguir los cambios.

Es un problema complicado, aún más desorderado para cuando se está manteniendo un sistema como se quiere .ACD con el que se puede conectar en línea, ya que a less que se esté haciendo un diff con la herramienta de comparación RSLogix, solo se ve código de máquina ilegible como "+ | Éû³'¬ÙÆW × æ ™ μ,> Ù, "

El control de revisiones más común que he visto (lamentablemente) es simplemente save el último file, luego tomar una copy y agregar la date actual al nombre del file, como la publicación recomendada de control.com descrita.

Necesita un sistema de control de versiones especializado para PLC como VersionDog .

Desde el fabricante:

"Soporte especial con Smart Compares para SIMATIC S5, SIMATIC S7, SIMATIC PCS 7, WinCC, WinCC flexible, InTouch, CoDeSys, TwinCAT, Phoenix PC WORX, RSLogix, Schneider Modsoft, Schneider Concept, Unidad Schneider, SINUMERIK 840D, Bosch IndraWorks y más También los progtwigs de robots de ABB y Kuka y los formattings de datos relacionados con la oficina como Microsoft Word, Microsoft Excel y Adobe PDF son perfectamente compatibles con versiondog.

Actualización: Aquí hay una captura de pantalla que muestra la comparación de la versión de escalera . Supongo que eso es lo que les interesa a la mayoría de los PLC. También lo usamos para progtwigr informes por correo electrónico si las versiones de las aplicaciones PLC en línea y fuera de línea coinciden, como una alarma de que algo ha cambiado en PLC pero no puesto en el server de control de versiones.

Esta es una muy buena pregunta y realmente depende de lo que quieras que haga. Si solo está utilizando un equipo Rockwell, podría ser útil analizar su solución, creo que se llama FactoryTalk AssetCentre. Actualmente estoy buscando usar Bazar de Canonical. Una cosa que VonC señaló es que una pieza de software que puede intercalar el PLC es una ventaja adicional, no es una obligación en mi opinión, pero seguro que ayuda.

¿Estoy leyendo tu pregunta correctamente y tienes varios desarrolladores trabajando con el mismo código de PLC al mismo time? Es una idea aterradora, pero sé que a veces debe suceder, los PLC de Siemens son un poco más fáciles de progtwigr con múltiples desarrolladores, pero yo asignaría a una persona para consolidar y probar todos los cambios antes de comprometerse con el PLC. Cualquier sistema de CVS le permitirá crear sucursales para cada desarrollador, pero la forma en que los conseguiría para consolidar sus cambios es la pregunta del millón de dolares.

Bart.

Una cosa simple sería hacer una diferencia de text en los files .l5k para que pueda ver fácilmente si un desarrollador ha estado jugando con una parte del file que está fuera de su scope.

RSLogix5000 siempre ha prohibido que varios usuarios abran y editen en el mismo .ACD simultáneamente. Sin embargo, si varios usuarios tienen files .ACD idénticos, los abren y todos hacen conexiones con el mismo controller de destino, cada uno de ellos puede editar en el controller simultáneamente, pero solo si están trabajando en rutinas diferentes. Las ediciones de otros aparecen automáticamente, si fueran a mirar otra rutina de progtwigdores.

Tenga en count que trabajar en línea como este se suele hacer con el PLC en funcionamiento, incluso a veces con el sistema de destino (algún tipo de máquina) en funcionamiento. Este tipo de arreglo con el propósito de completar el trabajo más rápido, o en algunos casos porque el sistema es enorme. Nadie se desarrolla así, ya que es una herramienta de debugging y poco práctica para cambios significativos.

Si un progtwigdor finaliza y otro no, el trabajo inacabado del otro se saveá en el .ACD del primer progtwigdor cuando guarden. Quien ahorre el último tendrá el trabajo de todos.

Al igual que otros han mencionado en este hilo, usar la date del file es bastante razonable. Algunas compañías usan una variable de control de versión que generalmente se muestra en una HMI conectada. Otras compañías usan un documento separado que documenta quién y qué cambia. A veces, las notas de la versión se colocan en un comentario de un renglón largo en la rutina principal.

Mi empresa usa un logging de cambios por separado y se mantienen copys de file datedas. Los progtwigdores múltiples solo se usan en los casos más extremos. Alguien siempre está designado para mantener la integridad del file sin connection, generalmente la persona que trabajará más time, o el administrador del proyecto.

Es importante tener en count que los comentarios de los renglones no se transmiten de un usuario a otro antes de RSLogix5000 v21 porque las versiones anteriores no almacenaban comentarios en el controller.

Dicho todo esto, es posible que intentes gestionar el desarrollo sin connection. No he visto ningún método sofisticado para esto. Por lo general, los progtwigdores escriben las rutinas necesarias por separado, y un gerente de proyecto las ensamblará en un solo proyecto. El enfoque más limpio que he visto es donde un gerente de proyecto creará una architecture con funcionalidad global y asignará trabajo de rutina a otros, dándoles una copy de .ACD para trabajar. Devuelven el .ACD con cambios, y el administrador del proyecto copy y pega sus rutinas en el proyecto "maestro".

Vi esta pregunta ahora mismo desde un enlace en el intercambio de stacks: ¿Existen soluciones realists / útiles para el control de código fuente para los progtwigs de lógica de escalera ? En lugar de tener una respuesta de solo un enlace, voy a engañar a mi respuesta aquí:

En realidad, hay una solución enlatada, de GE-IP de todos los lugares. Echa un vistazo a Proficy Change Management. Este producto controla las versiones desde un punto de vista de sistemas de control PLC, en lugar de un control de versión pura del punto de vista de los files; funciona como una capa sobre un VCS (la parte más aterradora es que originalmente este VCS era Visual SourceSafe) y maneja la administración de derechos, informes y pago / checkin.

Si bien el producto es de GE-IP, está diseñado para admitir una variedad de sistemas PLC y HMI listos para usar.

La divulgación completa, utilicé para el trabajo de una empresa que vende e instala PCM (pero eso fue hace 7 años). Entonces, si me preguntas cómo fue en ese entonces, ¡es probable que te diga dónde salió todo!