CIAA: Novedades

[Pablo Ridolfi]

Estimados,

Escribo para contarles cómo venimos con el Hardware y otros aspectos relacionados de la CIAA. Esta semana fue un poco intensa en mensajes, creo que principalmente por la nota en LN, y nos pareció adecuado compartir con ustedes el avance concreto del proyecto.

A grandes rasgos, respecto al hardware:

- CIAA-NXP: El diseño del PCB está terminado. Estamos revisándolo con mucho detenimiento y haciéndole correcciones menores (silkscreen, ancho de pistas, chequeo de footprints, etc.) antes de enviarlo a fabricación. Estimo que entre esta semana y la próxima estaremos armando los primeros 5 prototipos para probarlos internamente.

- CIAA-Freescale: El diseño del PCB está muy avanzado. Los interesados pueden consultar detalles con Ignacio Zaradnik (i...@electrocomponentes.com).

- CIAA-ST: Se está finalizando la adaptación del esquemático al STM32F4. El que lleva la batuta es José Fuentes (josecarl...@gmail.com).

Y me complace mucho contarles que hemos comenzado el diseño de dos profiles nuevos de la CIAA (ya lo habrán visto en hilos anteriores):

- CIAA-Microchip con PIC32, cuyo referente es el ing. César Fuoco (cesar...@elemon.com.ar).

- CIAA-RX con Renesas RX600, llevado adelante por Jaime Aranguren (jaime.a...@gmail.com).

En nombre del equipo de de desarrollo del hardware quiero hacer una mención especial al Ing. Mauro Koenig (mko...@emtech.com.ar) que se tomó el (para nada trivial) trabajo de rutear el PCB la CIAA-NXP. Creemos que ha hecho un trabajo excelente utilizando KiCad. Mauro trabaja junto a Martín Ribelotta (mribe...@emtech.com.ar) en Emtech, empresa dirigida por Guillermo Guichal (ggui...@emtech.com.ar). Ellos dos también vienen haciendo aportes significativos y compartiendo su extenso know-how desde las primeras etapas del proyecto. Mi sincero agradecimiento a todos ellos.

A continuación les pego un render del PCB de la CIAA-NXP (aún tenemos que acomodar un poco el silkscreen).

Respecto al firmware, estamos comenzando a avanzar en el diseño del RTOS, y la API/BSP. Tuvimos oportunidad de reunirnos con una persona de muchísima experiencia (>25 años) en control industrial, y una de las recomendaciones que nos hizo es que incluyamos Profibus DP en la CIAA. Así que decidimos modificar el circuito de la interfaz RS 485 para que soporte este protocolo, que por supuesto estará contemplado también en el firmware. Invito a mis colegas Juan Cecconi y Gustavo Alessandrini a completar esta información si lo creen necesario.

Como siempre estamos atentos a sus comentarios y sugerencias, así como a cualquier consulta que nos quieran hacer.

Saludos cordiales y buen fin de semana.

Ing. Pablo Ridolfi (FI-UBA/UTN-FRBA/UTN-FRH)

Responsable de Hardware / Subresponsable de Firmware de la 

Computadora Industrial Abierta Argentina

[Jaime Andrés Aranguren Cardona]

Hola Pablo,

 

Primero, gracias por el avance resumido. Desafortunadamente no pude ver el render, es problema de Google? O sera mío (Internet Explorer 9)?

 

Por otro lado, Profibus DP. Interesante, me gusta. Pero:

