Ladder CIAA

299 views
Skip to first unread message

Desarrollo electronico

unread,
Apr 23, 2014, 9:51:50 AM4/23/14
to embeb...@googlegroups.com
Hola.
Sigo muy de cerca el proyecto CIAA, quería felicitarlos por la iniciativa y aprovechar para consultarles si alguien a podido avanzar con algo del LADDER para la CIAA.

Tengo experiencia en desarrollo de software (Delphi XE, C++Builder, C#) y compiladores para pics. Programo hace muchos años la linea S7-1200 de Siemens.
Hacer un interprete ladder completo para los distintos micros implicara un gran esfuerzo. 
Alguien esta coordinando este tema específicamente?

Salu2s.

Atte.
Juan Pablo Ayala

Ariel Lutenberg

unread,
Apr 23, 2014, 10:07:40 AM4/23/14
to embebidos32@, J. Ezequiel Espósito, Alvaro Denis Acosta Quesada, Gustavo Alessandrini
Hola Juan Pablo,
Por suerte en los últimos días hemos podido avanzar mucho en lo que es la definición del firmware de la CIAA y justamente este es uno de los puntos que presentaremos en la reunión abierta de hoy a las 18hs en CADIEEL, Av. Córdoba 950 4º piso, CABA.

El tema del hardware ya venía encaminado desde hace tiempo y se terminó de encaminar con la aparición de interesados en desarrollar distintas versiones de la CIAA

Ahora nuestro principal desafío es en el tema del "Ladder CIAA", como vos lo llamas, o más en general la implementación de los lenguajes descriptos en la norma IEC 61131.

Quién está coordinando el desarrollo del software es Ezequiel Espósito, con la colaboración de Gustavo Alessandrini y Alvaro Denis Acosta Quesada entre otros. Pero realmente nos vendría muy bien si podes sumar tu colaboración o si es que aparecen otros interesados en ayudar con el software de PC, que esencialmente implica hacer todo lo necesario para que la CIAA se pueda programar en Ladder y los demás lenguajes de la norma IEC 61131.

En la solapa "software" de la web de la CIAA van a poder encontrar las definiciones en relación con el software:

De paso les comento que ayer se modificó la web de la CIAA para que ahora resulte más claro el status respecto a las siete versiones: ATMEL, FSL, NXP, PIC, RX, ST y TI, y también pusimos un resumen del origen del proyecto, por si alguno tenía dudas o curiosidad al respecto. Los invito a darle un vistazo.

En definitiva, si alguien se ofrece para colaborar en relación con el desarrollo del software de PC de la CIAA entonces por favor que me contacte por correo privado, porque su aporte será muy bienvenido!!!

Saludos,
Ariel.



--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Desarrollo electronico

unread,
Apr 23, 2014, 11:24:28 AM4/23/14
to embeb...@googlegroups.com, J. Ezequiel Espósito, Alvaro Denis Acosta Quesada, Gustavo Alessandrini
Hola Ariel, Gracias por tu respuesta. 
Aprovecho para saludar a mi ex profe Gustavo Alessandrini.
No se si ya tienen algo hecho, pero tal vez podría ayudar con el entorno ladder donde el usuario trabajaría.
Como para describir y que se entienda mejor la idea voy a poner algunas imágenes de un entorno de siemens.

El entorno donde el usuario trabajaría seria algo así:


Imágenes integradas 1

Este entorno tendría un árbol de instrucciones

 Imágenes integradas 2 

También un árbol de proyecto

Imágenes integradas 3

Un lugar donde el usuario pueda poner su bloque de programa:

Imágenes integradas 4
Un árbol de variables

Imágenes integradas 5

El entorno podría estar escrito en cualquier lenguaje preferentemente uno RAD para acelerar el proceso.

Una vez el programa tenga todas las funcionalidades, se pasaría a la etapa de pre compilación donde terminaríamos con un archivo que describiría los bloques ladder que el usuario puso, en que orden, que variables uso y de que tipo. Luego habría que interpretar todo esto para general un código el cual podría cargarse en la memoria SD de la CIAA para luego ser interpretado por los distintos micros. O bien interpretar y generar con la pc los distintos hex.

Espero puedan ampliar y corregir la idea.

Salu2s.

Juan Pablo Ayala

Alvaro Denis

unread,
Apr 23, 2014, 2:59:33 PM4/23/14
to ciaa-s...@googlegroups.com, embeb...@googlegroups.com
Que tal Juan,
Que bueno que tengas una idea clara para poder consultar. Quería comentarte
que Gustavo, Ezequiel y yo estamos suscritos a esta lista, pero sería bueno
que hicieras una petición de pertenencia a ciaa-software(googlegroup) donde
nos encargamos de debatir estos temas.

Aprovecho este mail para hacer una consulta abierta para quien me pueda
responder, si tienes algo que comentar te lo agradezco. Basado en algo
que explicaba uno de nuestros comañeros:
"...Esto está diseñado del lado del software de C++. Los elementos están
jerarquizados según relaciones de herencia. Cada elemento tiene dentro
una estructura de datos serializable y una función que serializa dicha
estructura (la transforma a bytes).

La idea es que al momento del envío del código al firmware (sea por
ethernet, puerto serie, sobre protocolo modbus o no), ese vector de
elementos se serialice a bytes, el firmware reciba el buffer de bytes
y lo vuelva a transformar en un vector de estructuras del lado del
firmware (en lenguaje de programación C).

A medida que en el firmware se va armando el arreglo de estructuras,
se va pidiendo memoria dinámica mediante el RTOS para las variables
de las operaciones y los resultados de las mismas...."

Aquí me surge una duda sobre el guardado de los proyectos, o sea según
creo deberían ser dos funciones no una. La otra sería para el guardado de
los proyectos de manera que el proyecto se pueda guardar y abrir nuevamente,
tengo entendido que en OpenPLC se especifica esto, creo que un XML +-.
Lo otro es que tal vez sería deseable una funcionalidad de "desserialización"
, o sea teniendo un programa en un dispositivo se le debería poder pedir
el código del programa(tal ves incluso con autenticación) y cargarlo nuevamente
en el editor donde se perderían 'unicamente los comentarios ya que no
se serializan
para no sobrecargar el procesamiento del runtime, es esto correcto?

Bueno Juan además comentarte que puedes descargar el código del proyecto
desde el repositorio oficial(https://github.com/ciaa/Software.git) y además
en la wiki(proyecto-ciaa.com.ar) puedes ver información,
que lo que tenemos definido para la GUI es usar Qt5.2, que dices sobre esto?
Además preguntarte si tienes alguna experiencia con boost-spirit como para
saber hasta que punto nos puede ayudar?

Salu2s a todos.




El 23/4/14, Guillermo Guichal <ggui...@emtech.com.ar> escribió:
> Me parecio muy bueno el mail con este ejemplo (por lo menos para mi que no
> he trabajado con Ladder ni PLCs).
>
> Sin estar al tanto de detalles de como va CIAA-SW ni, vale la pena copiar
> este mail en CIAA-SW? O lo que se hará esta claro y bien definido en ese
> grupo ya?
>
> Saludos, Willy
Alcanzarás la grandeza... cuando prescindas de la grandeza de los que están
por encima de tí, cuando hagas que los que están por debajo prescindan de
tu propia grandeza, cuando no seas arrogante con el humilde, ni humilde con
el arrogante!!!

Guillermo Villamayor

unread,
Apr 23, 2014, 3:16:45 PM4/23/14
to embeb...@googlegroups.com, ciaa-s...@googlegroups.com, embeb...@googlegroups.com
Alvaro la serialización puede, mejor dicho debe ser independiente de lo que
vos guardás en el disco. Vos preparás la información para enviarla por
ethernet en el momento que la enviás. Guardás solo las variables que pueden
sufrir cambios en cada proyecto, es decir podría ser que lo que guardás no
sea lo mismo que lo que enviás al dispositivo remoto. Con esto quiero decir
que son dos problemas independientes.

-----Mensaje original-----
From: Alvaro Denis
Sent: Wednesday, April 23, 2014 3:59 PM
To: ciaa-s...@googlegroups.com
Cc: embeb...@googlegroups.com
Subject: [embeb32] Re: Ladder CIAA
Para obtener más opciones, visita https://groups.google.com/d/optout.

Alvaro Denis

unread,
Apr 23, 2014, 3:50:56 PM4/23/14
to embeb...@googlegroups.com, ciaa-s...@googlegroups.com
Y lo que comentaba sobre "desserialización"?, o sea desde el dispositivo
volver a cargar el programa, esto es 'util?, es que nunca he programado un plc
ni usado ninguna de estas herramientas.
Salu2s y gracias.

El 23/4/14, Guillermo Villamayor <gvill...@gmail.com> escribió:

Gustavo Maggiolo

unread,
Apr 23, 2014, 10:41:27 PM4/23/14
to embeb...@googlegroups.com, ciaa-s...@googlegroups.com
Hola a todos,
Juan, estaria muy bueno que el editor ladder de la CIAA sea similar al de siemens!!
Yo hace un tiempo me sume al grupo de ciaa-firmware y comente algunos aspectos de las consideraciones que estas haciendo
respecto al editor de ladder. Tal ves mi error fui publicarlo en la vía equivocada.
Un editor similar estabamos haciendo, en mi empresa, pero el programador que lo hacia ya no esta más. Lo estaba haciendo en WPF.
Un tema importante, que no es menor, son las consistencias eléctricas a la hora de compilar. O las restricciones en las conexiones
cuando se esta haciendo un circuito Ladder.

Alvaro: es muy comun tener que leer el "ladder" de un PLC para modificarlo. El problema es que son muy pocos los PLC
que te guardan en la memoria la lista de simbolos, y en esos casos, es muy dificil seguir un programa.
Te simplifica mucho leer en un programa "MOTOR_ON" que si sólo ves los valores %I0.2 %W23

Espero se entienda mi comentario.
saludos

Gustavo

Guillermo Villamayor

unread,
Apr 23, 2014, 10:50:19 PM4/23/14
to embeb...@googlegroups.com
Eso no es mucho problema supongamos el peor caso ue es que le mandes
directamente el programa en HEX, en ese caso podés tener una rutina que te
lo desensamble.
Serializar en general es poner la información que vos la tenés en forma
estructurada en un formato mas o menos piola para, por ejemplo,
transmitirlo. Yo soy desarrollador de software, no me dedico a la
electrónica industrial pero me imagino que debe haber estándares para las
interfaces del lado del programa y del lado del PLC. Pasar directamente el
ejecutable no me parece una buena política porque si se te rompe la placa y
la cambiás por otra que tenga otro micro tenés que cambiar el HEX. Sería
mejor que el firmware del lado del PLC tenga un pequeño intérprete y vos le
pasas la secuencia de comandos. Pero es un tema de negociación entre el que
hace el programa y el que hace el firmware. Si no se ponen de acuerdo vas a
querer hacer hablar a un chino con un ruso. Pienso que debe haber interfaces
estándard para eso lo mejor es seguirlas lo mas posible.

-----Mensaje original-----
From: Alvaro Denis
Sent: Wednesday, April 23, 2014 4:50 PM
To: embeb...@googlegroups.com
Cc: ciaa-s...@googlegroups.com
Subject: Re: [embeb32] Re: Ladder CIAA

Guillermo Villamayor

unread,
Apr 23, 2014, 10:58:15 PM4/23/14
to embeb...@googlegroups.com
Gustavo una preguntita el editor de Ladder tiene que residir en el PLC??? Para mi tiene que ser un programa externo el PLC tiene que tener un interprete lo mas sencillo posible. En Compiladores e Interpretes lo que decis respecto a las restricciones es una serie de reglas que se llaman “Gramática”. Los distintos dibujitos se llaman “Símbolos Terminales” y las reglas para agrupar los símbolos terminales Gramática. (No confundir con la gramática española). Es una de las primeras cosas que tenés que tener antes de empezar a hacer nada.
 
Saludos
 
Sent: Wednesday, April 23, 2014 11:41 PM
Subject: Re: [embeb32] Re: Ladder CIAA
 

Gustavo Maggiolo

unread,
Apr 24, 2014, 7:52:52 AM4/24/14
to embeb...@googlegroups.com
Guillermo,
Si, tal cual, el editor ladder es externo al PLC. Y es ese editor el que te da todas las características para hacer mas "facil" el diseño con el PLC. Como son las referencias cruzadas, el monitoreo on-line (no confunfir con debug), etc.
En cuanto a la gramática y simbolos terminales totalmente de acuerdo con vos...

saludos

Desarrollo electronico

unread,
Apr 24, 2014, 9:01:51 AM4/24/14
to embeb...@googlegroups.com
Hola Gustavo, los recuerdos que me traen aquellos tiempos de estudio en Parana. 
Me gustaría saber que piensan hacer con el código ladder una vez generado?

El Ladder corre en PC hay que hacer un "Editor". 
Ya con ese dato uno puede hacer una aplicación con todas las funcionalidades para que un usuario programe en ladder, hasta acá solo seria un programa que permite escribir código ladder.

En una segunda etapa el "Editor" genera un archivo de precompilacion (un pseudo ladder o un conjunto de comandos que serán interpretados por el micro de la CIAA).

Y acá la pregunta seria una vez que tenemos el pseudo ladder el programa que hace? 

Compila el pseudo ladder en un hex para los distintos micros de la CIAA
Pro: El programa en el micro de la CIAA seria simplemente un bootloader que levanta el hex y lo corre.
Contras: 
Hacer un compilador para cada micro en PC no es un tema menor.
Hacer el debug en PC pasando del ladder al código de los distintos micros de la CIAA se complica de esta forma.

Compila el pseudo ladder en un grupo de comandos para ser interpretados por los distintos micros de la CIAA
Pro: El programa en PC es mas sencillo a la hora de compilar y no hay que andar lidiando con los distintos micros.
       Hacer el debug es mas sencillo por que básicamente el micro ejecuta comandos ladder.
Contras: 
El programa en el micro de la CIAA seria mas complicado, tiene que poder interpretar los bloques ladder.

A mi parecer veo mas factible definir todos los bloques ladder (por lo menos los básicos para la primera ver.)
Una vez definidos cada bloque ladder tendrá su función homologa en cada micro de la CIAA.
Luego tendríamos que hacer el interprete en cada micro de la CIAA, el cual recibe el pseudocodigo ladder y lo ejecuta. Hacer el debug sencillo de esta forma.

De todas formas para hacer ya hay. Podemos avanzar un montón con el programa. 
Dado a que hacer la interface con todas las funcionalidades visuales para que el usuario pueda escribir su código ladder es independiente del micro al cual sea destinado.

Espero mis comentarios les sean de utilidad.

Salu2s.

Juan Pablo Ayala

Guillermo Villamayor

unread,
Apr 24, 2014, 9:38:26 AM4/24/14
to embeb...@googlegroups.com
Tengo un pro y un contra adicional. En primer lugar seguramente vas a encontrar que cada uno es especialista en un micro y el firmware, si bien se puede armar algo común como un pseudocódigo y que todos tengan mas o menos lo mismo, es particular para cada micro y no es trivial porque aparte de permitirte cargar y ejecutar el programa tiene que poder comunicarse en cualquier momento con el usuario sin interrumpir la operación y atender requerimientos de un BMS para monitoreo y alertas.
La idea del Pseudo Ladder no es tan loca se puede pensar en trabajar con el pseudo ladder y si después se decide enviarle el HEX al micro se hace un driver para cada micro. Para el Debug si se pueden modelar todos los artefactos que van conectados al PLC, se puede hacer un simulados. La pregunta que me hago es ¿hay algún standard para el pseudo ladder?
Lo bueno de esto es que al ser un proyecto colectivo mucha gente puede tirar ideas y eso enriquece mucho. Por eso los que tengan ideas tírenlas porque a veces de una trivialidad sale una idea genial.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a mailto:embebidos32%2Bunsu...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Desarrollo electronico

unread,
Apr 24, 2014, 10:38:50 AM4/24/14
to embeb...@googlegroups.com
Hola Guillermo.

Hay una WEB con standares http://www.plcopen.org/

Con respecto al interprete del pseudocódigo en el micro creo que no sera un problema definido bien el pseudocódigo.
Fíjate que son bloques bien definidos, serian como funciones con sus parámetros de entrada y de salida, si uno los define bien hacerlo en un micro u otro no es tan complicado.

Por ejemplo Este bloque ladder:

Imágenes integradas 1

El primer bloque es leer una posición de memoria y negarla, el bloque esta bien definido.
Tiene como entrada la posición de memoria M1302.0 (significa el bit 0 de la posición 1302).
Y como salida el resultado del estado de esa posición de memoria negada.

El segundo bloque es un comparador, tiene como entrada dos datos:
1- La posición de memoria (MW1300 el W es por WORD (16bit))
2- El valor contra cual quiero comparar (W16#0000) en este caso un 0 numero de 16 bit
Y como salida es resultado de la comparación 1 o 0.

Al final hay un bloque que simplemente hace set (seria como un lach) copia la entrada a la posición de memoria M1302.0 (significa el bit 0 de la posición 1302)

Como veras si estos bloques ladder son bien definidos y hacer unas funciones en C para los distintos micros no es un problema.
Como comentaba antes el código del micro si es mas complicado pero no es tanto.

Con respecto a la comunicación básicamente un PLC resume todo en el mapa de memoria, el micro envia y recibe por ethernet el mapa de memoria.
En el caso de un editor necesitamos todo el mapa para hacer el debug. Pero si estuviera conectado a un Mimico (HMI) solo las variables necesarias. Y claro que a este punto espesaremos a discutir el tema de la latencia.
En un Mimico hay que definir las variables necesarias y con que latencia, por ejemplo una variable de 100ms es una variable rápida (rápida para un HMI pero en un micro en 100ms haces un montón de cosas).

Si quieren puedo armar un ejemplo completo de como se escribe un código en PLC y como se hace un HMI (el HMI es algo necesario para el éxito de la CIAA).

Tal vez para muchos sea trivial el tema de los ejemplos, pero hay muchas personas que son expertos en distintos campos y tener un panorama mas amplio les de nuevas ideas.

Salu2.
Juan Pablo Ayala

Guillermo Villamayor

unread,
Apr 24, 2014, 11:38:56 AM4/24/14
to embeb...@googlegroups.com
Y por lo que veo hay varios Open Source habría que ver que es lo que sirve y lo que no por ejemplo
 
 
 
 
Denme unos dias para ir leyendo un poco
 
Por otro lado no hace falta un programa completo se puede empezar haciendo un amistoso con unos pocos símbolos a ver como nos va.
Bloque de programa.jpg

Gustavator

unread,
Apr 25, 2014, 3:49:24 PM4/25/14
to embeb...@googlegroups.com
Hola a todos!
Vengo siguiendo la charla con respecto a Ladder, tanto como las otras.
El tema es que con el tema del Ladder me parece que nos estamos enquilombando demasiado...
No tengo experiencia en Ladder, recuedo haberlo aprendído en la escuela técnica... hice un par de TPs nomás, nada profesional. El tema es que me había quedado la idea que Ladder es una máquina de estados finitos
FSM  http://es.wikipedia.org/wiki/Aut%C3%B3mata_finito

Esto quiere decir que una vez realizado el programa gráfico, éso se podría traducir automáticamente a código ANSI C, que podría utilizarse en cualquiera de las CIAAs sin un laburo específico para cada una. Parecido a lo que hace Stateflow(Matlab), solo que no tiene la pinta de Ladder y es mas onda objetos...

En lo que habría que poner énfasis, sería en el programa que simularía ése código ladder (que podría compilar el C y evaluar sobre el C).

Como soy consciente que no tengo idea de Ladder, ántes de escribirles busqué en wiki para asegurarme que fuera simplemente una FSM como lo recordaba, y encontré una empresa Cordobesa que ya lo está haciendo!
Por lo que vi ofrecen el software gratis (solo para windorch) tal vez esté piola contactarse.
http://www.slicetex.com/ladder/index.html

Saludos
Gustavo






Mariano Cerdeiro

unread,
Apr 25, 2014, 3:54:38 PM4/25/14
to embeb...@googlegroups.com
Hola Todos,

a mi parecer seria mejor interpretar el ladder. Somos mucho más flexibles, sino hay que traducir a C, instalar un compiladro de la arq. correspondiente, no todos los compiladores son abiertos, tendriamos lio de licencia, o tendria que el usuario bajar sw de ciaa y luego el compilador de otro lado..

Además para cargar el SW abria que flashear sw. En cambio si es interpretado el SW del ciaa Firmware queda igual y e ladder se carga como datos.

Para mi esta segunda opcion es mucho más potente.

Saludos.
Mariano.-


Desarrollo electronico

unread,
Apr 25, 2014, 4:27:39 PM4/25/14
to embeb...@googlegroups.com

Estoy de acuerdo con Mariano. Lo mejor es interpretar los bloques ladder desde la ciaa.

Un punto importante a tener en cuenta es que pasar de ladder a c parecerá sencillo pero a la hora de meter ese código c generado a las distintas familias de micros va a ser un problema.
Mas problemático va ser crear el simulador pare hacer debug si pasamos de ladder a c.

Salu2

Mariano Cerdeiro

unread,
Apr 25, 2014, 4:32:45 PM4/25/14
to embebidos32
Hola Juan,

mis argumentos eran buenos, pero el tuyo termina con la discución por completo. Si quieren hacer debugging del lader, es IMPOSIBLE que lo hagamos en C, va a ser terrible trabajo, además no todos los procesadores soportan hacer debugger de otra aplicación como lo hacen las pcs, osea hacer debugging de una aplicacion desde otra...  que es lo que habria que hacer para hacer debugging del codigo c generado por el ladder. O lo tenes que hacer con un jtag, imposible...

Saludos.
Mariano.-


maidamar

unread,
Apr 25, 2014, 4:38:18 PM4/25/14
to embeb...@googlegroups.com, mcer...@gmail.com
Lo que hace Siemens con el Ladder es convertirlo a un código de máquina intermedio que utilizan sus PLCs (lenguaje AWL). Este lenguaje tiene un estilo assembler en varios aspectos, pero con varias funciones más avanzadas, obviamente. A lo que voy es que tal vez a la gente que esté programando el lenguaje Ladder para la CIAA le sirva saber que hay una equivalencia entre ladder y algo similar a assembler.
De ser necesario se pueden buscar set de instrucciones de ladder (KOP para Siemens) y de AWL para tener una idea de las instrucciones necesarias en una computadora industrial.

Marcos Lazcano

unread,
Apr 25, 2014, 11:09:01 PM4/25/14
to embeb...@googlegroups.com, mcer...@gmail.com
Veo que hay mucha gente orientada a hacer un ladder parecido al de Siemens.
Creo que no podria ser mayor el error, ya que es el menos compatible con la nueva norma de PLC Open, que compatibiliza a nivel de software y hardware las lineas de plc que se adhieren a esa norma.
Ademas tiene los 5 lenguajes de programacion de la IEC, mas uno adicional.
Pueden obtener mas informacion en la pagina de PLC Open:

Pablo Di Giulio

unread,
Apr 26, 2014, 4:36:18 AM4/26/14
to embeb...@googlegroups.com
Gente, hace unos años he trabajado para una empresa haciendo el mismo trabajo, PLC desde cero. He tenido las mismas dicusiones y llegamos a que el minimo lenguaje debia ser IL (Instruction list). El Ladder compilaba a IL y luego se hacia lo compilacion para el procesador (en nuestro caso lo hicimos en ASM al firmware y el set de instrucciones estaba definido con macros). Nosotros trabajabamos con una sola linea de MCU, por lo que era mas facil hacer la abstraccion. 
La IEC61131-3 establece los lenguajes de programacion para un PLC. En mi opinion, creo que si el PLC de la CIAA puede realizarse acorde a la IEC61131 sera un ++ mas para la empresa que desee utilizar este proyecto en sus aplicaciones. En mi poca experiencia en la industria, el sello de standares que el PLC tiene es muy importante para confiar en el producto y las empresas grandes lo ven, lo necesitan y es un argumento importante a la hora de venta.
Espero que les sirva la opinion. 

Adelante y muchos exitos!

Pablo.



Date: Fri, 25 Apr 2014 20:09:01 -0700
From: marcos....@gmail.com
To: embeb...@googlegroups.com
CC: mcer...@gmail.com

Subject: Re: [embeb32] Re: Ladder CIAA

Gustavator

unread,
Apr 26, 2014, 8:44:42 AM4/26/14
to embeb...@googlegroups.com, mcer...@gmail.com
OK. No pensé en lo de las licencias de los copiladores...
Creo que ahora me cierra. Corríjanme si me equivoco por favor.
La idea sería hacer un "firware" que interprete Ladder, convirtiendo a la CIAA en un PLC (mediana o alta gama). De ésta forma, sería posible hacer certificar tanto el "hardware" como el "firmware" para aplicaciones industriales (argumento de fiabilidad y comercial).

En todo caso, si se hace ésto, ya no sería una computadora industrial.
O mejor dicho, sólo el hardware de la plataforma quedaría certificada para ése "firmware" y no otra cosa.
¿Me equivoco?
Salvo que el firmware, use un OS que esté corriendo una aplicación, digamos PLC CIAA, y que al quedar certificado el conjunto SistemaOperativo+Aplicación, quede certificado el OS y ésto permita usarla como compu industrial.
La verdad es que no conozco sobre certificación de software y por éso mis dudas.

Respecto a la robustéz del hardware que andan mencionando, me parece que lo que hay que aclarar es que no es sólo cuestión de componentes electrónicos de mayor calidad, sinó que es todo el conjunto de la placa.
Yo mismo, usando componentes de grado militar/automotive blabla te puedo armar un PCB re-pedorro y suceptible a campos electromagéticos y demás...  lo que importa es certificar el conjunto (trabajé en un lab de EMC para caracterizar MEMS de coches), algo que les adelanto va a ser complejo y caro...  pero éso sería el final de la historia...
Supongo que habría que hablar con las empresas de los micros para ver si quieren garpar la certificación, o se podría hacer algo de "crowdfunding" para financiarlo. Ni idea.

Salu2
PD: aprovecho para agradecerle al señor Cerderio unos apuntes que hizo. Hace unos cuantos años me dieron una buena mano en Técnicas Digitales III - UTN  ;-)

Mariano Cerdeiro

unread,
Apr 26, 2014, 9:47:09 AM4/26/14
to Gustavator, Pablo Di Giulio, embebidos32
Hola Gustavo,

que bueno que los apuntes de TDIII sigan sirviendo... :) Se sigue dando modo protegido? hehe... A mi me encanto el tema, pero programar en assembler sirve para bastante poco... :(

Yo no entiendo nada de Ladder ni de que elementos tiene el lenguaje, pero seguro en el grupo hay mas de un experto. Y es una tema interdisiplinario que tenemos que coordinar al menos entre ciaa Firmware y ciaa Software.

Para mi la idea que el sw ladder se cargue como datos y una aplicacion lo interprete, osea fuera del kernel. Una aplicacion que puede alguien cargar o eliminar, ose asi quiere lader la carga si no lo quiere se ahorra ese espacio. Te dejo un esquematico de la estructura de SW del firmware (todavia en desarrollo, no esta terminado). El documento esta en argouml, envio una imagen.

Cree un ticket en en gitHub https://github.com/ciaa/Firmware/issues/15 para el tema ladder.

@Pablo Di Giulio: por tu mail anterior supongo sabes del tema, que tan complejo es, son 10 operaciones o son 1000? Estoy mirando la IEC 61131-3 pero va a llevar un tiempo son 240 páginas.

Además de gente que sepa, hay alguien que se ocupe del tema, osea un responsable, no digo para firmware ni para software sino para el tema ladder en general?

Saludos.
Mariano.-


FirmwareUML.zargo
ciaaFirmware.png

Ariel Lutenberg

unread,
Apr 26, 2014, 9:58:26 AM4/26/14
to embebidos32@, Gustavo Alessandrini, J. Ezequiel Espósito
Hola,
Sí, efectivamente hay responsables en CIAA-software@ asociados a todo esto que vienen discutiendo.
No sé por qué todavía no respondieron en este hilo, pero los pongo en CC de este correo.
Yo entiendo que hace unos dos meses ellos y el equipo de CIAA-software@ llegaron exactamente a las mismas conclusiones que Ustedes y las empezaron a documentar acá:

Les mando incluso una captura de pantalla del software que empezaron a armar:
Y una versión de eso mismo simplificada que yo uso para presentarlo en Ministerios y Empresas:

Creo que esencialmente ahora lo que faltan son personas con ganas de codificar usando C++, Qt, Boost, Binutils, gcc, newlib y OpenOCD. :)

Saludos,
Ariel.

Juan Manuel Cruz

unread,
Apr 26, 2014, 10:33:52 AM4/26/14
to embeb...@googlegroups.com, gust...@gmail.com, pablo.d...@hotmail.com
Muchachos:

        Me alegra mucho el interés y la pasión con que desarrollan el debate sobre el tema Ladder, especialmente porque tuve la suerte de conocer a unos cuantos de Uds. como alumnos en mi curso de TDII en UTNFRBA y aunque pertenecen a distintas generaciones el ejercicio de la profesión los ha llevado por el camino que alguna vez les mostré como posible.

        Hasta el momento y por falta de tiempo no he podido participar en este tema del proyecto pero en este caso me tomo el atrevimiento de decir que comparto la opinión de Mariano y la interpretación que de la misma ha hecho Gustavo.

        Muchas gracias por la ayuda y a seguir insistiendo a ver si podemos construir un futuro mejor, fuerte abrazo.


        Juan


Ing. Juan Manuel Cruz
Gerente de Ingeniería

Compañía Hasar | Grupo Hasar
Marcos Sastre 2214 | Ricardo Rojas | Tigre
[B1618CSD] Buenos Aires. Argentina
Tel [54 11] 4117 8900 | Fax [54 11] 4117 8998
E-mail:
jmc...@hasar.com
Visítenos en:
www.grupohasar.com
Información legal y política de confidencialidad:
www.grupohasar.com/disclaimer

Guillermo Villamayor

unread,
Apr 26, 2014, 10:43:30 AM4/26/14
to embeb...@googlegroups.com, Gustavator, Pablo Di Giulio, embebidos32
Mariano por lo que parece con este diagrama, es un pequeño sistema operativo con manejo de comunicaciones, memoria y dispositivos. En la parte de Kernel Layer tenés las funciones start() y stop() que podrían servir para ejecutar un programa. Si le mandás un interprete de un código intermedio o directamente el ejecutable para el micro sería lo mismo. Lo que no se es si tiene acceso directo a la memoria principal o si cuando querés leer una posición de memoria en realidad lees un driver y otra cosa es si la SD es parte de la memoria principal o es secundaria. 
 
Sent: Saturday, April 26, 2014 10:47 AM
Subject: Re: [embeb32] Re: Ladder CIAA
 

Guillermo Villamayor

unread,
Apr 26, 2014, 11:28:58 AM4/26/14
to embeb...@googlegroups.com
La arquitectura parece estar mas o menos definida acá
 
 
Pero el diseño está medio verde. O no lo publicaron.
 
Sent: Saturday, April 26, 2014 10:58 AM
Subject: Re: [embeb32] Re: Ladder CIAA
 
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a mailto:embebidos32%2Bunsu...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Ariel Lutenberg

unread,
Apr 26, 2014, 11:51:46 AM4/26/14
to embebidos32@
Guillermo, estás mirando en el lugar equivocado. :)
Fijate que ese archivo que linkeaste es de diciembre de 2012, tal como indica su URL. jaja.
Acá está la información relativamente actualizada, aunque es muy probable que no esté totalmente al día::
Y cómo dije recién, acá hay una captura de pantalla:
Y acá una "versión marketing":

