La reciente caída generalizada de Internet que seguro habréis visto estos días en los medios me ha recordado la importancia de los “porsis”. Es curioso que yo me acuerde ahora de ellos ya que normalmente quien los tiene en cuenta es mi mujer. Cuando nos vamos de vacaciones, si me veo con los pantalones puestos y la llave del coche en la mano ya estoy listo para salir. Ella en cambio llena la maleta de “porsis”. Esto “porsi” hace frío, esto “porsi” llueve… Y menos mal.

En mi defensa diré que tengo los “porsis” muy en cuenta en otros ámbitos, así que no soy un completo inconsciente. Uno recurrente que comento cuando reviso proyectos con clientes es el “porsi” de las conexiones remotas. Básicamente por dos motivos, uno porque las sentencias “para toda la vida” no me convencen (guiño simpático a los publicistas de Movistar) y otro porque como afirmaba Alf el filósofo, si en algún sitio pone irrompible, no me lo creo.

Me explico. Muchos proveedores de componentes de automatización tenemos soluciones en el ámbito de la conexión remota con servidores en la nube que hacen de coordinador de las VPN. En el caso de Panasonic, sería la nube de Corvina que podemos enlazar con nuestro FP-I4C o directamente con nuestras pantallas táctiles.

Pues bien, estos servicios en la nube, por muy bien hechos que estén, no pueden garantizar el 100% de disponibilidad a lo largo del tiempo. Ninguno. No hay nada irrompible. El ejemplo de la caída de estos días con el que abría el post pone de manifiesto que hasta las más grandes infraestructuras pueden caer (temporalmente).  

Por otro lado, generamos una dependencia de esos servicios para las conexiones remotas. Y ¿alguien se atreve a asegurar que estarán toda la vida?

Con esto no me posiciono en contra, todo lo contrario. De hecho ofrezco el servicio de Corvina convencido a diario ya que creo que los beneficios superan con creces los riesgos. No obstante, siempre resalto la conveniencia de disponer del “porsi”. Tanto el FP-I4C como las pantallas compatibles con el servicio Corvina, lo son también con servidores genéricos de OpenVPN y ese es el bendito plan B.

Por muchos años o décadas que el servicio en la nube esté operativo, si en cualquier momento deseamos migrar de servidor, siempre podremos montar en la nube o en local un servidor OpenVPN alternativo al que conectarnos. Esa libertad futura se traduce en tranquilidad presente.

Así que mi pregunta es: si te parece razonable echar en la maleta una chaquetita “porsi” refresca algún día por la noche ¿no te parece también oportuno tener un plan B para realizar las conexiones remotas a las máquinas?

P.D. Si alguien sabe de algún servicio en streaming que tenga Alf en catálogo que me avise...

La entrada de hoy es en formato de propuesta. Os propongo que en aplicaciones de posicionamiento valoréis seriamente el uso del “Bumping Home” o en definición más coloquial, “home por tope mecánico”. Veremos ventajas… y no serán solo económicas.

Voy a tomar como referencia el motor brushless Minas BL GP de Panasonic, usado en aplicaciones sencilla de posicionado, pero en realidad sería una propuesta aplicable a más equipos.

Vamos a poner un poco de contexto al tema. En aplicaciones de posicionado con referencia incremental embebida en el propio motor (encoder incremental por ejemplo) es casi siempre necesario tomar una referencia inicial al encender el equipo. Lo que conocemos por hacer “home” (llevar a origen). Es muy común en estos casos poner un sensor de referencia ya sea inductivo, microrruptor, fotocélula u otro.

Al iniciar la secuencia de “home” el motor busca a velocidad controlada el sensor y al encontrarlo “voilà”, paramos y ya tenemos hecho el “home”.

Las variables principales que se tienen en consideración a la hora de ejecutar este “home” son: velocidad, límite de par en el que consideramos que hemos colisionado y tiempo durante el que ese par se debe dar para realmente considerar que es el origen. Opcionalmente, como en cualquier tipo de “home”, podríamos aplicar un “offset”.

No debemos olvidar que buscamos una colisión, así que la velocidad debería ser prudente. También prudente debe ser el límite de par. Si para mover la puerta el motor necesita un 30% de su par, no hay necesidad de poner un límite del 100%. Poner 40 o 50% es más razonable ya que recordemos que mientras pueda, el motor va a entregar el par hasta su límite. Por último, el tiempo se utiliza como “filtro” ya que ese límite del 40 o 50% podríamos encontrarlo en la misma aceleración del movimiento natural de la puerta. Ponemos un tiempo tal que esa circunstancia se obvie.

