No mas dependencia con Windows en una migración

Cuando se comienzan a elaborar planes y estrategias para migrar el Sistema Operativo de todos los escritorios de trabajo a Software Libre, es común encontrar una gran dificultad para resolver el caso de aquellos programas los cuales no tienen ejecutables para GNU/Linux, no es posible correrlos con WINE y no se encuentran alternativas libre que puedan reemplazarlos, que cuenten con las mismas funcionalidades requeridas y que puedan leer sus formatos privativos.

Una propuesta común en la elaboración de estas estrategias consiste en usar un sistema virtualizado (ej. VirtualBox) resultando en la presencia de dos escritorios simultáneos para el usuario y requiriendo una cantidad considerable de recursos en el hardware de las estaciones de trabajo, casi siempre ofuscando y ralentizando el funcionamiento de todas las operaciones comunes.

Tenemos entonces una variedad de programas privativos de los cuales se desconoce una receta para hacerlos correr en GNU/Linux y de lograrlo (vía WINE) es posible que algunas de sus funcionalidades fallen. Muchos de estos programas son aquellos hechos por las mismas organizaciones en lenguajes privativos, con poca o ninguna documentación de su código y duramente vinculados (“cableados”, en la jerga común) con otros sistemas similares que también requieren Windows para operar y si son una piedra de tranca en una migración es por ser indispensables para la continuidad operativa o el funcionamiento de importantes procesos de la organización.

Esta situación ha sido por siempre causa de desilusiones e intentos fallidos al emprender un plan o proceso de sustituir por GNU/Linux el Sistema Operativo de los escritorios y a continuación se describe una alternativa, usando una sesión de usuario desde un “escritorio central” el cual provee (mediante un protocolo de red) las “ventanas” de las aplicaciones que necesitan los clientes quienes las visualizan como una aplicación más, inlcuso disponible como una entrada mas en su menú de inicio o como otro icono de acceso del escritorio.

El protocolo RDP

El protocolo RDP, desarrollado por Microsoft, permite la transmisión por red de la vista de un escritorio completo (al estilo VNC) pero su mas interesante característica es que permite también enviar sólo la ventana de cualquier programa. Es decir: una máquina (física o virtual) con Microsoft Windows puede “servir” cualquier aplicación instalada, digamos notepad, iexprorer o cualquier otro programa local instalado y entonces un cliente GNU/Linux puede mostrar en su escritorio esa ventana, de manera similar como muestra cualquier otra (LibreOffice, GIMP, Gedit, etc). Esto es posible lograrlo gracias a que existe una implementación libre del cliente RDP llamado FreeRDP.

Esta tecnología permite incluso enviar recursos a esas ventanas foráneas, entre los cuales destacan:

  • Sistemas de archivos locales (carpetas existentes en el cliente)
  • Unidades compartidas en red (carpetas montadas en red)
  • Unidades de CD/DVD
  • Unidades de almacenamiento (USB Drive)
  • Puertos físicos (serie, paralelo, USB)
  • Dispositivos de sonido (micrófono y salida de audio)
  • Dispositivos de red
  • Otros (es software libre y permite desarrollarle módulos adicionales)

Instalación de un Escritorio Central