Así que repito que esencialmente ahora lo que faltan son personas con ganas de codificar usando C++, Qt, Boost, Binutils, gcc, newlib y OpenOCD. :)

Saludos,
Ariel.

Guillermo Villamayor

unread,
Apr 26, 2014, 12:14:19 PM4/26/14
to embebidos32@
Lo que pasa es que de allí me mandan a consultar el otro. Igual no importa para los que no nos dedicamos a esto es mucha información de golpe. Ya estoy tratando de leer todos los links y todos los documentos. Tiempo al tiempo, también tengo que trabajar.

Ernesto Gigliotti

unread,
Apr 26, 2014, 12:25:10 PM4/26/14
to embeb...@googlegroups.com
leyendo lo que dijo ariel de usar C++ y Qt para el desarrollo del soft... consideraron la opción python + pyQt ? creo que aceleraría muchísimo el tiempo de desarrollo y quedaría un soft multi-plataforma (windows/linux/mac) casi sin hacer ningún cambio.


Ariel Lutenberg

unread,
Apr 26, 2014, 12:27:32 PM4/26/14
to embebidos32@, J. Ezequiel Espósito, Gustavo Alessandrini, Alvaro Denis Acosta Quesada
No soy experto en el tema, pero entiendo que la gente que está con eso lo discutió y llegó a la conclusión de que lo mejor era C++ y Qt. Pero sería cuestión de que lo hables con ellos directamente.
Pongo a varios de ellos en copia.
Abrazo.

