Posts Tagged ‘ethernet’

May
26

Temporización discontinua & Ethernet Multicast

Llevo tiempo sin publicar nada en el blog. Disculpad si alguien, remota posibilidad, lo sigue habitualmente. Un último mes complicado. Para ir entrando un poco en materia, os dejo algunos apuntes que últimamente me han llamado la atención: algunos ajenos, y otros propios.

No hace mucho me surgió un problema parecido al que de forma detallada y fantásticamente explicado se refleja en el artículo que os enlazo del estupendo blog Notas de Automatización: el problema radica en realizar una temporización discontinua, de forma que el contaje temporal de dosificación de un líquido sea fijo independientemente de las interrupciones que éste pueda sufrir en su flujo. Naturalmente el problema se basa en almacenar las temporizaciones en memorias intermedias, pero no es evidente. Como podréis ver, se encuentra resuelto en notación KOP, estupendamente detallado, comentado y explicado. Sabéis no obstante los que me conocéis la manía que tengo de tender siempre al AWL… lo reservaremos como ejercicio para el curso que viene.

Por otro lado, os dejo un pequeño videotutorial de un problema que hemos planteado hoy en las clases de recuperación de Comunicaciones Industriales. La comunicación Multicast sobre Ethernet, empleando 3 S7-300 con CPU 314C-2DP y sus respectivos módulos CP 343-1 Lean. Para ello hemos creado 2 grupos Multicast, uno compuesto por las CPUs 1 y 2 y otro por las CPUs 2 y 3. Recordad que los enlaces deben ser siempre enlaces UDP de tipo Multicast, y por supuesto el identificador IP de cada grupo debe ser diferente, así como el puerto de comunicación. Sin más, os dejo el video. Para que esta vez no se eternice el tiempo entre posts, pronto tendré otro preparado para hornear. Posiblemente no de videotutoriales ni material, pero igualmente interesante para conocer la triste realidad de nuestra familia profesional.

 

Feb
19

Comunicaciones Ethernet con S7-300 (2)

Las comunicaciones entre equipos S7-300 y S7-200 de Siemens admiten varias configuraciones distintas. Debido a las características de la mayoría de los módulos de comunicaciones de los que disponemos, las comunicaciones de este tipo las hemos implementado haciendo funcionar siempre el S7-200 como cliente y el S7-300 como servidor a través de enlaces tipo TCP. No podemos olvidar que en una arquitectura Cliente-Servidor es siempre el primero el que maneja la comunicación. De este modo, hasta ahora ha sido el S7-200 el que realiza las peticiones de lectura/escritura al S7-300 mediante el uso de las funciones AG_SEND, AG_RECV, AG_LSEND y AG_LRECV.

Existe otro caso particular de comunicación entre equipos 300 y 200 que es el inverso: el 300 actuando de cliente y el 200 haciéndolo de servidor. Este tipo de comunicación tiene algunas exigencias adicionales en la configuración de la comunicación. Por un lado, el peso de la comunicación recae ahora en el cliente, que es el S7-300. Tenemos pues que tener la posibilidad de definir qué datos van a leerse o escribirse, dónde y de dónde. Por otro lado, necesitamos además que en la configuración del enlace de comunicación a través de STEP7 para el S7-300, podamos configurar un enlace no-especificado, ya que el equipo S7-200 queda fuera del alcance de la configuración a través de STEP7, y deberá configurarse como siempre a través de MicroWIN (qué ganas tengo de ver una versión STEP 7 integrada para todos los equipos Siemens…).

En el videotutorial que os dejo, vemos cómo puede realizarse la configuración de esta comunicación estableciendo un enlace de tipo S7, ya que naturalmente ambos equipos son Siemens y el módulo de comunicaciones CP 343-1 Advanced nos lo permite (cosa que no hacía el 343-1 Lean). Es especialmente interesante la configuración de los TSAP en la comunicación, así como el uso de las funciones FB14 y FB15 (GET y PUT respectivamente), que necesitan de la configuración de un DB específico y que permiten la lectura o escritura de datos en CPU’s externas.