El servicio RDP se puede instalar en varias versiones de Windows (no en todas) y su funcionamiento ha sido probado satisfactoriamente con todas las funciones necesarias en la versión “Windows 7 Ultimate” en donde se requieren los siguientes pasos:

  • Reconfigurar el Cortafuegos: El Cortafuegos y cualquier otra herramienta que controle las reglas de los puertos IP (antivirus o similares) deben permitir peticiones y acceso a servicios por TCP/3389. En el ambiente de desarrollo se puede deshabilitar totalmente el cortafuegos, en producción será necesario realizar este ajuste de seguridad.
  • Habilitar las peticiones de Escritorio Remoto: habilitar la opción “Permitir conexiones de asistencia remota a este equipo” (en inglés la opción es “Allow remote connections to this computer”) dentro de la pestaña “Escritorio Remoto” en la sección “Sistema” del panel de control.
  • Instalar .NET Framework: se requiere específicamente la versión 4.0 de este componente. No está probado que funcione con versiones más nuevas o distintas a esta.
  • Instalar y Configurar RemoteApp Tool: Después de instalarse RemoteApp Tool debe habilitarse en este programa la opción para proveer aplicaciones vía RDP. Se pueden habilitar todas las aplicaciones para todos los usuarios o también es posible proveer una lista de aplicaciones con los usuarios permitidos para su acceso remoto.
  • Habilitar sesiones concurrentes: Para proveer el servicio a varios usuarios simultáneamente, es necesario correr la aplicación Concurrent RDP, la cual modifica las entradas del registro que permiten esta función.

Cliente RDP

Sólo es necesario tener instalada la versión 2.0 o superior de FreeRDP con lo cual es posible crear un icono de acceso directo en el escritorio o una entrada en el menu principal que invoque la aplicación requerida, mediante un comando similar al siguiente:

xfreerdp /u:usuario /p: /d:dominio /v:servidor /app:calc

Esto invocará la aplicación “calc” (la calculadora de Windows) y la mostrará en el escritorio del usuario cliente.

Quizás sea necesario añadir la opción /cert-ignore para abrir sesiones sin certificado, en especial para el ambiente de desarrollo. Más información en el man de xfreerdp, también visible ejecutando “xfreerdp /help” o bien disponible en la página de documentación del desarrollo.

Conocimiento Denegado

La informática y la telefonía celular son dos fenomenos muy cotidianos y de reciente data en la historia tecnológica de la humanidad, recién llegados hace menos de 30 años a una civilización después de 5.000 y más años de descubrimientos.

Si comparamos el mundo tecnológico con un bosque, podemos afirmar que a casi todos los habitantes del mundo les es permitido ver sólo los árboles que les rodean. Poco tiempo y poca información han tenido quienes quieren estudiar cómo funcionan los dispositivos electrónicos actuales y los programas informáticos que corren en ellos, para comprender algunas de sus poco obvias funciones que tienen sus diseños, en los cuales se toma casi siempre la previsión de dejar la mayor cantidad posible de secretos, generando así cada día más y mas “conocimiento denegado”.

Casi cualquier producto electrónico fabricado en los últimos 20 años posee partes y piezas de hardware y de software de los cuales nos está prohibido saber cómo funcionan. A veces incluso es desconocido esto en las fábricas que ensamblan las computadoras y teléfonos que usan estas misteriosos componentes, así como tampoco es manejado ese conocimiento en las universidades que intentan graduar profesionales serios, conocedores de estas áreas. Eso es conocimiento denegado.

En lo individual, esta condición compromete definitivamente la privacidad. Nuestros teléfonos celulares pueden escuchar a varios metros de distancia cualquier conversación, entender y convertir las palabras pronunciadas en texto, almacenar todos los mensajes enviados y recibidos, revelar la posición geográfica con tiempos y patrones de permanencia y enviar eso y mucho más a través de su red de conexiones simulando incluso un estado de “apagado” al supuesto dueño del dispositivo quien cree poder controlarlo y configurarlo a su gusto.

El tema es tan agobiante que hay aplicaciones que ofrecen, con el fin de ubicar un dispositivo perdido, realizar remotamente el encendido del mismo para poder recibir su localización geográfica y por tanto poder encontrarlo. Si el dispositivo se puede “encender” remotamente es porque está a la escucha, esperando la orden. Un dispositivo que está apagado no puede escuchar ninguna orden pues está apagado. Si se puede encender remotamente a través de un Software que usa la red de datos a través de Internet, lo único que quiere decir es que nunca estuvo apagado, aunque así lo pudiera jurar su propietario quien además cree que no es posible que su celular apagado lo esté escuchando y enviando sus conversaciones quién sabe dónde.

