Autor Tema: Tarjeta de adquisición de datos  (Leído 12757 veces)

Haran

  • Visitante
Re:Tarjeta de adquisición de datos
« Respuesta #15 en: 28 Enero 2014, 20:51 »
Gracias y siento explicarme tan mal...
Los encoders que tengo, tanto los de 3600 como los de 36000, son incrementales. Y si que son suficiente para la aplicación que necesito.
Aunque finalmente usare los heidenhain de 36000, para probar empezaré con los fagor de 3600 ya que son nuevos y sé que funcionan.

Desconectado tio_gil

  • Global Moderator
  • Oficial 1ª
  • ***
  • Join Date: Sep 2009
  • Mensajes: 3099
  • Ubicación: Madrid - España
Re:Tarjeta de adquisición de datos
« Respuesta #16 en: 28 Enero 2014, 21:15 »
tienes la info de ellos?

En el lado del PC, que programa vas a usar?
Torno Optimun D240x500 modificado, Fresa BF20L Vario modificada, mucha otra herramienta... y pocas ganas de trabajar !!

Haran

  • Visitante
Re:Tarjeta de adquisición de datos
« Respuesta #17 en: 28 Enero 2014, 21:45 »
Hoy no tengo más info. Aunque si me dices que tipo de información sería más fácil si puedo obtenerla o no.
No tengo ni idea del software... lo siento. No sé ni por donde empezar en ese sentido...


Desconectado fleming

  • Aprendiz
  • *
  • Join Date: Dic 2009
  • Mensajes: 737
  • Ubicación: BCN-A Coruña (cuando puedo)
Re:Tarjeta de adquisición de datos
« Respuesta #19 en: 29 Enero 2014, 17:35 »

En cuanto a la tarjeta de adquisición... como buen gallego... depende.
Puedes irte a algo cañero como una NiDAQ (y tampoco es de lo más, seguro que el tío_Gil nos puede vender algo high end ejejejjee)
O puedes irte a algo más de andar por casa como el arduino
También puedes ir a soluciones intermedias, como el puerto paralélo o un datalogger.... hay infinidad de soluciones, tantas como mecanismos para contar tiempos (con la suficiente resolución) entre dos eventos...estas soluciones "solo" están limitadas por:
  • Tus conocimientos y facilidad de acceso a la tecnología
  • Presupuesto
  • Velocidad de adquisición
Leyéndote, el punto número 1 no es trivial o fácil de resolver... tendrás que buscarte a alguien de la zona que te eche una mano y se involucre, porque aunque desde aquí te podamos orientar sobre que parece más adecuado, quien tiene que tomar la decisión de que sistema usar, es que vaya a programar la aplicación (ya sea en la plataforma o en el ordenador)


Para tu aplicación me iría a un encoder de alta resolción, incremental y solo leyendo un canal (la dirección será siempre la misma y controlado por tí), registraría también el indice para llevar cuentas de la revoluciones y como posible triguer de la adquisición en tiempo real para un posterior post proceso.


PAra el sistema de adquisción, habría que echar unos números una vez tengas encoder, o bien, echar unos números de las velocidades y resoluciones que deseas para buscar el encoder y el sistema de adquisición.

Lo que quiero (intentar al menos) es medir la linealidad del giro en reductores. Es decir en un reductor ejemplo de 10:1 de reducción con dos encoder uno a la entrada del reductor y otro a la salida ser capaz de ver en una gráfica como se desarrolla el movimiento de salida. El motor del eje de entrada dará en ese caso 10 vueltas y el de salida dará 1, pero cuando la entrada haya dado 5 vueltas el eje de salida seguramente no estará en 180º. Es debido a los saltos de los engranajes, tanto de anchuras de diente, como de concentricidad de la zona de contacto con el eje de giro. Así lo que busco es el gráfico de cómo se comporta el eje de salida en función del giro de entrada.