• Recuerdo que en algún momento existió una discusión sobre si agregar CAN a la CIAA o no, con el argumento en contra de que CAN no es abierto/no propietario (inventado por Bosch, aunque se usa por montones) y para usarlo con todo rigor en sabores como CANOpen (lo más usado en la Industria) se necesitarían certificaciones y membresías, a pesar de existir implementaciones de código abierto como CANFestival. Al final se dejó CAN en la CIAA para futuros usos. En fin, un transceiver para el controlador CAN del respectivo MCU. El stack es otro asunto, creo que no resuelto aun. Me corriges por favor.
• Profinet va mucho mas alla de la capa física (RS-485 es una de las varias posibilidades). Incluso si así fuera, las velocidades pueden llegar a 12 Mbps, lo cual no es nada trivial de manejar via software Incluso, no estoy seguro de que todos los MCUs de la CIAA tengan UARTs que puedan llegar a esa velocidad. Y menos aun si se considera que Profibus maneja las capas 2 y 7 de OSI, entonces surge la pregunta: es la idea hacer una implementación de Profibus en SW en el MCU? Esto implica conseguir los estándares en IEC ($$$), más todo lo que involucra implementar y validar la implementación. En particular, en la capa de enlace de datos, el manejo del bit / frame timing no es nada trivial. Es la idea ir por esa ruta? De todas formas, existen ASICs para este fin, como los de Profichip, en particular siendo interesantes el VPC3+C y el VPC3+S. O las soluciones de HMS, tales como el B30-DPV1. Y en todo caso sigue pendiente el tema de menbresías, certificaiones, etc... Supongo que si es como ejercicio académico no es tan problemático, pero si es para sacar un producto al mercado, ese es otro cantar. Y si a eso le sumamos las discusiones filosóficas relacionadas con ser abierto, no propietario, independiente de fabricantes, muy bajo costo, disponibilidad en Argentina, etc, las cosas se van volviendo más complicadas. Cuál es entonces el norte con relacion a Profibus en la CIAA? Repito: me gusta y me interesa, pero la cosa vá mucho más allá de eso.

Saludos,

 

Jaime Aranguren

[Jaime Andrés Aranguren Cardona]

Corrijo:

 

Escribí: "Profinet va mucho mas alla... "

 

Lo correcto es: "Profibus va mucho mas alla... "

 

Saludos.

[Pablo Ridolfi]

Hola Jaime,

Te adjunto la foto del render a ver si la podés ver, fijate en los adjuntos de este correo. :-)

Aclaro que no soy para nada experto en Profibus. Quizás Juan (en copia) pueda aportarnos información más concreta.

Sí te puedo decir que desde el punto de vista del hardware de la CIAA, ser compatible con Profibus DP requiere solamente cambiar el transceiver RS485 por uno que además admita las especificaciones eléctricas que requiere este protocolo y los resistores del bus. Es un cambio que impacta muy levemente en el hardware como está hoy.

Por eso adoptamos una filosofía parecida al caso CAN: Que esté soportado por el hardware. Luego, si el estándar es abierto, lo implementamos en el firmware. Si no es abierto, y el usuario de la CIAA dispone de las licencias correspondientes, él mismo lo puede implementar y utilizarlo sin problemas, porque el hardware lo va a soportar. ¿Se entiende la postura?

Saludos,

Pablo.

--
-- 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.

[Juan Cecconi]

Hola Jaime,
        En relación con CAN, adjunto un extracto de un libro que trata sobre el tema donde menciona el asunto de las regalías. Yo ciertamente no me preocuparía por eso.