En lo colectivo, el Conocimiento Denegado atrofia el acervo científico de cualquier nación, puesto que convierten al estudio y la creación en un campo minado donde a cada paso puede explotar una “patente” que niega, prohíbe y dificulta enormemente avanzar en el dominio y control de cualquier área del saber y el hacer. Asimismo vulnera dramáticamente la soberanía y autodeterminación de cualquier país puesto que es imposible saber si se cumplen las garantías de seguridad de estado al hacer uso de tecnología que oculta muchas de sus funciones. Múltiples ejemplos hay, como el caso de los misiles que Argentina no pudo activar en la guerra de las Malvinas debido a una escondida trampa dentro de los dispositivos adquiridos por esa nación.

Ningún experto puede estudiar cómo funcionan gran parte del hardware y del software que opera en los circuitos y sistemas que usamos actualmente. Estas novedades tecnológicas no pueden investigarse en las universidades de nuestros países: está prohibido por los fabricantes estudiarlas y por tanto es imposible aprender a fabricarlas. Es imposible ser experto en un área del saber en estas condiciones.

¿cómo puede cualquier país desarrollarse en estas condiciones cuando hay tanta debilidad e ignorancia sistemáticamente generada y ciegamente aceptada?

Marco Legal del Software Libre en Venezuela

Las leyes venezolanas relacionadas con la migración a Software Libre y que tienen que ver de forma vinculante y explícita en este respecto son:

  • Decreto Presidencial 3.390: Publicado en diciembre de 2004 dice en su primer artículo “La Administración Pública Nacional empleará prioritariamente Software Libre desarrollado con Estándares Abiertos, en sus sistemas, proyectos y servicios informáticos. A tales fines, todos los órganos y entes de la Administración Pública Nacional iniciarán los procesos de migración gradual y progresiva de éstos hacia el Software Libre desarrollado con Estándares Abiertos.”. Este decreto fue derogado en 2013 por la Ley de InfoGobierno.
  • Gaceta Oficial 39.109: del cual se cita el primer artículo que dice “Todos los entes y órganos de la Administración Pública Nacional de la República Bolivariana de Venezuela que generen, procesen o almacenen documentos electrónicos informáticos, deberán aplicar y utilizar el Formato Abierto de Documentos (ODF) en su versión 1.0 sin menoscabo de que se empleen versiones superiores conforme lo indique el ente encargado de velar por el cumplimiento de la presente resolución”
  • Gaceta Oficial 39.633: en cuya ordenanza 025, artículo 5 dice “Los Órganos y Entes de la Administración Pública Nacional deben incluir en los términos de referencia de aquellos contratos que tengan por objeto la adquisición de estaciones de trabajo, el requerimiento de justificar su funcionamiento bajo la distribución Canaima GNU/Linux sin la necesidad de la instalación adicional de componentes o partes privativas o cerradas para su operatividad; debiendo además ser éste el único sistema instalado en los equipos desestimando las ofertas que no cumplan esta condición.
  • Ley de InfoGobierno: Promulgada en Gaceta Oficial el 21 de octubre de 2013, la Ley de Infogobierno hace de uso obligatorio el Software Libre para todos los servicios informáticos que preste el Poder Público (instituciones públicas) de la República Bolivariana de Venezuela y ordena que “Todo programa informático que se desarrolle, adquiera o implemente en el Poder Público, después de la entrada en vigencia de esta Ley, deberá ser en software libre y con estándares abiertos”.