Perdona pero leyendo estas explicaciones y el pdf de la máquina que expones hay cosas que no me cuadran.
La relación de transmisión es algo que no cambia en una revolución del engranaje, si al cabo de la primera vuelta el eje de salida se encuentra en 180,001 grados, al cabo de 100 vueltas el eje de salida se encontrará en 180,001. De lo contraría existiría deslizamiento (cosa poco probable... habiendo dientes engranados de por medio). En una transmisión por engranajes se me antoja muy muy complicado que salten dientes...
Disculpa si me meto en terrenos que desconozco, pero leyendo por encima lo que hace la máquina del pdf es medir al variaciones puntales de relación de transmisión debidas al cambio del punto de contacto de los engranajes (como sabrás el perfil de envolvente de los engranajes es al que define un punto de contacto entre dos engranajes se mantenga cte en el espacio y en el tiempo, permitiendo tener una relación de transmisión constante en el tiempo... si el punto de contacto se mueve, a lo largo de una revolución, la relación de transmisión va variando... y eso no mola. El perfil de envolvente de los engranajes resuelven este problema), así como ovalidades, perfiles incorrectos incorrectos y desgastes asimétricos.


Cuanta más resolución tenga tu encoder mejor, porque tu rango de trabajo va a ser una sola revolución (si es que quieres hacer lo que describe la máquina).
La velocidad no parece muy crítica, pero si quieres estudiar los efectos en dinámico o en altas revoluciones )es decir, el efecto de la inercia) en vez de estático o bajas revoluciones.
Al final lo que vas a necesitar son velocidades angulares que saldrán de integrar tus posiciones angulares.


Saludos
« última modificación: 29 Enero 2014, 17:38 por fleming »

Haran

  • Visitante
Re:Tarjeta de adquisición de datos
« Respuesta #20 en: 29 Enero 2014, 18:27 »
Gracias fleming.
Vamos que plug and play no va a ser... Al menos barato...
Conocimientos cero... He montado la electrónica de una impresora 3d y ya me creo un experto programador y electrónico... (sólo había que acoplar una ramps encima de un arduino y meter el firmware...).
Respecto al tema de revoluciones estoy de acuerdo con tus argumentos ( excepto que a 100 revoluciones este en 180.001; estará en 0, creo...). Lo único que me interesa es una vuelta como tu bien dices ( del eje de salida).
Las revoluciones en general suelen ser muy bajas del orden de 100rpm en conductor.
El giro será para ambos lados, pero seré yo el que lo elija así que ese dato no lo necesito, efectivamente.
Una duda ¿ labview es compatible con los datos de arduino? Es software gratuito y para ir probando me podría servir...

Desconectado fleming

  • Aprendiz
  • *
  • Join Date: Dic 2009
  • Mensajes: 737
  • Ubicación: BCN-A Coruña (cuando puedo)
Re:Tarjeta de adquisición de datos
« Respuesta #21 en: 29 Enero 2014, 19:17 »
Hombre,
Plug and play... yo creo que muy poco... aunque sea LabView.
Sorry, LabView es de pago... y no es barato. Pero si que tiene la ventaja que es muy fácil de hacer cosas siguiendo los tutoriales, digamos que está pensado para electrónicos Ingenieros que no quieren programar (que al final aprenden a programar en LabView... pero ese es otro debate). Es sencillo, potente y hasta se puede integrar con Arduino... peeeeero, ten en cuenta que es un sistema de alto nivel (al igual que arduino), y a medida que subes en los niveles, pierdes control, pero sobre todo, pierdes velocidad... con un poco de "sentidiño" se les puede sacar algo de potencia...
Tienes como unos "cienes" de tutoriales...
Pero insisto, antes de elegir la plataforma, habría que echar unos numeritos para saber en que mundo está apliación... en el de los milisegundos, los microsegundos, los nanosegundos...?!?!?
-RPM máximas?
-Resolución del encoder o de la lectura?
A partir de ahí, te saldrá la frecuencia de tu sistema...


Saludos


PD: Pon algo sobre esas jollitas de 36000 ppr... que se me hace la boca agua   .baba .baba .baba

Desconectado tio_gil

  • Global Moderator
  • Oficial 1ª
  • ***
  • Join Date: Sep 2009
  • Mensajes: 3099
  • Ubicación: Madrid - España