Mariano Cerdeiro

unread,
Apr 26, 2014, 12:32:16 PM4/26/14
to embebidos32
Hola Guillermo,

ahi mejoré un poco el diagrama en funcion a tu comentario.

La idea es hacer un wrapper del OS. Los responsables de SW decidieron que el sistema POSIX (al menos similar a posix). Yo todavia me estoy convenciedo de la idea, pero posix tiene sus ventajas. :)

Las funciones kciaa_start y kciaa_stop estan pensadas para arrancar el software de la ciaa y no el software de ladder.

El software de ladder estaría en la capa superior en donde dice c/c++ Application. Y la parte de ladder seria como datos en flash.

Le LadderLoader podria tener algun tipo de acceso algun canal de comunicación o sobre ModBus (no se si el ModBus esta pensado para flashera tambien?).

Aclaro por si las moscas, por que hay gente hablando de SW y otros del Firmware, los gráficos son del Firmware.

Saludos.
Mariano.-
FirmwareUML.zargo
ciaaFirmware.png

Mariano Cerdeiro

unread,
Apr 26, 2014, 12:39:08 PM4/26/14
to embebidos32, Gustavo Alessandrini, J. Ezequiel Espósito
Hola Gustavo y Ezequiel,

ya esta definido el formato binaro del Ladder osea la salida del ciaa Software y el input del ciaa Firmware? Seria como especifica el standard IEC 61131-3?