Otras leyes relacionadas directa o indirectamente con las Tecnologías Libres

  • Decreto Presidencial 825: (mayo 2000) Declara el acceso y el uso de Internet como política prioritaria para el desarrollo cultural, económico, social y político de la República Bolivariana de Venezuela.
  • Decreto Presidencial 1.204: (febrero 2001) Tiene por objeto otorgar y reconocer eficacia y valor jurídico a la Firma Electrónica, al Mensaje de Datos y a toda información inteligible en formato electrónico, independientemente de su soporte material, atribuible a personas naturales o jurídicas, públicas o privadas, así como regular todo lo relativo a los Proveedores de Servicios de Certificación y los Certificados Electrónicos.
  • Ley Especial Contra los Delitos Informáticos: (septiembre 2001) Tiene por objetivo la protección integral de los sistemas que utilicen tecnologías de información, así como la prevención y sanción de los delitos cometidos contra tales sistemas o cualquiera de sus componentes o los cometidos mediante el uso de dichas tecnologías.
  • Decreto con Rango, Valor y Fuerza de ley 9051; (junio 2012) (derogado por la Ley de Infogobierno) Dicta ordenanzas sobre acceso e intercambio electrónico de datos, información y documentos entre órganos y entes del Estado, con el objeto de garantizar la implementación de un estándar de interoperabilidad. Se especifica el uso de Software Libre y Estándares Abiertos.

Semeruco MIDI

“Semeruco” es una baya (berry, en inglés) propia del centro-occidente de Venezuela, en los estados Falcón, Lara y Zulia, aunque se da en otros estados del país.

Esta es una iniciativa colectiva de la Comuna Itinerante del Sonido y del Audio “CISA” y la Comuna Don Luis Zambrano y el objetivo es crear una fábrica de hardware libre donde se produzcan estas propuestas de innovación nacional.

El objetivo de este proyecto es hacer una Superficie de Control MIDI con las siguientes características y objetivos para su primer prototipo:

  • Matriz de teclado de capacidad hasta de 64 pulsadores organizados en una rejilla de 8×8
  • Entradas analógicas (las 8 de la tarjeta Pingüino)
  • 16 leds, asignados sobre un teclado de 4×4 pulsadores.
  • Reloj para el tempo, asignado a una línea de 4 leds.
  • Comunicación USB y/o MIDI

Resultado esperado

Diseño de interfaz

Una superficie de control MIDI con una matriz de 4×4 teclas para la secuencia y controles diversos, tanto analógicos (potenciómetros/sensores) como digitales (prendido/apagado).

En el gráfico se muestra el diseño conceptual, esquematizado para su comprensión. La manufactura tendrá variación.

Los controles pueden añadirse o quitarse de la matriz, así como esta puede redimensionarse y alcanzar las 8×8 teclas. Inicialmente y en el prototipo planteado, se pueden implementar sensores de luz, de proximidad y de cualquier dispositivo que envíe una variación de valores, los cuales podrán ser leídos en un rango entre 0 y 1023. Una precisión de 1024 valores es bastante suficiente para casi cualquier necesidad de lectura diferencial, al menos para las señales MIDI las cuales tienen todas un rango de variación entre 0 y 127.

La matriz trabajará como escritorios virtuales: se pueden administrar muchas matrices que forman cuadrados de 2 o más matrices, de manera de poder, con 4×4 elementos, manejar rejillas con formas arbitrarias como 8×8, 4×16 o cualquier patrón con un múltiplo de 4×4 de estos pulsadores con led.

La pantalla ayudará a ubicarse en qué “escritorio” se está, aunque la pantalla LCD no forma parte necesariamente del primer resultado de este proyecto. Se puede sustituir por una matriz de 4×4 leds que muestren en qué espacio virtual se encuentre.

El Controlador

El controlador principal de Semeruco MIDI es la tarjeta “geÑUino”, basada en el micro-controlador AVR Atmel de 8-bit. Este controlador posee tecnología basada en arquitectura RISC Para profundizar más sobre sus características, las cuales están públicamente documentadas, se pueden ver su (hoja de especificaciones técnicas).

Es una tarjeta 100% compatible con Arduino y su placa base está diseñada a una sola cara, de manera de poderla reproducir con cualquier procedimiento artesanal de creación de PCB.

La tarjeta geÑUino ha sido totalmente diseñada desde cero y acá están sus esquemáticos, diseñados con Fritzing. Las imágenes pueden ampliarse al accionar el puntero sobre ellas.

