Transferencia completada

febrero 13, 2011

Como ya indiqué hace tiempo, he transferido todo el contenido de este Blog SRCA a la web Elec2.es. Desde este momento, ésta será la referencia para las nuevos posts, publicaciones, tutoriales, etc. Las circunstancias así lo mandan…


Absurdeces e ignorancias administrativas (y 2)

julio 20, 2010

Nunca me ha gustado Saramago. Como lector no excesivamente cultivado, su prosa se me ha hecho siempre tediosa y densa. A pensar de resultarme llamativos los trasfondos, o la interpretación personal de las situaciones, reconozco haber comenzado Ensayo sobre la Ceguera, pero no haber sido capaz de pasar más allá de la mitad del libro. No sé por tanto hasta qué punto mi moraleja propia de la historia es la que Saramago pretendía. Ni siquiera sé si pretendía alguna, o simplemente que cada uno se construyera la suya propia. Tampoco la adaptación de Fernando Meirelles me hizo cambiar mis conclusiones.

Es curioso cómo cuando nadie puede o quiere ver, y como cuando aquellos que sí lo hacen eluden su responsabilidad como guías, la oscuridad todo lo anega. En situaciones especiales, los errores cometidos una vez son traspiés de los que tomar oportuna nota para situaciones posteriores similares. Los cometidos por segunda y consecutivas veces se llaman ignorancia, ineptitud y estupidez.

Hace un año por estas fechas, en Sistemas de Regulación y Control Automáticos, y por extensión en el Departamento de Electricidad & Electrónica de nuestro IES Santiago Apóstol la sufríamos con la marcha de David Pecellín. Ya expuse las razones de la estupidez, y no tiene mucho sentido volverlas a repetir siendo las mismas. La única razón de volver de nuevo al mismo tema es la denigración del esfuerzo por parte de una Dirección General de Formación Profesional  y de Personal Docente que, teniendo capacidad para ver la luz, prefiere seguir ciega, mientras dobla la rodilla en señal de reverencia a la mano que le da las míseras migajas para alimentarse. Cuando a una mesa le quitas una pata, independientemente del grosor de la misma y la importancia del soporte, se tambaleará, pero si le quitas dos, en poco tiempo se vendrá abajo.

Las reglas generales no son válidas para las situaciones particulares. Como consecuencia de la regla general, tristemente, este blog tiene que desaparecer. Como con Roy Batty, todos esos momentos de trabajo, investigación, actualización de información y materiales en una evolución vertiginosa, se perderán en el tiempo. Es hora de morir.

No será, por suerte, una muerte definitiva, sino más bien una transmigración. Elec2 será a partir de ahora el sustento del blog, en una remodelación que, a lo largo del verano de calor y moscas, que diría Cela, iré llevando a cabo, pero que previsiblemente cambiará totalmente de perfil, tristemente alejado de la automatización industrial a la que he intentado enfocarlo en estos últimos dos años.

A todos los que durante estos últimos años habéis pasado horas de vuestro tiempo ayudándome, a los que de una u otra forma desde que llegué hasta ahora habéis contribuido a que mi estancia durante estos años aquí haya hecho que, pese a tener la posibilidad de acercarme a casa, haya preferido la distancia a la comodidad, mi más sincero agradecimiento. No creo que pueda estar en otro sitio tan bien como he estado estos años con vosotros.

Hasta pronto.


Temporización discontinua & Ethernet Multicast

mayo 26, 2010

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.


El nido del esquivo Gremlin eléctrico

marzo 25, 2010

Otro interesante ejemplo que nos presentan en There, I fixed it! de lo que no debe ser un armario eléctrico.


Comunicación Profibus entre S7-300 y S7-200

marzo 2, 2010

Para seguir, en el ya poco tiempo que nos queda de curso en Comunicaciones Industriales, con el tema de Profibus, os pongo otro videotutorial que detalla un poco, en la medida que permite una grabación de escritorio, la forma de configurar la comunicación entre un equipo S7-300 y un S7-200 de la gama SIMATIC.

Dado que el S7-200 funciona siempre en modo esclavo en Profibus DP a través del módulo EM 277, toda la comunicación se configura desde STEP7 para el S7-300, siendo necesario a través de MicroWIN programar únicamente los movimientos de datos necesarios para la transferencia desde el área V del S7-200.

Algunos datos interesantes que me gustaría destacar de la configuración de los equipos:

– De cara a poder enlazar en modo esclavo el módulo EM 277 del S7-200, es posible que sea necesaria para la versión 5.4 de STEP7 la instalación del archivo GSD del módulo. Un archivo GSD no es más que un paquete de datos de configuración necesario para algunos equipos de la gama Siemens, a modo de una actualización de Hardware personalizada. Tras la descarga del GSD, su instalación no suele ofrecer problemas. Si los ofrece (en algunas versiones de STEP7 v5.3 puede ser así), siempre podemos recurrir a la solución de “fuerza bruta” descrita en el video. Os aseguro que funciona.

– Es fundamental tener en cuenta que el a partir del byte especificado en la configuración de STEP7 del área V del S7-200, primero irán los datos de Entrada (entran en el S7-200), y luego los de Salida (salen del equipo). Por tanto, si seleccionamos una transferencia de 2 Bytes Out/2 Bytes In a partir del VB10, tendremos que VB10 y VB11 serán los bytes donde se vuelquen los datos de entrada en el 200, mientras que VB12 y VB13 serán los que reflejen los datos de salida del mismo con dirección a otros equipos (en este caso, el S7-300).

– No podemos olvidar bajo ninguna circunstancia configurar la dirección Profibus DP del EM 277 con las ruedas codificadas, y por supuesto, comprobar la posición de las resistencias de terminación de los conectores del Bus.