Saludos.
Mariano.-

Alvaro Denis

unread,
Apr 26, 2014, 5:33:33 PM4/26/14
to Ariel Lutenberg, embebidos32@, J. Ezequiel Espósito, Gustavo Alessandrini
Que tal Ernesto,
El tema de la portabilidad está resuelto, c++, boost y qt son portables,
lo otro es la manera en que se configure el proyecto, esto lo tenemos
resuelto para linux y windows(mac se puede agregar también) sin hacer
ningún cambio, o sea compilamos con cmake(cross plattaform make).

Por último mencionar que la velocidad de desarrollo se define un poco por
las tecnologias en uso pero casi siempre depende más de las manos en que estén
puestas(las personas), en el equipo tenemos definido c++ porque es lo que
consideramos según nuestra experiencia nos permitir'a avanzar más, de todos
modos comentar que para mi estaría bien que un colaborador haga cualquier
submodulo en otro lenguaje que pueda ser vinculado con c++(ej: python) aunque
en realidad sería algo a considerar entre todos los miembros para valorar
si tiene alguna ventaja la propuesta que se haga.

@Ariel que tal ariel vengo siguiendo el hilo lo que sucede que en estos
momentos estoy teniendo un problema con la configuración de la otra pc que
necesito para las pruebas de rs232, llevo + de 24 horas en eso y no logro,
instalar ggg por eso el silencio...