De manera común a Profibus y CAN, en ambos está resuelta sólo la capa física del mismo, es decir, que ciertamente queda un gran trabajo por hacer en el firmware / software para luego implementar las capas superiores. El tema de la certificación será un tema a tratar, porque coincido que académicamente no es necesario, pero luego para llegar a la industria lo será sobre todo en aplicaciones de envergadura. No lo tengo claro, quizás lo puedan realizar las empresas interesadas, o algún organismo apoye la iniciativa y cubra la certificación llegado el caso...no lo se.
En lo que al Hard refiere, el Profibus DP a implementar está basado en RS485 para profibus (SN65HVD1176) pero tenemos la limitación que la UART del micro llega a 8 Mbit/s (con 16 Bytes de buffer y DMA) con lo cual hoy no llegaríamos a cubrir los 12 Mbit/s de máxima. Tenemos un procesador ARM dual core de 200MHz, que en principio creemos alcanzará para implementar las capas superiores conjuntamente con las demás tareas.  Respecto al estándar IEC 61158-x es cierto que se paga, pero también es cierto que se consiguen en la web (en el emule x ejemplo) y para un proyecto abierto - colaborativo donde participa mucha gente eso está bueno. La realidad es que esta primer versión de la CIAA plantea muchos desafíos e interrogantes, será la piedra angular de algo que esperamos sea muy grande pero que seguramente en un futuro será distinta a como la estamos por ver nacer hoy. Posiblemente las próximas versiones, o incluso los otros sabores de la CIAA (Freescale,  ST, Microchip, etc) puedan llegar a tener cambios, un ASIC como los mencionados que resuelvan el tema, o modificar Hard que con esta versión veamos que no alcanzó, pero creo que sin tener la experiencia previa es difícil saberlo. La realidad es que hoy la CIAA está por salir a la luz luego de mucho (mucho) trabajo colaborativo y tratamos de abarcar bastante (232 / 485 / CAN / USB / Eth / I-O / 4-20mA / 0-10V), esperamos cosechar experiencia para volver a la carga con las mejoras que hagan falta, o que empresas hagan las mejoras que necesiten basados en este modelo.
Saludos
Juan

[Jaime Andrés Aranguren Cardona]

Hola Pablo,

 

Gracias por las clarificaciones.

 

1. Render. Si, lo veo. 4 capas? 6? 2?

2. Profibus. Se entiende la postura, y creo que es importante que esto esté puesto sobre la mesa al iniciar, para tener claras las expectativas, para todos los involucrados.

 

Saludos,

 

Jaime Aranguren

[Juan Cecconi]

4 capas apuntando a que pueda fabricarse en el país. Objetivamente se hubiesen necesitado 2 más porque Mauro tuvo que hacer malabares para rutearla y hubo que sacrificar parte de los planos internos para trazas de señal.
Saludos
Juan Cecconi

[Juan Cecconi]

Quizás este doc conteste muchos de los interrogantes sobre la implementación de profibus DP. Es muy similar al caso de la CIAA, en un ARM LPC2148 y también es un proyecto abierto.
Saludos
Juan

[Marcos Lazcano]

Intento ofrecer mi ayuda para lo que sea necesario, en el proyecto de la versión Microchip.

Mi correo creo que esta publicado, sino contactarme por aquí mismo.

[Jaime Andrés Aranguren Cardona]

Hola,

 

Si, si muy interesante, de hecho ya lo conocía. Pero la viabilidad no está garantizada, si se quiere hacer algo en serio con fines comerciales -no necesariamente el caso de la CIAA dotada de Profibus DP-. En el website de los mismos autores:

 

• "What is the statement of the PROFIBUS International?

This is a part of the email exchanged between the PBMaster project and the PI chairman:

 

"PROFIBUS is not free of patents. But anyway, we ourselves do not want to become PROFIBUS an Open Source technology. It is important not to mix the words "open" and "open source". Of course, PROFIBUS is an open industry standard available for everybody in the world."

 

We have to respect the patent limitation, but I personally do not agree that PROFIBUS is an open industry standard and available for everybody in the world. The specification is not available for free and implementing a device (primarily a master station) not using a proprietary ASIC a long with not being a member of PI leads to infringement of the patent rules."

 

Hombre: que un estandar o protocolo sea abiero, no quiere decir que las especificaciones sean gratuitas, ni que las implementaciones puedan hacerse a nombre del estándar sin pagar la membresía a un consorcio, ni que no se deba pasar una cualificacion y certificacion por un laboratorio autorizado. Es triste, y es costoso, pero es la unica manera de asegurar la interoperabilidad y la estabilidad de un protocolo. Además, si se tuviera conciencia de lo que implica desarrollar y establecer un protocolo estandarizado de comunicaciones, se entendería mejor que la inversion realizada debe ser recuperada de alguna manera.

 

Que sea abierto quiere decir que no es cerrado, es decir, se pueden hacer implementaciones por otros, registrandose en el consorcio y haciendo que la implementacion esté cualificada y certificada.

 