En el siguiente documento de Siemens tenéis una magnífica explicación de la configuración de la comunicación entre equipos S7-200, S7-300 y S7-400 para diferentes supuestos de actuación (cliente / servidor) de cada uno de ellos. Lástima de las limitaciones de todos conocidas…

 

Nota: Teniendo en cuenta la caótica página web de Siemens, en ocasiones no es fácil encontrar material que solvente dudas sobre el uso de determinadas funciones de comunicación. No obstante, en el siguiente enlace tenéis sobrada documentación sobre uso de funciones de comunicación en Industrial Ethernet y Profinet, así como algunas soluciones a dudas y problemas comunes que pueden surgir. Y respecto al idioma, ya sabéis lo que hay. El que quiera peces…

Ene
31

Comunicaciones Ethernet con S7-300 (1)

Las comunicaciones Ethernet son, salvando Profinet y la cantidad de nodos aún instalados de Profibus en todos sus perfiles, quizás las más versátiles en cuanto a la posibilidad de integración de distintos sistemas y a la salida a redes de área extensa. Es por ello que en los últimos años han sido los estándares 802.3 de Ethernet y también el 802.11 de Wireless los más adoptados para la comunicación en sistemas industriales de cierta entidad.

Para ilustrar las posibilidades de comunicación de los S7-300, iremos poco a poco realizando ejemplos cada vez más complejos hasta donde las posibilidades físicas de material, conocimientos, y fundamentalmente tiempo, nos dejen evolucionar.

Como hay que comenzar por algún sitio, lo haremos por el principio, que suele ser lo más conveniente. Veremos cómo realizar una comunicación simple entre dos S7-300, funcionando uno como cliente y otro como servidor, y haciendo uso de las funciones integradas de los módulos CP. En este caso, trabajaremos en ambos equipos con los módulos de comunicaciones Ethernet CP 343-1 Lean. Estos módulos tienen algunas limitaciones de cara a la comunicación Ethernet, como veremos más adelante, pero para este sencillo ejemplo nos serán suficientes.


Mediante las funciones de librería de los módulos CP AG_SEND (FC5) y AG_RECV (FC6) realizaremos el envío de datos de la palabra EW124 de un equipo (llamémosle S7-300 (1)) a la palabra AW124 de otro (S7-300(2)). A diferencia de lo que ocurría con las comunicaciones MPI, en este caso para la transferencia de datos deberemos hacer uso de ambas funciones. La primera de ellas (AG_SEND) nos enviará los datos de la CPU al búfer de comunicaciones del módulo CP, y de ahí al equipo especificado en el enlace definido, y la segunda función (AG_RECV), recogerá los datos del enlace en el búfer del segundo módulo CP, y se los enviará al equipo receptor.

Para este ejemplo pueden usarse varios tipos de enlace. Normalmente (salvo casos particulares que iremos desgranando), para realizar comunicaciones entre equipos Siemens podemos hacer uso de los enlaces S7 por su rapidez y simplicidad a la hora de identificar los equipos. Si además es necesario traspasar la frontera de los equipos industriales y llevar estos datos a otras redes, recurriremos como en este caso a los enlaces TCP.

Como mejor se ilustra el ejemplo es con una explicación in situ. Así pues, ahí va como de costumbre el videotutorial.

 

 

Sep
23

Cableado del par trenzado con RJ-45

Pues me disponía a hacer una entrada con el cableado del par trenzado que estamos haciendo en el módulo de Comunicaciones Industriales cuando me encuentro que al mismo tiempo, con unas horas de antelación, los tocayos de ciclo del IES Guarnizo de Cantabria han hecho una entrada similar, breve, pero muy bien explicada, y con la ilustración de uno de los problemas que nos ha surgido en uno de los cables: la inversión de posición del terminal.

 

dhqtks6w_187cc5czrcv_b

 

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Spain
This work by José María Delgado is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Spain.