Este controlador ha sido inspirado en el proyecto Pingüino-VE del “maestro” Joan Espinoza.

Este micro-controlador, servirá tanto de procesador de señales como de interfaz tanto por USB como por MIDI directamente. Este será el cerebro de la superficie de control. Se encargará de las siguientes funciones:

  • Recibir la señal de los pulsadores de la matriz (señales binarias)
  • Leer valores de entrada analógica (perillas, potenciometros, sensores de proximidad, de luz, de presión, etc)
  • Enviar las señales MIDI tanto por DIN-5 como USB
  • Dirigir todos los dispositivos y poder acoplarse a señales maestras

Acá podemos ver cómo se interconecta nuestra tarjeta con los demás elementos de la superficie de control:

Lectura del Teclado

La superficie de control se compone de un teclado en forma de matriz de 8×8, lo cual se logra multiplexando 3 bits con el integrado 74138 para enviar un pulso a cada una de sus 8 salidas (eje X) lo cual será leído en cada una de las 8 entradas (eje Y) del integrado 74151.

La lectura funciona de la siguiente manera: se envía la sucesión binaria-octal 000,001,010,011,100,101,110,111 en sus 3 puertos de entrada. Esto hará que se encienda, en cada una de esas combinaciones, una salida del 74138 (eje x).

Es decir: enviando en las entradas del 74138 el binario “010” activará el pin de salida 2, enviando el binario “011” activará la salida 3, etc.

Por cada uno de los envíos de estos octales, se leen secuencialmente las 8 entradas del 74151 para registrar cual está activo en ese momento, es decir, si hay o no un pulsador presionado. Esto sucede muchas veces por segundo, por lo cual presionarlo momentáneamente será suficiente para obtener una lectura.

Por un proceso inverso al funcionamiento del 74138, cuando se detecta la activación de un pulsador, el pin marcado como “R” del 74151 se activará y en sus salidas “abc” estará el octal correspondiente a cual pin ha sido detectado. Esta lectura también debe hacerse secuencialmente.

Así se recorre toda la matriz y se lee el teclado.

Los puntos que se ven en la matriz corresponden a los pulsadores que estarán en el circuito. Están colocados arbitrariamente, por lo cual este diseño da para hasta 64 pulsadores.

Es importante acotar que este teclado lee sólo una pulsación a la vez y pulsar dos teclas a la misma vez no dará el efecto deseado. Este diseño no necesita esa funcionalidad. Para permitir pulsaciones simultáneas es necesario acompañar cada pulsador con un diodo o una resistencia que haga unívoca la presencia de más de una pulsación simultánea. Más información aquí.

La lógica de leer el teclado y enviar la respuesta se resolverá con un FOR anidado, como se expresa en el siguiente pseudo-código:

apagar todos los pines 
for (x=0; x<8; x++) {
enviar octal "x" al 74138
for (y=0; y<8; y++) {
leer la entrada octal "y" del 74151
if y==HIGH {
salida MIDI: "activo x en y"
}
apagar el pin encendido
}
}

Como se lee en el código, se hará una lectura en barrido secuencial por el teclado enviando pulsos en los 8 pines del eje X, leyendo coincidencias por cada uno de esos pines en los 8 pines del eje Y.

Y aquí el esquema y el PCB de este circuito.

En el esquema eléctrico no está reflejada la presencia de las resistencias “pull-up” pero en el circuito impreso o PCB está un componente llamado “arr” el cual es un arreglo de resistencias de 1k.

Matriz de Leds

Este circuito compuesto por un integrado 74154 es un multiplexor de 4 a 16 que servirá para colocar sus salidas en una matriz de 4×4 que sirvan para indicar qué teclas se han pulsado. Al pulsarlas de nuevo su led se apaga.

La escritura no es en forma de matriz (componente x,y) sino que es una secuencia constante de 16 leds que se llamará desde los 4 bits (nibble) enviado a la entrada del 74154.