Sin más, os dejo el videotutorial. Espero como siempre que os sea útil para recordar conceptos y para asentar los que ya tengáis.


Comunicación Profibus DP entre S7-300

febrero 24, 2010

A falta aún de sacarle jugo a la Cp 343-1 Advanced con el diseño de aplicaciones web integradas de control mediante el uso del HTML Code Generator de Siemens, nos metemos en uno de los sistemas más ampliamente usados en el ámbito de las comunicaciones industriales, que aunque poco a poco va siendo desplazado por sistemas más versátiles como Profinet, todavía tiene mucha vida por delante gracias a la gran cantidad de nodos profibus actualmente instalados.

Para comenzar por el principio, que suele ser lo más conveniente, os dejo un pequeño videotutorial de cómo realizar la configuración de la comunicación Profibus entre dos S7-300 mediante STEP7. El objetivo es intercambiar dos áreas de memoria entre dos S7-300 funcionando como Maestro/Esclavo. Pretendemos pues reflejar el byte de entrada EB124 de uno de los equipos (maestro) en el byte de salida AB124 del otro equipo (esclavo) y viceversa.

Es especialmente interesante la estructura de los dos bloques de programa OB1 que cargamos en cada uno de los autómatas. No olvidéis que a pesar de que las transferencias configuradas vía STEP7 son tan sencillas como AB0->EB0 en un equipo y AB0->EB0 en el otro, tenemos que mover a esos datos de salida (AB0) y de entrada (EB0) los respectivos valores EB124 y AB124 que queremos que se reflejen en cada uno de los equipos.

El siguiente paso es incluir a los S7-200 en las comunicaciones Profibus. Poco a poco se anda el camino. Espero que os resulte de utilidad.


Comunicaciones Ethernet con S7-300 (2)

febrero 19, 2010

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…


La importancia de la estructuración

febrero 13, 2010

“Cualquier idiota puede escribir código que un ordenador pueda entender. Los buenos programadores escriben código que las personas puedan entender.” (Martin Fowler)

(Vía Mundo Geek)


Comunicaciones Ethernet con S7-300 (1)

enero 31, 2010

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.


¿TIC en la FP?

enero 30, 2010

Si he de ser sincero, siempre que la actividad me ha puesto delante, de forma voluntaria o involuntaria, una situación en la que las diferencias entre la formación profesional y la educación secundaria obligatoria eran palpables (en estos gazpachos de gente que tenemos hechos en los institutos), casi nunca he sentido envidia (llamémosla sana por ser condescendientes) de la situación ajena respecto a la propia. Y digo casi nunca por los aspectos habituales que uno está un poco cansado de argumentar, llamémosles en general GUARDIAS, y lo dejo aquí que se me calientan las yemas de los dedos.

A lo que iba: siempre tiene uno la sensación de ser un privilegiado por el ámbito en que desempeña su labor docente, por unas u otras circunstancias que son por supuesto discutibles, pero que son las de uno. Y yo, personalmente, no las cambiaba. Pero hete aquí que conforme me he ido metiendo en ámbitos que hasta ahora sólo había rozado tangencialmente, he encontrado algo de lo que realmente siento sana (ahora sí) envidia de otros niveles educativos.

Si generalmente en el ámbito educativo y formativo la Formación Profesional ha sido siempre (ahora nos intentan vender otra cosa, pero lo venden a precio barato) la apestada del sistema (y no olvidemos, otros países sí lo saben, que de la calidad del sistema de Formación Profesional depende el nivel de desarrollo tecnológico de un país), ahora sigue siéndolo, y seguirá así me temo un rato largo, la apestada en el uso de las Tecnologías de Información y Comunicación. La situación se solventa dejando libre albedrío a las familias profesionales y ciclos para que, bajo su sesgado criterio, empleen aquello que crean oportuno, a cargo por supuesto de los presupuestos y asignaciones departamentales, pero sin un claro y definido programa que apoye, defienda y promueva el uso de TIC desde el punto de vista formativo, y no del profesional propio de cada familia.

De esta forma, mientras la educación primaria y secundaria se engordan y ceban en el uso de TIC, en la FP estamos a dos velas, hasta el punto, y esto es lo gordo, que en muchos (no en uno ni dos, en muchos) Ciclos Formativos de nuestra Comunidad no existe, no digo ya los ordenadores por cada dos, tres u ocho alumnos, sino ni siquiera el ordenador por profesor (de portátil ni hablamos, hablo del mamotreto fijo de la mesa del aula). Y aquí no pasa nada. Lo tomamos como lo más normal. Como la FP no entra cuando hablamos de TIC, pues todos contentos con lo que hay.

Y lo grave de esta situación es que es ahí realmente donde se aprovecha el potencial de las TICs a nivel formativo (no digo por supuesto que no se aproveche a otros niveles, pero no como nos quieren hacer creer los politiquillos de turno, a los que les interesa porque con eso es con lo que se imprimen las dietas). La Formación Profesional ofrece un abanico tan sumamente amplio de recursos para la explotación de las TIC que deja palpable y claro que este sistema es el del mundo al revés: hartura para quienes no pueden, quieren o saben aprovechar la comida, y hambre y miseria para aquellos que sí podrían hacerlo.

Ojalá me equivoque y de aquí a nada, cada vez que lea una noticia de asignación de equipos, pizarras digitales, programas de formación, promoción y difusión de herramientas TIC, o iniciativas para su fomento aparezcan, al lado de la educación obligatoria, las letras FP. Pero vamos, cazado un conejo, cazados todos. Todavía tiene que llover.


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.