Placa electrónica de control de respirador con motor paso a paso usando un microcontrolador STM32

Habiendo diversos diseños en 3D de respiradores, bastantes de ellos basados en motores paso a paso (stepper motor), se propone el diseño de una placa electrónica de control basada en microcontroladores STM32, concretamente el microcontrolador STM32F103C8T6 que usa la placa de desarrollo Bluepill.

Aunque no haya un diseño único de respirador 3D, la mayoría de ellos se controlarán de forma similar, usando un motor paso a paso, finales de carrera, sensores de flujo y presión, etc.

Se propone la placa Bluepill en este hilo por la gran cantidad de librerías existentes para esta plataforma, que incluyen  periféricos de diversos tipos (conversores ADC, DAC, pantallas LCD, teclados, sensores de diferentes tipos, buses I2C, SPI y USB, etc).

Además de que mi propia experiencia con este tipo de dispositivos puede evitar problemas habituales que suelen aparecer.

Dispongo de alguna placa para el montaje de algunas partes de lo que sería el prototipo, de tal forma que puedo ensayar algunos montajes, partes del software, comportamiento de algunos sensores o drivers, etc.

FASE PRIMERA:
Crear una placa electrónica de control que sea funcional, aunque no sea bonita.
El propósito es tener lo antes posible algo que pueda poner en marcha el respirador de forma adecuada.
Cuando digo placa electrónica, no me refiero a que sea una única placa electrónica, de hecho va a estar formada por varias placas electrónicas conectadas de forma adecuada.
Para esto, debido a la finalidad (soporte vital), queda descartado cualquier montaje con cables de "quita y pon" en protoboards.
Todo se debe de hacer en placas soldadas adecuadamente (aunque sean módulos de desarrollo), con conectores adecuados o conexiones atornilladas.
En sucesivas fases ya se mejorará el diseño y se creará una placa definitiva.

PLACAS A UTILIZAR:
1.- Bluepill, placa económica y de "muy alta disponibilidad", al menos en el mercado oriental, formada por un microcontrolador STM32F103C8T6 cuyas principales características, entre otras, son: reloj a 72 Mhz (o 48 Mhz si se utiliza el bus USB), 10 conversores ADC de 12 bits cuyo tiempo de muestreo es de microsegundos, pines de 3.3V tolerantes a 5V, varias UARTs, buses I2C y SPI, y PWM.
2.- Módulo de expansión I/O a través de I2C basado en el circuito integrado PCF8574.
3.- Pantallas LCD 16x2 (16 carácteres y 2 líneas).
4.- Teclados 4x4 (keypad de membrana), que será mucho más apropiado para desinfectar la propia máquina cuando lo requiera que otro tipo de pulsadores o interruptores.
5.- Conversores ADC basados en los circuitos integrados ADS1115 (16 bits) o en el circuito integrado HX711 (24 bits) que incorporan amplificadores PGA diferenciales adecuados para señales de puentes de Wien.
6.- Conversores DAC de 12 bits basados en el MCP4725.
7.- Drivers de motores paso a paso, como el TB6560AHQ, que admite corrientes de 3A y 34V, con hasta 64 micropasos.
8.- Placas conversoras de tensión continua DC-DC para alimentar las placas de control, sensores y la placa de potencia.
9.- Placas para la carga y utilización de una batería de soporte, como por ejemplo una de 12V/7Ah, aunque en caso de necesidad y urgencia, esta parte se puede omitir y se podrá acoplar una SAI (UPS) adecuada.

SOFTWARE DE PROGRAMACIÓN DEL MICROCONTROLADOR:
Se puede usar tanto linux como windows para desarrollar y programar este microcontrolador.
Hay que instalar ciertas herramientas software de desarrollo y algunas librerías, que indico a continuación:
1.- El software de Arduino.
2.- El stm32duino de "rogerclarkmelbourne (Roger Clark)", no el de ST oficial (este último no tiene ciertas herramientas útiles para el desarrollo, o no funcionan correctamente, como es el puerto serie virtual a través del USB).
3.- El bootloader de Roger Clark para la placa Bluepill, led PC13.
He de indicar que para que funcione correctamente hay que recurrir a una versión antigua de este bootloader y configurar en el software "Arduino" la velocidad de reloj a 48 Mhz y no los 72 Mhz que hay por defecto.
Son pequeños errores que he ido viendo y que posiblemente resolverán en un futuro, si es que no lo han resuelto ya.
Además hay que modificar una resistencia en la placa del Bluepill correspondiente a las líneas del bus USB para que funcione este bus.

Entiendo que aunque no especifique direcciones URL, los programadores con algo de experiencia que quieran colaborar entenderán perfectamente todo lo que indico, y si no es así posiblemente les cueste demasiado empezar con esto.