Salu2s y gracias a todos por sus comentarios.


El 26/4/14, Ariel Lutenberg <ariel_l...@yahoo.es> escribió:
> No soy experto en el tema, pero entiendo que la gente que está con eso lo
> discutió y llegó a la conclusión de que lo mejor era C++ y Qt. Pero sería
> cuestión de que lo hables con ellos directamente.
> Pongo a varios de ellos en copia.
> Abrazo.
>
>
> El 26 de abril de 2014, 13:25, Ernesto Gigliotti
> <ernestog...@gmail.com
>> escribió:
>
>> leyendo lo que dijo ariel de usar C++ y Qt para el desarrollo del soft...
>> consideraron la opción python + pyQt ? creo que aceleraría muchísimo el
>> tiempo de desarrollo y quedaría un soft multi-plataforma
>> (windows/linux/mac) casi sin hacer ningún cambio.
>>
>>
>>
>>
>> El 26 de abril de 2014, 13:14, Guillermo Villamayor
>> <gvill...@gmail.com
>> > escribió:
>>
>> Lo que pasa es que de allí me mandan a consultar el otro. Igual no
>>> importa para los que no nos dedicamos a esto es mucha información de
>>> golpe.
>>> Ya estoy tratando de leer todos los links y todos los documentos. Tiempo
>>> al
>>> tiempo, también tengo que trabajar.
>>>
>>> *From:* Ariel Lutenberg <ariel_l...@yahoo.es>
>>> *Sent:* Saturday, April 26, 2014 12:51 PM
>>> *To:* embebidos32@ <embeb...@googlegroups.com>
>>> *Subject:* Re: [embeb32] Re: Ladder CIAA
>>>
>>> Guillermo, estás mirando en el lugar equivocado. :)
>>> Fijate que ese archivo que linkeaste es de diciembre de 2012, tal como
>>> indica su URL. jaja.
>>> Acá está la información relativamente actualizada, aunque es muy
>>> probable
>>> que no esté totalmente al día::
>>> -
>>> http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=versiones:v1_0:software:inicio
>>>
>>> Y cómo dije recién, acá hay una captura de pantalla:
>>> -
>>> https://www.dropbox.com/s/e6qumvduq3knpv9/Software-ModeloIngenieria.PNG
>>> Y acá una "versión marketing":
>>> - https://www.dropbox.com/s/84l3tkkqhmsi2ur/Software%20Ladder.jpg
>>>
>>> Así que repito que esencialmente ahora lo que faltan son personas con
>>> ganas de codificar usando C++, Qt, Boost, Binutils, gcc, newlib y
>>> OpenOCD.
>>> :)
>>>
>>> Saludos,
>>> Ariel.
>>>
>>>
>>>
>>> El 26 de abril de 2014, 12:28, Guillermo Villamayor <
>>> gvill...@gmail.com> escribió:
>>>
>>>> La arquitectura parece estar mas o menos definida acá
>>>>
>>>>
>>>> http://www.sase.com.ar/asociacion-civil-sistemas-embebidos/files/2013/12/CIAA-Software-v1.0.pdf
>>>>
>>>> Pero el diseño está medio verde. O no lo publicaron.
>>>>
>>>> *From:* Ariel Lutenberg <ariel_l...@yahoo.es>
>>>> *Sent:* Saturday, April 26, 2014 10:58 AM
>>>> *To:* embebidos32@ <embeb...@googlegroups.com>
>>>> *Cc:* Gustavo Alessandrini <galess...@gmail.com> ; J. Ezequiel
>>>> Espósito <ezequiel...@gmail.com>
>>>> *Subject:* Re: [embeb32] Re: Ladder CIAA
>>>>
>>>> Hola,
>>>> Sí, efectivamente hay responsables en CIAA-software@ asociados a todo
>>>> esto que vienen discutiendo.
>>>> No sé por qué todavía no respondieron en este hilo, pero los pongo en
>>>> CC
>>>> de este correo.
>>>> Yo entiendo que hace unos dos meses ellos y el equipo de
>>>> CIAA-software@llegaron exactamente a las mismas conclusiones que Ustedes
>>>>> https://github.com/ciaa/Firmware/issues/15para el tema ladder.
>>>>> mailto:embebidos32%2Bunsu...@googlegroups.com<embebidos32%2Bunsu...@googlegroups.com>.
>>>>> Para más opciones, visita el sitio del grupo en
>>>>> https://groups.google.com/d/forum/embebidos32?hl=es
>>>>>
>>>>> ---
>>>>> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32"
>>>>> de Grupos de Google.
>>>>> Para anular la suscripción a este grupo y dejar de recibir sus
>>>>> mensajes, envía un correo electrónico a
>>>>> embebidos32...@googlegroups.com.
>>>>> Para acceder a más opciones, visita
>>>>> https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>>> -- Recibiste este mensaje porque estás suscripto al Grupo Google
>>>> Embebidos32. Para postear en este grupo, escribe un email a
>>>> embeb...@googlegroups.com. Para des-suscribirte, envía un email a
>>>> mailto:embebidos32%2Bunsu...@googlegroups.com<embebidos32%2Bunsu...@googlegroups.com>.
>>>> Para más opciones, visita el sitio del grupo en
>>>> https://groups.google.com/d/forum/embebidos32?hl=es
>>>> ---
>>>> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32"
>>>> de Grupos de Google.
>>>> Para anular la suscripción a este grupo y dejar de recibir sus
>>>> mensajes,
>>>> envía un correo electrónico a embebidos32...@googlegroups.com.
>>>> Para acceder a más opciones, visita https://groups.google.com/d/optout.
>>>> --
>>>> -- Recibiste este mensaje porque estás suscripto al Grupo Google
>>>> Embebidos32. Para postear en este grupo, escribe un email a
>>>> embeb...@googlegroups.com. Para des-suscribirte, envía un email a
>>>> mailto:embebidos32%2Bunsu...@googlegroups.com<embebidos32%2Bunsu...@googlegroups.com>.

