Feb
15

Sensores en Arduino (II): Temperatura

Si en artículo anterior veíamos cómo habíamos trabajado en clase midiendo temperaturas con termistores, veremos ahora qué hemos hecho para trabajar con sensores de temperatura de unión semiconductora tipo LM35. El proceso es enormemente más sencillo, ya que la gran ventaja de este tipo de sensores es su linealidad: en el caso del LM35, 10 mV/ºC. Por contra, sacrifican enormemente su precisión (errores hasta del orden de 0.6ºC), estabilidad y tiempo de respuesta.

En nuestro caso hemos usado los LM35 con encapsulado plástico TO-92. Su hoja de características podemos descargarla directamente de la web del fabricante.

LM35

Su conexionado básico para medir temperaturas entre +2 y +150ºC con Arduino es extremadamente sencillo: su rango de alimentación en Vs varía entre +4 y +20Vcc, y su salida varía del orden de 0V+10mv/ºC.

Conexionado LM35

Conectarlo a Arduino es igualmente evidente, sólo hay que respetar el patillaje del elemento.

LM35 Arduino UNO

El código para Arduino no puede ser más sencillo, aunque es posible recurrir a varias alternativas. La primera de ellas es transformar de forma directa la lectura del valor analógico en A0 a un valor de temperatura. El razonamiento es sencillo: dado que los pines analógicos de Arduino tienen una resolución de 10 bits (1024 valores) con un rango en tensión de 5V, Arduino es capaz de distinguir escalones de tensión de (5/1024). Podemos deducir pues que el valor en V del pin analógico (en este caso A0) será:

Lectura del pin(analogRead) * (5/1014) [V]

Transformándolo a mV, que es el rango del sensor LM35, tendremos:

Lectura del pin(analogRead) * (5/1024) * 1000 [mV]

Si además sabemos del Datasheet de nuestro LM35 que en su configuración básica la tensión en Vout es 10 mV/ºC, podemos concluir que el valor en ºC de la temperatura leída en el pin A0 es:

(Lectura del pin (analogRead) * (5/1024) * 1000) / 10, o lo que es lo mismo:

Lectura del pin (analogRead) * (5/1024) * 100.

Es por eso que podemos plantear:

Otra buena opción consiste en mapear nuestro rango de valores conociendo sus valores mínimos y máximos, aunque en este caso debemos estar seguros de los rangos mínimos y máximos de nuestro sensor en su configuración:

En los próximos días emplearemos algún otro tipo de sensor, crearemos algunas aplicaciones sencillas de control domótico aislado controlado por Ethernet y haremos nuestra propia biblioteca de funciones para los sensores empleados.

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…

Feb
13

La importancia de la estructuración

“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)

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.