Para mantener el estado encendido/apagado de cada led, no se realiza como es común un proceso de round-robin sobre cada uno para activarlos por una fracción de segundo muy rápidamente, dando la ilusión de estar continuamente encendidos.

En este caso, se usarán flip-flops 74LS273 los cuales contienen ocho tipo D. Con esto, sólo es necesario enviar un pulso para encender o apagar el led deseado, manteniendo su estado hasta que un segundo pulso lo cambie a su contrario.

La entrada “CLK” habilita la escritura para el cambio de estado. En este caso se conectan en paralelo pues no se separarán en dos grupos lógicos de ocho, sino que se activará todo el circuito para escribir o apagar arbitrariamente el led deseado.

La entrada “RST” al recibir un pulso colocará todos los estados en cero, es decir, se apagarán todos los leds.

Acá los esquemas del PCB (dos caras) y el circuito.

Entradas Analógicas

Este es un proceso más simple: son 8 entradas que pueden registrar valores del 0 al 1023. Cualquier dispositivo que arroje valores análogos podrán luego ser interpretados dentro de esa escala. Acá pueden colocarse potenciómetros (lineales o logarítmicos), sensores de proximidad, sensores de luz, etc.

El valor que arroje esta entrada tendrá que ser interpretada por el programa para enviarse posteriormente como una señal MIDI (velocidad, portamento, pitch, etc)

Inicialmente este diseño tendrá dos potenciómetros y una fotoresistencia.

Fotografías del Proceso

Tenemos un primer prototipo 100% funcional de SEMERUCO MIDI.

CNC con Tecnologías Libres

Para potenciar el desarrollo tecnológico, productivo, industrial de Venezuela es necesario disminuir las dependencia de importaciones y consumo a la que se acostumbra. Se requiere la conciencia del pueblo y de cada ingeniero, artesano, tecnólogo, diseñador, técnico pueda aportar ideas y desarrollos de proyectos que permitan crear artículos de diversos índoles, y reproducirlos en el país con nuestros recursos. No es una tarea fácil, requiere mucha dedicación, conciencia y voluntad de querer formar parte de la solución.

Las tecnologías libres han sido a través de los años una alternativa viable frente a los desarrollos tecnológicos privativos, que siempre han sido orientados al neto beneficio económico del desarrollador. Las tecnologías libres permiten la libre adquisición, distribución, y modificación de los productos, lo que permite que a través del tiempo puedan ser mejorados y adaptados a las necesidades. El desarrollo de software libre desde hace algunos años ha avanzado hasta el punto de tener herramientas para todas las necesidades de los usuarios, pero no hay software sin hardware, y es precisamente ese punto el que ha sido poco abordado en el mundo.

Hemos tomado la iniciativa de promover la investigación de hardware libre, y crear herramientas que permitan ayudar a incrementar la producción industrial del país, así como también acabar con la inercia de consumo que solo ha permitido la prosperidad de quienes tienen el medio de producción.

El fin fundamental del siguiente proyecto es aportar a esa iniciativa, desarrollando un producto que puede ser utilizado en muchos sectores de la producción de los pequeños y medianos productores. Un control numérico computarizado (CNC) es una máquina que permite el movimiento de una partícula a través del espacio por medio de herramientas computacionales que le dan autonomía a la hora de elaborar el trabajo. La elaboración de su mecánica de trabajo es muy sencilla y puede ser adaptada a la necesidad del área de trabajo donde se necesite. El sistema de control del CNC siendo una tecnología libre puede ser construida por quien la necesite.

Básicamente, para hacer un CNC hay que tomar en cuenta tres principales áreas o disciplinas:

  • El Software
  • La Mecánica
  • La Electrónica

El Software

Es simple la elección del software que se usará, puesto que LinuxCNC es, a todas luces la mejor opción en Software Libre. El asunto consiste en decidir en qué tipo de hardware se ejecutará.