Así que se inicia la búsqueda de origen a velocidad lenta, impactamos con cuidado y tras el tiempo definido “empujando” el tope, el motor se para (opcionalmente aplica el “offset”) y ya estamos en origen.

Qué me gusta de este modo:

• Nos ahorramos el sensor (algún eurillo que se nos queda en el bolsillo para otra cosa).
• Nos ahorramos el tiempo de instalación mecánica y eléctrica del sensor (algunos minutillos para tomarnos algo con el dinero que nos hemos ahorrado).
• Es un elemento menos susceptible de estropearse (y por el que nos tengan que llamar mientras nos tomamos “el algo”).
• En caso de sustituirse/manipularse, podemos variar sin querer el punto de detección (ya no se me ocurren más tonterías con lo que relacionarlo 😅).

Este modo de “home” no siempre será aplicable, pero como veis hay buenas razones para tenerlo en mente Os invito a tenerlo en consideración en vuestra próxima aplicación de posicionado.

Os dejo por hoy y me voy a tomar algo que me han entrado ganas ☕.

Saludos!!!

Catálogo del motor usado como ejemplo:

https://www.panasonic-electric-works.com/cps/rde/xbcr/pew_eu_en/ca_minas_bl_en.pdf

Un detalle importante a tener en cuenta es la distancia entre haces, ya que un objeto de altura menor a esta distancia podrá pasar entre ellos y no será detectado. En este ejemplo la distancia sería de 20mm entre haces.

Otro problema que podemos encontrarnos es que el objeto sea irregular y aún siendo mayor a la distancia entre haces, en sus extremos no lo sea y no podamos detectar con precisión la llegada del mismo. Pongamos un ejemplo para abrir boca (literalmente). Si tenemos que detectar de costado el paso de una bolsa de patatas fritas avanzando con la soldadura por delante, no sabremos con exactitud la altura de la soldadura y muy probablemente con diferentes bolsas tendremos distintos puntos de detección. En ocasiones detectará antes, en ocasiones después, en función de cómo se vaya ensanchando la bolsa y acabe cortando alguno de los haces.

Es en estos casos cuando un tipo de producto no muy conocido puede ser útil. Los sensores de haces cruzados. En este tipo de sensores, igual que antes, se disponen varios haces en un mismo cuerpo, pero con la diferencia de no estar dispuestos en paralelo sino cruzados.

De esto modo se hace muy complicado (o al menos mucho más que antes) que un objeto pueda pasar sin cortar algún haz.

Como de costumbre, os dejo un vídeo corto con un par de pruebas de ejemplo.

Saludos!!!

Hola a tod@s.

En el post de hoy repasamos teoría básica de sensores de reflexión directa para poder decidir qué tipo es más adecuado para cada aplicación. Nos vamos a centrar en las diferencias entre los sensores de reflexión directa difusa y los trigonométricos.

Reflexión difusa convencional.

En un sensor de detección difusa convencional, el funcionamiento es bastante sencillo. Se emite un haz de luz (típicamente roja o infrarroja), éste rebota en un objeto en caso de estar presente y en función de la cantidad de luz recibida de vuelta, se activa o no la salida. Si no hay objeto o está muy lejos, habrá poco retorno de luz y no se activará la salida.

Así son la mayoría de sensores de reflexión directa. La dificultad puede venir con objetos de diferentes colores. Un objeto blanco (o claro) refleja más luz que uno negro (u oscuro) y eso implica que donde se detecta uno, quizá el otro no.

También hay que tener en cuenta el impacto derivado de la variación de la distancia. Un mismo objeto reflejará más luz cuanto más cerca esté. Por poner un ejemplo de lo que todo esto implica, una caja de color negro cercana al sensor puede dar la misma reflexión que una blanca mucho más lejana. Para el sensor lo mismo es.

Esto puede suponer un problema cuando el fondo en una aplicación de detección es más claro que el objeto a detectar.

Reflexión trigonométrica.