Re:Tarjeta de adquisición de datos
« Respuesta #22 en: 29 Enero 2014, 19:30 »
Pues Fleming ha hecho una muy buena exposición.
Las placas de NI no son nada malas. Además suelen tener drivers para poderlas manejar desde otros porgramas. Y el soft qe puedes hacer resulta "bonito"
LabView es de NI... curioso ;)

Si no hay placas que te den entrada de encoder directa y/o con la suficiente resolución, te tocará hacer electrónica por medio. Lo más fácil: unos decoder de cuadratura de LSI/CSI  (en está página)que ya te lo dan hecho (al menos la decodificación, que HAY QUE HACERLA HARDWARE).

Y como dice fleming, LW no es gratis (la versión base "sólo" cuesta 950 eu -más impuestos- y no se que s epuede hacer con ella)


,encoder de
Torno Optimun D240x500 modificado, Fresa BF20L Vario modificada, mucha otra herramienta... y pocas ganas de trabajar !!

Desconectado fleming

  • Aprendiz
  • *
  • Join Date: Dic 2009
  • Mensajes: 737
  • Ubicación: BCN-A Coruña (cuando puedo)
Re:Tarjeta de adquisición de datos
« Respuesta #23 en: 29 Enero 2014, 20:30 »
Yo he hecho muchas integraciones con NiDaQ's de Ni, tanto en LabView como en otros entornos (delphi, C++, VB..)... y la verdad es que el herdware es brutal, no muy caro (para todo lo que hace), pero para mi gusto los de National Instruments la cagan un poco con los drivers.
Otra cosa FUNDAMENTAL (sin ánimo de gritar) es tener un muy buen programador con  background en electrónica y sobre todo en los drivers de NI... yo en algún proyecto he tenido auténticos problemas de rendimiento por no configurar/utilizar correctamente la tarjeta/DLL
National Instruments se ha caracterizado por tener unos productos de muy fácil integración... pero para mi gusto, de muy alto nivel.... cuando necesitas alto rendimiento y eficiencia... tienes que pasar por Hardware-software desarrollado a medida.... pero eso se dispara en dinero y sobre todo... en tiempo (que también es dinero...)
SAludos.

Haran

  • Visitante
Re:Tarjeta de adquisición de datos
« Respuesta #24 en: 29 Enero 2014, 22:36 »
Vaya esto se pone complicado... Gracias a los dos por el interes y la ayuda.
Respondo a fleming. RPM 100 maximas en el eje de entrada.  En la salida maximo 100 para relaciones de 1:1 (aunque generalmente rondará las 50rpm en la salida).
La resolución de los encoder que se ponen en este tipo de máquinas es de 36000 y según el fabricante de +/-1".

Los encoder que dije joyitas, no se sí lo son... son unos heidenhain Rod800 (igual para vosotros es algo normal, a mi me pareció incrible cuando leí la chapa). No encuentro documentación, pero mirando en catalogos de heidenhain parece que la serie 800 es parecida al menos en cuanto a caracteristicas. Pongo un enlace a un pdf de heidenhain... por cierto ahi unas tarjetas ik220 al final que serán viejas (a juzgar por los windows en los que funciona), pero que igual hay por ahí alguna...
http://bicep.caltech.edu/~yuki/servo/208_736-27.pdf

Desconectado fleming

  • Aprendiz
  • *
  • Join Date: Dic 2009
  • Mensajes: 737
  • Ubicación: BCN-A Coruña (cuando puedo)
Re:Tarjeta de adquisición de datos
« Respuesta #25 en: 30 Enero 2014, 00:16 »
#Madredelamorhermoso!!!
Dices que tienes por ahí tirados unos Heidenhain RD 800?!?!?
De joyitas nada.... joyas en toda regla!!!
Hombre, no sé hasta que punto tienes ganas de hacerte la máquina esa... pero si consigues vender los encoders... te puedes pegar unas buenas vacaciones.
Manejar esos pulsos a esas velocidades... lo más adecuado sería intentar poner a funcionar las IK220 (que llevan el mítico integrado de PLX de pasarela PCI)
El problema es que ya no quedan muchos ordenadores con PCI, y seguramente las DLL's será para Windows XP... pero olvídate del Plug and Play.