Ernesto Gigliotti

unread,
Apr 26, 2014, 6:12:59 PM4/26/14
to embeb...@googlegroups.com
Gracias Alvaro por responder, yo lo tiraba como idea porque donde trabajo lo empezamos a usar y la verdad que estoy sorprendido de lo rápido que se avanza, pero sí, tenés razón, que va mucho en los programadores, y si se sienten más cómodos con C++ no hay nada que discutir, jeje.

saludos!


Para obtener más opciones, visita https://groups.google.com/d/optout.

Ezequiel Espósito

unread,
Apr 26, 2014, 9:23:51 PM4/26/14
to embeb...@googlegroups.com
Hola buenas noches,

Disculpen la demora en responder, pero los últimos días estuvimos enfocados en el diseño de la arquitectura del firmware de la CIAA.

Respecto a las cuestiones relacionadas al software de la CIAA, que se estuvieron discutiendo en este hilo, ya se tomaron unas cuantas decisiones de diseño.

Por un lado, se utilizará el estándar IEC61131-3. Este estándar define los elementos básicos de un lenguaje de programación y diferentes formas de codificarlo. En la primera versión del software de la CIAA, se implementarán las codificaciones IL (Intruction List) y Ladder. El diseño del software se esta realizando de manera tal, que cada instrucción codificada en IL o en Ladder sea mapeada a los elementos básicos definidos en IEC61131-3. De esta manera, será posible traducir de IL a Ladder o viceversa de manera automática.