Sin ir muy lejos, otro ejemplo es FreakZ, y ya sabemos lo que pasó:

 

"written by Akiba, February 13, 2013

The FreakZ stack and sim haven't been updated since 2008. I had a falling out with the Zigbee Alliance way back when and decided to stop development on it. The simulator hasn't been updated and I wouldn't use it.
Sorry about that."

 

Muy diferente la historia sería si este tipo de protocolos son concebidos desde el principio para ser, no solamente abiertos, sino de fuente abierta. Sigue siendo una piedra en el zapato el tema de interoperabilidad y certificaciones. Quien asume los gastos?

 

De todas maneras, volviendo a Profibus:

 

• "What will be with the PBMaster project now?

I keep on the development now as a close-source solution for a company. This is a way how to keep the development and go ahead with the project. The implementation is available as a proprietary solution until the patent limitation is valid. I do not want to provide the code under a non-GPL license, as most of the companies would never contribute back their improvements to the community."

Al parecer hay luz al final del camino:

• "Will the source code be available in the future?

This is what I hope to be happened. According to my study, the patents affecting the master implementation should expire by the end of 2012. Hence, as I hope, there will be no obstruction, which would avoid me to release the code to the open-source community."

 

2012 paso hace rato. Alguien pudo encontrar PBMaster? Sourceforge está vacio.

 

Saludos,

 

Jaime Aranguren

[Juan Cecconi]

Interesante el faq de temas relacionados con las patentes, el proyecto y profibus. Será un buen punto a debatir. Sin dudas desde lo académico es muy interesante el desarrollo de la implementación en firmware y por lo que menciona el artículo después no pueda publicarse abiertamente, lo cual va en contra de los principios de la ciaa. Y por otro lado el que quiera comercializarla debería utilizar un ASIC de alguno del consorcio en una versión nueva, o incluirlo en alguna versión de la ciaa ...
Lo veo un tema espinoso que tendremos que ver en detalle.
Saludos
Juan

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/iC16oNtmK4c/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

[Juan Manuel Cruz]

Pablo:

        Quien suelde esa placa tendrá problemas, la máscara de componentes pisa algunos PAD´s en los que no soldarán los componetes, podemos verlo esta noche, saludos.

        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

[Pablo Ridolfi]

Hola Juan, no te preocupes, justamente el silkscreen es uno de los layers que todavía debemos acomodar bien antes de enviar el PCB a fabricación. Todavía estamos haciendo la revisión eléctrica.

Saludos,

Pablo.

[Juan Manuel Cruz]

Ok, comprendido

[Mariano Bondaz]

Hola, estoy interesado en saber como consideran las interferencias,  actualmente estoy desarrollando una plca placa de control de un lavarropa i dustrial y tengo muchisima inferencia en el lcd 16x2 cuando se activan los electro-imanes de las electrovalvulas. .probe de todo...optos..en entradas y salidas..aislacion en la carcaza con aluminio conectada a negativo..ya diseñe 3 plcas diferentes y nada..alguna sugeren ia

[Fabián Rinalde]

Hola Mariano.

Si mandas algún esquema de conexión tal vez te podamos ayudar con tu problema. Lo que puede estar sucediendo es que tengas loops

en los circuitos de por ejemplo la masa. Si las electrovalvulas son de 220v (como supongo), al actuar producen campos magneticos dispersos
que en dichos loops te podrán inducir corrientes parásitas importantes.

Si es eso, lo solucionas con algún magnetic shielding o bien evitando todos los loops en el pcb o en la interconexion de placas.

Saludos

Fabián

[Mariano Bondaz]

Ahi te mando una imagen pcb.. en el db9 se conecta el lcd y en el db15 se conectan los rele (8) x medio de un uln2803 toda la placa esta aislada del chasis del lavarropa..si lkega a tocar se descontrola mal. .

[Pablo Lodetti]

 