La vía más sencilla (y la más recomendada) es hacer uso de un computador con un puerto Paralelo DB25. Allí LinuxCNC conseguirá una forma directa de comunicarse con nuestro CNC.

Otra opción probada fue hacer uso de una tarjeta RaspberryPI pero la misma requiere modificaciones importantes al sistema operativo para poder hacer uso de un kernel RT. Para lograr esto, es necesario tener corriendo Raspbian con Wheezy e instalar LinuxCNC en la RaspBerry:

sudo apt-get install git 
git clone git://git.mah.priv.at/emc2-dev.git
git branch --track rtos-integration-preview3 origin/rtos-integration-preview3
git checkout rtos-integration-preview3
sudo apt-get update sudo apt-get install gettext autoconf libpth-dev bc gcc g++ make git libncurses5-dev libxaw7-dev libreadline-dev tcl8.5-dev tk8.5-dev bwidget libgtk2.0-dev python-dev python-tk python-lxml libboost-python-dev libtk-img python-imaging-tk python-xlib python-configobj python-gnome2 python-glade2 python-numpy libgl1-mesa-swx11 libgl1-mesa-swx11-dev python-gtkglext1 python-opengl freeglut3 libglu1-mesa libglu1-mesa-dev
cd emc*/src
./autogen.sh
./configure --with-threads=posix --with-platform=raspberry --enable-drivers --enable-simulator --enable-run-in-place

Luego será necesario instalarle un Kernel RT o de lo contrario sólo se podrá ejecutar LinuxCNC en modo simulación. En ESTA página están las instrucciones de cómo hacerlo.

La Mecánica

En esta sección se describe paso a paso la construcción de los CNC que hemos hecho en nuestro proyecto.

Primer Prototipo

El primer paso fue desarmar unas impresoras viejas:

Allí se recuperaron varias piezas que en la primera versión del CNC se usaron completas y otras piezas que desensambladas se convirtieron en partes de otras estructuras posteriormente.

Los motores encontrados (arriba a la derecha en la foto) son motores llamados “paso-paso” y sus detalles se describirán ampliamente pues hubo necesidad de investigar distintos temas para lograr el movimiento de los ejes del CNC usando estos muy importantes componentes.

Se procedió a armar un primer prototipo, procurando usar la mayor cantidad de piezas recicladas, empezando por su estructura básica que se derivó de una mesa doblada y oxidada de modo que se modificó, se pulió y se pintó esa estructura para usarla como base del primer CNC hecho en casa:

Luego se le colocaron los primeros rieles:

Y Arriba se colocó otro riel con un cabezal rotatorio equivalente al eje Z. Este modelo, aunque hizo su trabajo inicial, tuvo un error en el diseño de este eje y quedó como pendiente modificarlo para mejorar su precisión y su firmeza.

Este primer CNC recibió el nombre código “CALEMBE” como un apodo gracioso que hace ironía a su sincrética composición de piezas y partes.

Segundo Prototipo

Posteriormente, antes de emprender el cambio necesario en el Eje Z de “Calembe”, decidimos usar el esfuerzo y el tiempo en hacer otro CNC, usando como base una estructura metálica de aluminio la cual uniendo ángulos con remaches fue definiendo lo que sería la segunda máquina construida para este proyecto.

Nuevamente el Eje Z del CNC tuvo que ser modificado, pues cuando llegó el taladro de mano hubo que adaptarlo a las nuevas dimensiones del cabezal:

Tercer Prototipo

Con los conocimientos adquiridos durante la fabricación de los dos prototipos anteriores, se obtuvieron los conocimientos necesarios para emprender la contrucción del tercer prototipo, con el objetivo de lograr una máquina CNC con un nivel de precisión profesional y con estructura en capacidad para incidir sobre materiales metálicos.

Primero, resolvimos los rieles del eje X:

photo_2016-06-06_18-44-17.jpg
photo_2016-06-06_18-44-09.jpg
photo_2016-06-08_22-09-56.jpg
photo_2016-06-08_22-13-07_.jpg