También se diseño una estructura de clases que permite guardar en un vector de estructuras de datos las diferentes instrucciones de un programa. Estas estructuras, por medio de los mecanismos de herencia y polimorfismo, permiten almacenar toda la información que los diferentes tipos de instrucciones del estándar requieren. Una vez generado el programa, este vector de estructuras se serializa (se transforma a bytes) para enviarlo al firmware o para almacenarlo en el disco rígido de una PC. De esta manera se reduce al mínimo el parser del microcontrolador, ya que cada posición del vector es una estructura que contiene toda la información para ejecutar una instrucción (dirección de memoria de las variables, puntero a función de la operación, etc.). En un principio el programa serializado será transmitido mediante Modbus al firmware y será almacenado en la Flash/SD y levantado a RAM en el momento de la ejecución.

Finalmente, ahora estamos trabajando en cuestiones relacionadas con la sintaxis y la semántica de las codificaciones IL y Ladder, ya que software hará las verificaciones correspondientes antes de enviar al firmware el programa. El software conocerá el mapa de memoria de las diferentes versiones de la CIAA, para también verificar si un programa es compatible con los recursos del firmware/hardware particular.

Espero haber aclarado las cuestiones de diseño del software de la CIAA.

Saludos.
Ezequiel Espósito
Reply all
Reply to author
Forward
0 new messages