Hola Mariano , en las pistas las podrias hacer con angulos de 45º y no rectas,esa pista rodeando la placa podria ser una gran antena, si te parece podrias habrir otro hilo (para no cambiar este que son novedades de la CIAA)   seguro te podemos dar una mano.

[Gustavo Montero]

Buenos días gente,

Me interesa el proyecto que me parece una excelente iniciativa, y me gustaría poder colaborar, aunque no sea con trabajo porque no creo poder disponer de suficiente tiempo, pero al menos con algunas ideas, sugerencias, opiniones y criticas constructivas, en base a mis experiencia personal de muchos años de desarrollo de sistemas embebidos, incluyendo algunos proyectos con algunas semejanzas con este.

No se si este post es el adecuado y recién ingreso al grupo así que aprovecho para consultarles como acostumbran a canalizar este tipo de colaboraciones, y si les parece que les pueden ser de utilidad.

Muchos de los ingenieros que nos hemos dedicado a esto desde hace años nos hemos enfrentado varias veces a la alternativa de usar un PLC comercial o desarrollar un controlador dedicado, y siempre en esos casos también nos hemos planteado la conveniencia de desarrollar un controlador multiuso, básicamente un hardware de PLC pero cuyo firmare lo programáramos nosotros.

Obviamente los desarrolladores de embebidos siempre preferimos implementar nuestra propia solución a medida y programar en C a tener que programar en Ladder, ja ja !!

En mi caso la idea de hacer una placa genérica nunca se materializo por completo (aunque algo parecido hice una vez en un proyecto para INVAP), siempre termine desarrollando hardware a medida para cada aplicación, pero pensé mucho en esta solución genérica de este tipo, tanto en el hard como en el soft.

Por lo que veo la CIAA es en principio exactamente eso con la ventaja de poder llegar a ser masiva, tanto en su aplicación como en su desarrollo.

Por lo que leo en este post y lo que vi en la pagina del proyecto ya tendría algunos comentarios y sugerencias que hacer. No encontré información de cuan avanzada esta la parte de software/firmware y no se donde buscar, porque de estar a tiempo también podría hacer algunas sugerencias al respecto.

En particular siguiendo un poco el hilo de este post me gustaría comentarles algo respecto del protocolo de CAN. Hace dos años empece un proyecto de una aplicación medica que ya esta funcionando en la que había que interconectar placas de un sistema y decidí hacerlo con CAN. Algunas de las placas debían implementar lazos de control y ciertos algoritmos de medición que convenía hacerlos con DSP y en ese momento se decidió usar micros DSPIC. Por velocidad de comunicación, inmunidad al ruido, compatibilidad EMI, simplicidad de interconexion, y disponibilidad de hardware dedicado dentro de los propios micros, la mejor alternativa fue CAN. Ahora había que ver que hacer con el CAN que solo permite mandar paquetitos de 8 bytes, eso si con posibilidad de regular la latencia manejando las prioridades dadas por los ID. En realidad en un sistema típico como ese uno necesita leer y escribir información de configuración y eventualmente algunos datos, que puede llegar a ser mas o menos voluminosa y para la cual no importa demasiado la velocidad y la latencia, y también mandar y recibir información de control de tiempo real con la menor latencia posible. La clave esta por un lado en un protocolo que permita segmentar una información voluminosa en varios paquetes, con control de secuencia y demás, y por otro lado en la asignación de los ID para asegurarse alta prioridad en la información de tiempo real. Pensando e investigando un poco descubrí que CANOpen era exactamente eso con sus protocolos SDO y PDO, y algunas cositas más para la administración de la red y manejo de fallas (NMT y EMCY). Conclusión que decidí implementar CANOpen, al menos en una versión libre no certificada pero que, salvo algún detalle que se me halla pasado, no debería faltarle mucho para certificar.