Y presentamos los rieles para visualizar cómo quedará la estructura:

photo_2016-06-06_18-44-21.jpg
photo_2016-06-10_10-26-32.jpg

Partes para el Eje Z:

La Electrónica

la construcción del controlador (driver) de los motores es un paso necesario. Acá describimos todo lo necesario para construir uno.

Los Motores

Primero conozcamos cómo funcionan los motores PASO-PASO necesarios para un CNC

Se usaron en su mayoría motores “Shinano-Kenshi” modelo stp-42d221-03, que la empresa EPSON denomina con el modelo EM-336. Hay muy poca documentación sobre este motor. Hasta donde la vaga información que se maneja en los foros y comparando modelos, el em336 es el equivalente al estándard Numa17.

Al no haber una carta de especificaciones, se desconocían entonces alguno de los valores apropiados de impediancias y voltajes con lo cual se pueden calcular óptimamente la intensidad y duración de los pulsos que deben ser enviados a los motores para lograr la mejor relación velocidad-aceleración-fuerza de cada motor.

El “modo” de los motores define el tipo de respuesta que tendrá a cada patrón de señales que se les envíe. Estos modos permiten una precisión de 1.8 grados o 0.9 grados por pulso recibido. Es decir, una vuelta completa del motor requiere, dependiendo de cómo se configuren sus entradas, 200 o 400 pulsos de señal por revolución.

Estos modos son tres:

  • FULL STEP: 200 pasos por revolución. Rotación de 1.8° por pulso. Un pulso equivale a un paso completo en este modo.
  • HALF STEP: 400 pasos por revolución. Rota 0.9° en cada puso. Este modo disminuye en un 30% el torque (fuerza) del motor. El motor se comporta más silenciosamente en este modo.
  • MICROSTEP: Subdivisiones magnéticas que permiten ángulos menores por cada pulso. Cada subdivisión reduce el torque significativamente.

El Controlador

Ya el CNC estaba resuelto básicamente en sus funciones físicas de movimientos.

Comenzamos a diseñar entonces un circuito electrónico que movería los 3 motores.

En ese momento las señales para los movimientos de avance y retroceso de los ejes se generarían desde un PLC en el cual se grabaría un patrón cíclico.

Ese primer diseño usó integrados “Puente H” para conmutar las señales y convertirlas en los patrones necesarios que deben ser recibidos luego por una etapa posterior de potencia que alimentará los pines del motor con el patrón recibido.

Luego el diseño lo modificamos y quedó compuesto de la siguiente forma:

  • Etapa de control, en la cual cada pulso recibido desde la entrada es transformado en las señales que activarán las bobinas de los motores mediante integrados que reciben un pulso y una señal de dirección y lo secuencian a 4 salidas con los patrones para cada modo del motor (full, half o micro)
  • Etapa de potencia, donde las señales emitidas hacia las bobinas se elevan al voltaje y amperaje necesario para mover los motores
control.jpg
potencia.jpg
photo72818692763789503.jpg

En este punto tomamos la decisión de usar el puerto paralelo y no USB ya que el desarrollo de este último no está aún completamente implementado para el nivel de estabilidad que se necesita.

Este controlador entonces se conecta directamente al puerto paralelo de un computador, usando una interfaz de simples cables en un conector DB25 estándar

Entre otras opciones posibles está el uso de ethernet para el envío de las señales pero es un desarrollo también en proceso y no recomendado aún para aplicaciones que tengan como meta la producción. Asimismo, hay desarrollos como HAL2Arduino el cual usa un Arduino a través del puerto USB como pasarela hacia el controlador. Esta opción aún no la hemos explorado en este proyecto (pero lo haremos).

NOTA: nuestra investigación arrojó que NO es posible usar una interfaz DB25-USB de las que venden comercialmente para tener un puerto paralelo en cualquier computador portátil moderno. No es posible puesto que los tiempos de latencia interna de estos dispositivos es muy alto para las necesidades de LinuxCNC.