En este caso el principio de funcionamiento es diferente. También emitimos un haz de luz, pero no tenemos en consideración la cantidad de luz reflejada, sino dónde es recibida. Para ello las fotocélulas disponen de un fotodiodo ubicado tras una lente focalizadora y desplazado respecto al diodo emisor. Por trigonometría pura, en función de la distancia al objeto, la lente concentrará el haz reflejado en diferentes puntos del fotodiodo. Tendremos por tanto la posibilidad de discriminar por distancia en lugar de cantidad de luz. Con la siguiente imagen seguro que quedará más claro.

Aquí un sensor de detección difusa no es adecuado debido a que el ajuste que podemos hacer para un color determinado puede ser no válido para detectar un objeto de otro color. Aquí sin duda será más conveniente un sensor trigonométrico.

Lo mismo si además el fondo está muy próximo.

Detección etiqueta adherida a objeto

En este caso, si la etiqueta es blanca o evidentemente más clara que el producto al que está adherida, deberíamos optar por discriminar con un sensor difuso en función de la cantidad de luz reflejada ya que la diferencia de distancia es mínima (grosor de la etiqueta).

Como veis, en función de la aplicación, nos convendrá más una opción u otra. Lo importante es conocer cómo funciona cada tecnología para decidir con criterio cual es la más apropiada.

Como soy un fanático de los videos, os dejo a continuación unas pruebas con sensores de ambos tipos para que veáis las diferencias.

Saludos!!!

(Note for non-Spanish speakers at the end)

A raíz de una pequeña entrada que hice en LinkedIn usando el láser HGC para medir nivel de líquido, me plantearon algo similar pero con la particularidad de medir sobre aceite.

Como avanzaba en la entrada, en principio se trataba de una aplicación inviable para láser debido a la alta transparencia del aceite que impediría que el haz se reflejara en la superficie y que estaría constantemente reflejado en el fondo.

No obstante, por vocación de servicio, dispuse lo necesario para hacer la prueba y lo registré en el vídeo que os dejo a continuación.

Recibí al mismo tiempo una confirmación de mis suposiciones y una lección de cuán equivocado puede estar uno si pierde el foco del objetivo último. En este caso, efectivamente el sensor no podía dar una lectura correcta, pero igual de cierto era que sí podía tener un valor continuo del nivel.

Lo que se apreciaba era una variación de lectura derivada de la diferencia del índice de refracción del aceite y del aire, y cómo al subir el nivel este cambio hacía que el haz reflejado en el fondo se desviara en mayor o menor medida.  

Resultado, la medida indicada en el sensor era errónea, pero sí disponía de una variación (analógica) de la medida vinculada al nivel de aceite.

Por lo tanto, si el objetivo último era tener una lectura que indicara una proporción del nivel y no tanto una medida exacta del mismo, podíamos dar la prueba como exitosa.

Moralejas que me llevé: “Si el resultado es el deseado, poco importa si nos ceñimos 100% a las características de un manual” y “no hay mejor evaluación que la empírica (al menos en estos casos)”.

Saludos!!!

*To avoid misunderstandings, the measurement shown in the video is not valid. HGC cannot measure oil level. This post explains how sometimes we can get useful information from an invalid measurement.   

Hola a todos, hoy toca briconsejo. Básico, pero útil en algunos casos.

Pongámonos en este caso hipotético. Tenemos una máquina a la que debemos dar asistencia remota. Allí donde está ubicada, la IP pública es dinámica y no tenemos ninguna VPN disponible, ni servicio cloud de teleasistencia tipo Corvina.

El cliente eso sí, nos tiene los puertos abiertos y tiene un servicio tipo dynDNS con una URL conocida.

Hasta aquí todo bien, salvo que nos encontremos que alguno de los softwares a utilizar para la conexión no acepte URLs para la conexión y haya que darle una IP sí o sí.

Podríamos “darle la brasa” al cliente y pedirle que cada vez que nos conectemos revise cuál es su IP pública para poderla usar o podemos apañarnos por nuestra cuenta gracias al comando NSLOOKUP.

Básicamente este comando lo que hace es devolvernos la IP de la URL que introduzcamos. Para ello ejecutamos el símbolo del sistema de Windows (CMD para los amigos) y escribimos nslookup seguido de la URL. Podéis probar con google.es como en este ejemplo.

Una vez tenemos nuestra IP ya podemos llevárnosla al software que toque y trabajar como de costumbre…

Sí, lo sé, por esto no me van a nombrar sucesor de Hackerman (referencia fílmica para unos pocos 😅), pero de un “apurillo” nos puede sacar…

Saludos!!!