Habiendo indicado las nociones básicas de lo que propongo, dejo que más gente colabore en esto, en la medida en que cada uno pueda o esté capacitado, para que entre todos podamos obtener algo que se pueda utilizar y que pueda ayudar a alguien que lo necesite en un futuro.

Como muestra de algunos de los componentes indicados, aunque no estén montados para este desarrollo, si que dan una idea de lo que se puede utilizar:

«1

Comentarios

  • Hola José!

    ¡Tiene muy buena pinta el proyecto! ¿Qué necesitarías para poder avanzar en el proyecto? 


  • Buenas noches elsatch
    Lo que me hace falta es colaboración.
    Técnicamente yo sería capaz de desarrollar todo el proyecto, pero al ser una persona sóla me llevaría demasiado tiempo.
    El apoyo conjunto de programadores, electrónicos, informáticos, matemáticos, médicos, etc. reduciría bastante el tiempo.
    Lo que hay que hacer lo tengo claro.
    Cómo se hace también.
    Y estoy convencido de que todo va a funcionar (esto por mi experiencia en todo esto).
    Así que si puedes indicarme lo que se te da mejor, podremos ver como avanzamos conjuntamente.
    Te puedo indicar que hay librerías de este microcontrolador y funciones que ya he usado y testeado.
    El problema es que hay algunas librerías por internet (github, adafruit, etc.) que no funcionan como deberían, y hasta dar con la adecuada uno pierde bastante tiempo.
    Puedo indicar librerias consideradas "buenas":
    - NewLiquidCrystal.
    - Comunicación USB (puerto serie virtual) de Roger Clark.
    - ADS1115 de baruch
    .. etc.

    Luego hay también otras herramientas que he utilizado que han funcionado bastante bien, como un DataLogger llamado OpenLog (de Adafruit), bastante práctico para analizar datos.

    Bueno, tu me diras lo que te gusta ..
  • Ahora mismo lo que se me da mejor es conectar gente ( y hacer los resúmenes del foro!). Voy a incluir este proyecto, que saldrá en el boletín de las 08:00, para que se sume más gente.

    Aunque también programo, creo que voy a ser más útil así.

    Gracias por la propuesta y por tus aportes!
  • Como dice un antiguo profesor mío.. divide y vencerás, o el amigo Jack, vayamos por partes.

    Enumero partes o bloques de lo que constará el sistema (aparte del sistema mecánico en 3D).
    A priori una buena aproximación sería:
    1.- SAI (UPS) de 230V/50Hz. No vamos a complicarnos en algo que ya esta diseñado y disponible.
    2.- Alimentación de unos 32V a partir de fuentes industriales comerciales. No se nesitaría mucha potencia, posiblemente con una de 200W sea suficiente. No se ha elegido una tensión superior por la propia limitación que existen en numerosos drivers de motores paso a paso y circuitos integrados, aunque existen algunos de tensiones de alimentación más altas.
    En la parte de alimentaciones también estarían las placas conversoras de tensión DC-DC que suministrarían 12V, 5V, 3.3V, -5V, etc.
    3.- Placa de control, con el microcontrolador indicado.
    4.- Teclado y LCD.
    5.- Placa de potencia con el driver del motor paso a paso.
    Para mejorar el diseño, esta placa de potencia puede controlar completamente el motor, llevando también un segundo Bluepill (microcontrolador STM32F103C8T6) y así permitir un desarrollo mucho más rápido y eficiente.
    Se establecería un protocolo de comunicaciones entre ambas placas del tipo maestro-esclavo que evitarían una programación muy compleja en tiempo real si sólo se usara un microcontrolador.
    6.- Placas auxiliares con detección de posicionamiento o encoder optico del motor paso a paso. Esto estaría conectado a la placa anterior. Con este tipo de sensores se podría estimar el volumen instantáneo del balón.
    7.- Placa de acondicionamiento de señales (sensor de flujo, sensor de presión, oxímetro de dedo, etc.).
    8.- Placa de actuadores secundarios (zumbador o alarma, reles, etc.)
    9.- Placa con reloj en tiempo real RTC.
    10.- Placa OpenLog con tarjeta microSD para almacenamiento de datos (cuya finalidad es el testeo y la calibración de sensores).
    11.- Placa de comunicaciones o control externo (comunicación con ordenadores usando el propio puerto USB o mejor un adaptador USB UART-TTL, con buses RS485, modbus, serie, ESP8266, ESP32, etc.) para que una enfermera pueda estar controlando multitud de pacientes en una pantalla de ordenador o en el movil.
    También servirá para permitir la programación de "programas" y "parámetros" de funcionamiento "predefinidos" usándo un PC y no la pantalla pequeña.
    12.- Servidor externo que permitiría la recolección de datos para que funcionara el punto 11. Se podría usar un router con OpenWrt, un PC servidor con linux por ejemplo, apache, Iot, mosquitto, etc. Esto ya es para un futuro, no propiamente del diseño del respirador.
  • Hola, ciertamente, un proyecto así necesita colaboración. Estoy pensando en lanzar el reto a mis ex-alumnos del año pasado. En la asignatura usamos STM32 para hacer prácticas, programando en C y usando Atollic True Studio como IDE. En concreto, usamos la placa STM32F429 DISC1, una placa de desarrollo muy interesante y de coste contenido (35€) que incluye una pantalla LCD 320x240 color que podría servir para implementar la interfaz de usuario. Teniendo en cuenta la comunalidad entre los diferentes dispositivos de la familia STM32, portar el código de un dispositivo a otro debería ser fácil y los alumnos están familiarizados con esta en concreto.
    Para tener una respuesta efectiva creo que sería necesario diseñar bien la arquitectura de software y definir en detalle los módulos que hay que implementar y las interfaces. Supongo que para hacer esto hay que tener un conocimiento de cómo funciona un respirador y aquí yo no puedo ayudar (no tengo los detalles).
    Otro aspecto que me preocupa es que toda esta iniciativa es, en gran medida, una respuesta a la rotura de las cadenas de suministro de los fabricantes industriales de respiradores. Quizá deberíamos pensar en un sistema modular que pueda funcionar con diferentes dispositivos periféricos (motores, sensores, etc.) no sea que cuando tengamos el diseño no podamos encontrar los componentes que necesitamos. Para ello, supongo que la arquitectura del SW debería incluir una capa de HAL que permitiese una independencia del HW usado. Si tenemos recursos suficientes, alguien podría estar haciendo el módulo para el sensor A, otro para el sensor B, etc.
    Supongo que son reflexiones obvias, pero si empiezan a aparecer recursos que ayuden, tenerlo estructurado nos iria bien.
  • Uff, lo he enviado antes de acabar. ¿Cómo veis lo de lanzar la iniciativa a ese grupo?

  • Buenos días Josep
    Conozco la placa STM32 que indicas, de hecho estaba dudando en usar la STM32F4DISCOVERY, la hermana pequeña de la STM32F429, pero he pensado que placas mas económicas y accesibles para todos podrían servir mejor para desarrollar librerías o hacer pruebas.
    Siempre habrá tiempo de saltar a estas placas.

    Uno de los problemas que me he encontrado en el pasado con la placa STM32F4DISCOVERY es que usaba ya pines para circuitos integrados de audio y otros sensores que hacen complejo el estar analizando esquemas electrónicos.

    Una mas sencilla, mas simple y mas "virgen" me parece mas adecuada.

    En cuanto a la pantalla LCD gráfica me parecería bien, si no fuera porque puede generar problemas y no hay tiempo para estar complicándose la vida:
    - Obliga a un software mas complejo.
    - Puede impedir crear un sistema mas robusto (en tiempo real), que no se vea obligado a usar RTOS.
    - Limita la portabilidad si se basa en interfaces gráficas de pantallas determinadas.

    Por mi experiencia cuando trabajaba en grupos de programadores, no recomiendo que trabaje varia gente sobre lo mismo.
    Me acuerdo que el programador de la tarde modificaba lo que hacia el de la mañana, y este lo que hacia el anterior la tarde anterior.

    Habiendo dicho esto, si quieres desarrollar una especie de controlador de pantalla gráfica que se base en esta plataforma y que incluya la pantalla y el teclado, puedes hacerlo (sería un añadido "opcional").
    Se debería comunicar por un puerto serie UART, por ejemplo, con el microcontrolador principal, y actuaria como esclavo.
    Toda la comunicación en ASCII, de forma parecida a la indicada para el controlador de motores.

    Por su sencillez, y practicidad en cuanto a la programación, de momento se seguirá usando un LCD y un teclado como los indicados inicialmente, que usan el bus I2C para la comunicación.
  • De acuerdo, de momento no lanzo la iniciativa. Es verdad que, a menos que seamos capaces de tener unos bloques bien definidos con unas interfaces claras, tener a varios programadores trabajando simultáneamente no tiene mucho sentido.

  • Hola buenos dias! 
    De programación y electrónica no se nada, pero de diseño 3d bastante. Además mi madre es matematica y mi padre médico. Si podemos ayudar en algo estamos a tu completa disposicion.
  • editado 18 de marzo
    roncolas dijo:
    Hola buenos dias! 
    De programación y electrónica no se nada, pero de diseño 3d bastante. Además mi madre es matematica y mi padre médico. Si podemos ayudar en algo estamos a tu completa disposicion.
    He visto algunos modelos de respiradores.
    Si se utiliza un respirador AMBU como base, el caudal de 200l/min se puede conseguir aumentando el tamaño del motor paso a paso de algunos de los diseños y aumentando la potencia de este con mayor tensión de alimentación y mayores velocidades (PPM), y optimizando el comportamiento y la dinámica del sistema con una rueda dentada reductora en alguno de los diseños.
    En cuanto al posicionamiento se puede realizar con sensores de efecto hall como el OH49E o SS49E y dos pequeños imanes, como los de neodimio usados en los falsos pendientes, digo esto porque los finales de carrera realizados con optoacopladores pueden fallar por interferencias con la luz solar, mandos de infrarrojos, etc.
    Los sensores de efecto hall son mas inmunes a fallos que los sensores ópticos si se colocan bien.

    El siguiente diseño es del argentino Jeremias Almada:


    Como ejemplo de prototipo parece adecuado, pero creo que necesita mejoras.

    Particularmente le haría estas modificaciones:
    1.- No acoplaría directamente el motor a la correa dentada, sino que montaría una rueda dentada intermedia reductora, para mantener un régimen de giro mas alto en el motor paso a paso y así poder ajustar muchísimo mejor la curva de posicionamiento (curva volumétrica) a lo deseado. Ver el hilo que he abierto al respecto (nadie tiene en cuenta las relaciones de transmisión).

    2.- Los soportes de los brazos generan un momento sobre los cojinetes lineales, que desajustarían el sistema tras varios ciclos de uso, siendo mejor poner 4 cojinetes por brazo en vez de 2.

    3.- En los brazos pondría algo similar a ruedas de monopatin o algo similar, que minimizaran el rozamiento con el balón hinchable, ya que este pequeño rozamiento, tras miles de movimientos acabarían dañándolo.

    4.- Distribuir hasta 10 sensores de efecto hall en un soporte bajo los patines, por ejemplo.
    Esto ayudará a corregir el posicionamiento en caso de pérdidas de pulsos y reajustar el sistema.

    5 sensores para un patín y 5 para el otro, teniendo un "desfase" entre un patín y otro de "medio" segmento.

    No todo tiene que ser impreso, a veces hay algunas cosas fácilmente realizables por otros métodos.
    Hoy hay empresas de corte de planchas por láser bastante buenas y con una precisión muy buena.

    Adaptador de conectores o vías a sensores de presión:
    Lo que posiblemente sí pueda hacer falta puede ser una T que permita interceptar la canalización de salida de gases del AMBU.
    No sé si alguna de las válvulas ya dispone de algún pitorro que permita colocar una vía de silicona.
    El propósito de esto es poder colocar un sensor de presión.
    Desconozco el diámetro interno/externo que se usan en estos casos, pero posiblemente estén alrededor de 3 o 4 mm de diámetro externo.

    Como ejemplo de sensor de presión, aunque posiblemente no sea este concretamente, tenemos el MPXV7002:
    https://www.nxp.com/docs/en/data-sheet/MPXV7002.pdf

    Ahí podrás ver las dimensiones de su pitorro de varios modelos, unos 3mm aproximadamente mas el reborde cónico.
    El impreso tendrá que tener paredes algo mas gruesas, ya que los plásticos usados suelen ser algo menos resistentes.

    Desconozco las características técnicas del conexionado del AMBU.

    Mucho cuidado si se decide imprimir esta "T", fisuras o roturas durante su uso podrían ser "delicadas".

    Antes de empezar a diseñar esta T buscaría si hay algo que haga esta función.
  • editado 18 de marzo
    Josep_M_R dijo:
    De acuerdo, de momento no lanzo la iniciativa. Es verdad que, a menos que seamos capaces de tener unos bloques bien definidos con unas interfaces claras, tener a varios programadores trabajando simultáneamente no tiene mucho sentido.

    Buenas tardes Josep
    He estado definiendo un protocolo de comunicaciones y una cosa que he llamado Mapa de Registros Virtual.
    Mira el hilo:
    https://foro.coronavirusmakers.org/index.php?p=/discussion/206/protocolo-de-comunicacion-jpmsmrv-maestro-esclavo-de-usb-uarts-de-microcontroladores-y-pcs#latest
    Y el pdf que he adjuntado por si quieres imprimirlo.
    Espero que captes la idea, para así poder desarrollar fácilmente todo.

    Te puedes crear tu propio MRV y decirme como es, ya que la interfaz gráfica puede ser independiente al funcionamiento del resto.
    Se transmitirían los registros que se modificaran en caso de actualización y habría periódicamente chequeos (polling) en el caso de actualización de registros.

    Ten en mente que STM32F429 DISC1 (LCD+Keypad) siempre actuará como esclavo, reciviendo los datos a través de la UART.

    Puedes sustituir la UART por el puerto USB o utilizar un adaptador USB-UART TTL para verificar y testear el comportamiento de este bloque.

    Lo digo porque también se puede añadir la librería JPMSMRV a un pequeño programa de PC que permita controlar, monitorizar o actualizar los datos o parámetros.

    Este software para PC puede ser muy simple, con una línea de comandos con cosas muy básicas para la escritura y lectura de registros.
    O algo mas complejo, con interfaz gráfica, para hacer test algo mas complejos.

    Si se puede, este mismo software con o sin interfaz gráfica podrá utilizarse para testear otras placas, como es el caso de la placa controladora de motor paso a paso, que tiene su propio MRV.

    Hay otra placa que también se podrá testear con este software de PC:
    https://foro.coronavirusmakers.org/index.php?p=/discussion/comment/177#Comment_177
    De hecho, se tendrá que realizar una App específica para PC.


  • Buenas noches,

    Me llamo Daniel Diez, soy ingeniero mecánico y maker, actualmente trabajo en una empresa diseñando máquina herramienta y me enfrento a diseños con motores, transmisiones, sistemas de guiado etc en mi día a día.

    Estoy viendo los diseños que se han realizado, y el que mas me convence es este último que habéis puesto, pero como bien dice Jose-Pizarro, tiene algunas carencias a resolver.. tengo bastante experiencia con los nema 17, había pensado en solucionar el tema de la reducción usando un husillo trapezoidal para el movimiento lineal y algunas cosas más.. tengo bastante material en casa, voy a realizar un diseño y os lo enseño.

    Saludos!
  • Buenas noches, soy ingeniero electronico de argentina, con mi hermano hacemos automatizaciones. Me parece que hay un nivel de integración baja para desarrollar rápida y confiablemente un producto. A que me refiero, que tal vez deberían considerar utilizar productos industriales directamente. Hoy todas las empresas que proveen tornillos de bolas recirculantes, guias lineales, servomotores, electrovalvulas, PLC, HMI, reguladores, sensores, etc seguramente van a aportar para solucionar esto. El costo de todo después se vera como se paga. (Muchos pueden aportar con donativos, campañas por redes sociales, etc para solventarlo pero eso es otra etapa). No se que opinan pero me parece que el tiempo apremia.
    https://www.youtube.com/watch?v=1t2t8d8xtD0

    AMBU que hicieron en RICE (Rice engineering majors breathe new life into ventilators in low-resource settings)


    Recien ingreso a este foro, disculpen si aporto información repetida o que no aporta al proyecto que están encarando, mi idea es ayudar en este momento tan critico.
    Saludos!

  • Buenas noches, soy ingeniero electronico de argentina, con mi hermano hacemos automatizaciones. Me parece que hay un nivel de integración baja para desarrollar rápida y confiablemente un producto. A que me refiero, que tal vez deberían considerar utilizar productos industriales directamente. Hoy todas las empresas que proveen tornillos de bolas recirculantes, guias lineales, servomotores, electrovalvulas, PLC, HMI, reguladores, sensores, etc seguramente van a aportar para solucionar esto. El costo de todo después se vera como se paga. (Muchos pueden aportar con donativos, campañas por redes sociales, etc para solventarlo pero eso es otra etapa). No se que opinan pero me parece que el tiempo apremia.
    https://www.youtube.com/watch?v=1t2t8d8xtD0

    AMBU que hicieron en RICE (Rice engineering majors breathe new life into ventilators in low-resource settings)


    Recien ingreso a este foro, disculpen si aporto información repetida o que no aporta al proyecto que están encarando, mi idea es ayudar en este momento tan critico.
    Saludos!

    Hola Nicolas

    Me parece muy bien lo que comentas.

    Parece muy sencillo pedir de forma altruista componentes "caros" a distribuidores o fabricantes.

    No digo que alguno no responda, el problema va a venir por la disponibilidad.

    Normalmente los productos caros no se fabrican tan en masa como los productos económicos.

    Sobre todo porque si la competencia fabrica un modelo más avanzado el primer fabricante se queda con los almacenes llenos de dispositivos obsoletos, caros, que tendrá que vender a un precio incluso menor al de fabricación o se los tendrá que comer con patatas.

    Elige un PLC, el que quieras, que sea válido para el control preciso de un motor paso a paso (pensando en un respirador basado en AMBU).

    Mira su coste y disponibilidad.

    Si hay stock suficiente y el fabricante está dispuesto a cederte estos dispositivos, adelante.

    Ponte a programarlo para implementar lo que se necesita.
    Abre un hilo y empieza con las colaboraciones.

    Lo indicado para el PLC aplícalo al resto de componentes necesarios.

    NADIE IMPIDE que se desarrollen paralelamente diversas líneas de actuación.
  • Hola Jose.

    Soy responsable del diseño de PCB de mi empresa, además llevo parte de la integración de dichas tarjetas. Nos dedicamos a la realización de amplificadores de estado solido por lo que en principio no debería de haber problemas de integración en soporte digital, RF o potencia.

    Quizá te interese que realice el diseño de un PCB para ese esquema. Aunque eso por un lado haría que la fabricación dependerá de tener también ese PCB creo que podría aportar muchísimo valor en velocidad de replica.

     Por otro lado podría hablar con fabricantes nacionales de PCB a ver si alguno esta dispuesto a ayudarnos, por lo menos, con los tiempos de fabricación, cadenas de montaje, etc.

    Quedo a la espera de tus comentarios.

    Ánimo!
  • Buenos días Antonio
    Como casi todos los electrónicos nos hemos dedicado en algún momento al diseño PCB.
    Yo trabajé hace tiempo con 2ci:
    https://www.2cisa.com
    Y tienen la capacidad técnica para realizar las placas en horas, y sus acabados son buenos.
    En el Polígono Industrial de Málaga también tienen líneas de montaje otra empresa.
    Pero estoy desconectado de todo esto desde hace años.
    La parte electrónica no me preocupa, con dinero al final se podrá hacer casi todo, aunque salga caro.
    De momento a intentar conseguir un prototipo que sea 100% funcional y que sirva para mantener a los enfermos vivos el tiempo suficiente para que se curen.
    Gracias por tu ofrecimiento, estamos en contacto.

  • Perfecto.

    Cuando tengas el prototipo funcional valora si se pudiera poner todo en una tarjeta. con conectores para cada elemento en la disposición adecuada. Para que sea montar la tarjeta completa en la mecánica con la menor dificultad.

    Dependiendo de los componentes puedo realizar un diseño lo más económico posible. La verdadera ventaja es que si no hay que cablear se pueden fabricar muchos respiradores en pocas horas. Además de que podría hacerse en más de una localización.

    Ya habrá tiempo de de hablar de fabricantes y montadores. Hay bastantes gracias a Dios. En ese aspecto la verdadera lógica podría ser mandar Software, Gerber, BOM y ficheros STL para impresión por todo el territorio nacional para que se fabrique, monte y distribuya de manera paralela por quien quisiera aportar.

    Estoy a tu disposición.

    Ánimo!
  • Intentaré que todo se pueda poner en una placa.
  • Hello guys! My name is Samuel Marciano.I'm currently living in Brazil.I worked during 4 years at a hospital.As a biomedical techinician.I was assigned to do the maintenance of all medical stuff , lung ventilators included.I'm also doing my major in eletrical and Electronics engineering, so I have a bit of experience in the biomedical area to draw on.I hope I could help you guys iwith it.Feel free to contact me:

    Email:marcianosamuel@gmail.com
    Skype I'd: samuelluiz25
    What's app: +55 19999533461
  • Tengo conocimientos en la serie de microcontroladores que describen y programo aplicaciones de escritorio en lenguaje c# y quisiera colaborar y aportar mis conocimientos para esta buena causa. 
  • editado 19 de marzo
    Tengo conocimientos en la serie de microcontroladores que describen y programo aplicaciones de escritorio en lenguaje c# y quisiera colaborar y aportar mis conocimientos para esta buena causa. 
    Buenas noches Ariel_arias
    Me alegra que haya más gente que colabore.

    Creo que una de las primeras cosas que se debieran realizar es un software de test (lo que viene a ser el software o modo de ingeniería).

    Estoy implementando una libreria con funciones muy basicas para permitir la comunicación entre microcontroladores, PCs, etc.
    La librería la he llamado JPMSMRV.
    Se basa en un Mapa de Registros Virtual.
    Cada posición de ese mapa será un parámetro, variable, dato, etc. lo que se quiera definir.
    Toda la comunicación entre dispositivos consistirá en leer o escribir registros de ese mapa.
    Sólo hay dos funciones en esta API, así que para los programadores será muy fácil de manejar.
    Se pueden leer o escribir registros de forma individual o por bloques en un sólo comando.

    Las especificaciones de este protocolo las indico en:
    https://foro.coronavirusmakers.org/index.php?p=/discussion/206/protocolo-de-comunicacion-jpmsmrv-maestro-esclavo-de-usb-uarts-de-microcontroladores-y-pcs#latest
    Hay un pdf por si quieres imprimirlas.

    Para enlazar esta librería con C# se puede usar lo indicado en paginas como esta:
    https://github.com/mrts/mono-static-linking
    Al menos en linux, supongo que windows no generará problemas.

    Sabiendo como funciona el MRV, creo que lo que se pudiera hacer también en un principio es algo que permita obtener las variables y poder modificar parámetros de una aplicación para PC.
    Esta en concreto:


    Igual para hablar mas detenidamente de detalles sería mejor que me mandases algún mensaje al correo con tus dudas.
  • editado 19 de marzo
    Ariel_arias he dejado un ejemplo del Mapa de Registros Virtual en un documento pdf en el hilo de la libreria JPMSMRV.
    He creado un ejemplo de uso de la librería JPMSMRV y cómo se maneja el Mapa de Registros Virtual (MRV).
    Adjunto el pdf.
    El ejemplo es de la aplicación que se está viendo aquí.
  • Hola José,
    dejé un post en el hilo General/fabricación. mi empresa se dedica al montaje de PCB y tengo buena relación con fabricantes de PCB. Si te puedo ayudar con algo no dudes en contactar conmigo.
    muchas gracias.

  • En cuanto al posicionamiento se puede realizar con sensores de efecto hall como el OH49E o SS49E y dos pequeños imanes, como los de neodimio usados en los falsos pendientes, digo esto porque los finales de carrera realizados con optoacopladores pueden fallar por interferencias con la luz solar, mandos de infrarrojos, etc.
    Los sensores de efecto hall son mas inmunes a fallos que los sensores ópticos si se colocan bien.

    El siguiente diseño es del argentino Jeremias Almada:


    Como ejemplo de prototipo parece adecuado, pero creo que necesita mejoras.

    Particularmente le haría estas modificaciones:
    1.- No acoplaría directamente el motor a la correa dentada, sino que montaría una rueda dentada intermedia reductora, para mantener un régimen de giro mas alto en el motor paso a paso y así poder ajustar muchísimo mejor la curva de posicionamiento (curva volumétrica) a lo deseado. Ver el hilo que he abierto al respecto (nadie tiene en cuenta las relaciones de transmisión).

    2.- Los soportes de los brazos generan un momento sobre los cojinetes lineales, que desajustarían el sistema tras varios ciclos de uso, siendo mejor poner 4 cojinetes por brazo en vez de 2.

    3.- En los brazos pondría algo similar a ruedas de monopatin o algo similar, que minimizaran el rozamiento con el balón hinchable, ya que este pequeño rozamiento, tras miles de movimientos acabarían dañándolo.

    4.- Distribuir hasta 10 sensores de efecto hall en un soporte bajo los patines, por ejemplo.
    Esto ayudará a corregir el posicionamiento en caso de pérdidas de pulsos y reajustar el sistema.

    5 sensores para un patín y 5 para el otro, teniendo un "desfase" entre un patín y otro de "medio" segmento.

    No todo tiene que ser impreso, a veces hay algunas cosas fácilmente realizables por otros métodos.
    Hoy hay empresas de corte de planchas por láser bastante buenas y con una precisión muy buena.

    PARA LA GENTE QUE ME PREGUNTA LA LOCALIZACIÓN DE ESTE DISEÑO 3D:

    No he encontrado los archivos del modelo de respirador 3D con el globo verde que hay más arriba, solo una foto en Facebook.

    Es el del argentino Jeremias Almada y es el diseño que veo más apropiado de los que he visto, aunque no los he visto todos.
    https://www.facebook.com/groups/670932227050506/photos/

    Necesita las modificaciones comentadas para que funcionara bien:
    la rueda dentada reductora, los 4 cojinetes lineales por patin, las ruedas de monopatín o patines para reducir el rozamiento de la bolsa AMBU,etc.

    Un diseñador de 3D podría modificar su diseño para adaptar estas modificaciones.
    Es inviable el uso de motores Nema 17 y Nema 23, hay que usar motores Nema 34, aunque cuesten 60 euros en vez de 20.
    Así que la rueda dentada reductora (2 ruedas dentadas dentadas unidas) hay que acoplarlas a un motor Nema 34.

    Además de las modificaciones indicadas:
    - El uso de rodamientos a bolas para la rueda dentada reductora y la polea opuesta.
    - Un puente sobre la rueda dentada y sobre la polea opuesta para fijar firmemente el eje del rodamiento.
    Si no se fija bien este eje, las fuerzas y holguras podrían hacer que la rueda se moviera o que se saliera la correa, o el acoplamiento con los piñones del motor.
    - Hace falta también un sistema de tensado de la correa (las impresoras usan un muelle).
    La situación de este muelle en las impresoras:
    - En la polea opuesta al motor.
    - En el extremo de la correa.
    Por sencillez, yo dejaría la polea fijada y tensaría la correa con un muelle en la unión con el patín.
    Un muelle tensado fuertemente, sin llegar a romper la correa dentada.
    La correa dentada debe de ser del grosor y tamaño adecuados, ya que se va a ver sometida a grandes fuerzas.
    No tiene por que ser muy grande, pero nada de usar esas finísimas de los juguetes.
    Tengo por ejemplo una que compre hace tiempo que parece resistente, era económica (compré 10 metros) y era el paso estandard de los engranajes que se utilizan habitualmente para multitud de cosas (era de goma negra con refuerzos internos de fibras con un olor muy fuerte).
  • Hola José,
    dejé un post en el hilo General/fabricación. mi empresa se dedica al montaje de PCB y tengo buena relación con fabricantes de PCB. Si te puedo ayudar con algo no dudes en contactar conmigo.
    muchas gracias.

    Buenas tardes sergioalvarez

    En este mismo foro estoy en contacto con más diseñadores electrónicos, concretamente Antonio_PCB está colaborando también.

    Es bueno saber que se pueden realizar montajes aquí mismo.

    No se ha dicho todavía ningún número, pero yo ya tengo uno en mente.
    Abriré un hilo para que haya una referencia de a qué nos tenemos que enfrentar en cuanto a la disponibilidad de componentes, viabilidad técnica, etc.

    Pasate por el hilo de colaboración y deja el comentario indicado.
    https://foro.coronavirusmakers.org/index.php?p=/discussion/298/coordinacion-de-colaboradores-diseno-electronico-y-programacion#latest

    sergioalvarez, montaje de PCB, en estudio

    Aunque al final la fabricación de PCB la gestiones tú, es preferible poner las cosas muy concretas, para no crear confusiones.
    Si hay posteriormente algún fabricante de PCB que se quiera ofrecer a colaborar, que no piense que hay alguien ya encargado de eso.

    Gracias por colaborar, toda ayuda es bienvenida

  • jesconsa dijo:
    Buenas noches jesconsa

    El motor paso a paso que estoy recomendando por potencia necesaria es un Nema 34, así que el Nema 17 es muy pequeño.

    La velocidad de los husillos suele ser mas baja de lo que se necesita.
    Hay un hilo en donde se hace incapié en tener una relación de transmisión más o menos adecuada, para un régimen de giro del motor paso a paso entre 800rpm y 1600 rpm.

    El eje, depende de la masa que tenga, generará un momento de inercia que puede que no sea bueno tener.

    Las ruedas reductoras y correas suelen tener menor momento de inercia por la propia geometría y por menos masa, al ser fabricadas también con materiales menos densos que el acero (están hechas de plástico).

    Hay guías supereconómicas que nadie están utilizando, las de los cajones.
    Llevan bolas, deslizan suavemente, pero tienen inconvenientes:
    Se pueden desmontar, se pueden oxidar, su limpieza es casi imposible, tienen un rango de movimiento muy limitado, aunque sean muy largas.

    Por eso las guías que está utilizando los modelos de respiradores con movimientos lineales son ejes cilíndricos con cojinetes de desplazamiento lineal.

    De todas formas, gracias por la aportación, todos los comentarios que sumen son bienvenidos.
  • Buenas tardes, acabo de leer este hilo. Trabajo en Omron Iberia. Fabricante de sistemas de control industrial, entre ellos PLC's, servomotores y pantallas. Por favor, puedo ayudaros en algo?
  • Buenas noches Raul_nicolas
    Estoy valorando lo que puede hacer falta, además de estar programando y ensayando bastantes cosas.
    Me falta tiempo para llevarlo todo como quería, posiblemente sí que se necesiten fuentes de alimentación industriales para alimentar la electrónica, tanto la de potencia como la de control.
    Las alimentaciones de los motores paso a paso, en una primera aproximación, estarían en el rango de 32 a 48V y 6A (pueden ser de algo menos de corriente, si aceptan periodos transitorios de varias décimas de segundo a esta corrietne
    Hasta que no se avancen los ensayos no te puedo indicar nada más.
    Creo que se están apuntando más gente para crear diseños paralelos al mio usando Raspberry Pi,revisa el foro por si alguien ha abierto algún hilo.
    Desconozco si hay algún programador que quiera realizar el control usando PLCs industriales.
    De todas formas, gracias.
    Y cuando disponga de más información vuelvo a contactar contigo.
Accede o Regístrate para comentar.