Para 100rpm y 36000 pulsos, a mi me sale una frecuencia de 60Khz... que tampoco es tan exagerada, son 166 milisegundos. Para un arduino lo veo un poco justo, tendrías que optimizarlo mucho... casi ni lo intentaría, teniendo en cuenta que tienes que apreciar desviaciones geométricas casi imperceptibles, tu base de tiempos tendrá que ser muy muy buena (basada en un VCO), podrías intentar algo con una NiDAQ (Intentando pensar en Plug and play) o desarrollarte algo con un FPGA's o DSP's (en el extremo opuesto del plug&play), pero lo suyo sería utilizar las IK220... eso es lo más plug and play que tienes en cuanto al hardware.... peeeero, te queda el software, que no es tontería...


Saludos.


Desconectado tio_gil

  • Global Moderator
  • Oficial 1ª
  • ***
  • Join Date: Sep 2009
  • Mensajes: 3099
  • Ubicación: Madrid - España
Re:Tarjeta de adquisición de datos
« Respuesta #26 en: 30 Enero 2014, 11:05 »
fleming, te has ido en los ceros. Son 16.6 microsegundos. Por eso decía yo de poner directamente un decoder. (a no ser que lo que tengas, coo bien dices, una fpga, un micro con entrada de encoders, etc,etc)

Respecto a lso ordenadores, lo único que se me ocurre es que mires en placas de PC industriales. Estas suelen traer todavía estos tipos de buses, incluso puertos paraleo y serie. Tampoco valen lo que vale una placa "normalita" de pc.

Al final, como dice el amigo Fleming, pasta por todos los lados.
Torno Optimun D240x500 modificado, Fresa BF20L Vario modificada, mucha otra herramienta... y pocas ganas de trabajar !!

Haran

  • Visitante
Re:Tarjeta de adquisición de datos
« Respuesta #27 en: 30 Enero 2014, 11:30 »
Gracias a los dos.
Creo que de primeras tengo que empezar por algo manejable. Os parece descabellado que me meta con los dos fagor 3600 y arduino a ver si soy capaz de aprender de que va todo esto?
Si consigo algo con ellos el resto ya sería con un cheque en blanco...
« última modificación: 30 Enero 2014, 11:57 por Haran »

Desconectado tio_gil

  • Global Moderator
  • Oficial 1ª
  • ***
  • Join Date: Sep 2009
  • Mensajes: 3099
  • Ubicación: Madrid - España
Re:Tarjeta de adquisición de datos
« Respuesta #28 en: 30 Enero 2014, 16:42 »
Todo es empezar... y tomárselo con calma
Torno Optimun D240x500 modificado, Fresa BF20L Vario modificada, mucha otra herramienta... y pocas ganas de trabajar !!

Desconectado fleming

  • Aprendiz
  • *
  • Join Date: Dic 2009
  • Mensajes: 737
  • Ubicación: BCN-A Coruña (cuando puedo)
Re:Tarjeta de adquisición de datos
« Respuesta #29 en: 30 Enero 2014, 17:20 »
Jur jur jur... Cierto, se me han ido los ceros... Es lo que tiene ser de letras ;)
Harán, bajar de 36 a 3,6 es solo un orden de magnitud... Sigo pensando que el cristal de cuarzo/resonador del arduino no tiene la suficiente estabilidad para apreciar las variaciones... Oero como las cosas no se resuelven con apreciaciones, lo mejor es hacer un estudio de propagación de errores, para saber si el error de tu medida está lejos de tu orden de magnitud.
No quiero desaninarte con esto, empieza con el arduino y con el de 3,6k ppr, lo bueno es que aprenderás y entenderás donde estan los problemas a la hora de plantearte un desarrollo mas serio.
Ánimo.... Y como digo siempre, no dejes de contarnoslo!!