Personalmente recomiendo usar CANOpen por su simplicidad y eficiencia. CANOpen esta especificado por una organización que se llama CIA (CAN In Automation, que parecido a CIAA ¿no?) de la cual uno puede ser miembro o no (la membresia anual para universidades creo que cuesta unos 550 euros), pero tengo entendido que no hace falta ser miembro para usar el protocolo, de hecho uno puede certificar con ellos pero también puede certificar por su cuenta usando herramientas de certificación que se pueden bajar del sitio creo que solamente llenando un formulario (yo no lo probé).

Otra alternativa seria implementar un protocolo propio del proyecto, pero casi seria reinventar la pólvora, nimiamente habría que implementar algo como el SDO y habría que definir una forma de asignar los ID para los PDO que terminaría siendo algo muy parecido a CANOpen. Pero creo que también podría ser una solución valida, lo que creo definitivamete es que no se debería desperdiciar el CAN, pienso que el soft debería soportarlo desde el principio, porque serviría tanto para interconectar distintas CIAA como para controlar otros sistemas comerciales, dedicados, o futuros productos de este mismo proyecto como servos, variadores de velocidad, sensores de distintos tipos (encoders por ejemplo), etc.

Saludos,

Gustavo

[Marcos Lazcano]

Estimado Gustavo:

La CIAA va a tener su puerto CAN, muy bien instrumentado.

Luego en el firmware se podra implementar o no el protocolo de CanOpen.

Llevo algo de tiempo que lo tuviera disponible, pero se logro.

Coinncido plenamente en que es necesario tener conectividad a redes industriales, sea al inicio o mas adelante, y creo que el hardware ya contampla los dos estandares mas usados hoy dia, CAN y Ethernet.

[Gustavo Montero]

OK Marcos, gracias por la respuesta.

En realidad la ventaja que le veo al CAN no es solo el hecho de ser ya un standard como red industrial, lo cual es importante por supuesto, sino el hecho de que como bus es muchisimo mejor el el RS485 para la interconexion de sistemas de control por el hecho de que es realmente de múltiple acceso con resolución automática por hard y con priordad, de las posibles colisiones. En RS485 siempre hay que usar un mecanismo master-slave o token-passing para que solo un dispositivo a la vez transmita sobre el bus porque no esta previsto en el hardware del bus el manejo de colisiones. Yo implemente muchismas aplicaciones con RS485 usando diferentes protocolos, incluyendo algunos de diseño propio y también MODBUS en sus dos versiones (HEX y RTU) y solo tuve esta experiencia que te mencione con CAN, pero creo que de ahora en mas para cualquier sistema de control que requiera una topologia distribuida no dudaría en seguir usando CAN.

De todos modos hay que seguir soportando RS485, y en especial MODBUS sobre RS485, porque hay muchos dispositivos con los que puede hacer falta comunicarse como PLC's, pantallas, etc.

Saludos,

Gustavo

[Juan Cecconi]

Si. Por todo lo mencionado optamos por poner CAN y RS485 ademas de Eth.
También puede usarse el CAN para por ejemplo hacer tools automotrices con OBD2...hay miles de aplicaciones
Saludos
Jusn

--

[Gustavo Montero]

Correcto Juan, me había olvidado de mencionarlo pero también podría ser útil para aplicaciones automotrices, solo que ahí el protocolo seria OBD II para la parte de diagnostico, para la interconexion entre subsistemas las automotrices suelen usar otros protocolos propietarios, pero anyway el hard sigue siendo CAN y con ciertas prevenciones pueden llegar a convivir algunos protocolos. En realidad la mayoría de los vehículos tienen varios buses CAN en las ECU's, dos o mas, y generalmente el que se usa para la toma de diagnostico es dedicado para eso e implementa OBD II.

También el CAN, independientemente del protocolo que se use encima, seria lo indicado (y tengo entendido que es lo que se viene usando) para la interconexion de los subsistemas de las maquinarias agrícolas, cosechadoras, sembradoras, etc.

Pero no es solo del CAN que me interesaba opinar, solo que no se si este es el post indicado, por eso había consultado sobre como estaba de avanzada la implementacion del software en general.

Saludos,

Gustavo