Labview y Puerto paralelo

un monocromador jaja
bueno yo hise esa interfaz sin saber lo que era

un monocromador es una maquina que descompone la luz en colores como 1 prisma
pero este aparato te da la longitud de onda deseada

ejemplo quiero 452.23 nm en luz "que es azul"
¿para que es?
bueno es para hacer incidir luz especifica en un material

¿en que lo usan?
para hacer diodos semiconductores con silicio

¿como funciona?

con un vulgar motor a pasos

¿que hace ese programa que mande?
mueve un motor a paso

facil

labview no es nada dificil de usar , ami no me gusta prefiero el visual C
pero cada quien se acomoda con lo que puede

saludos
 
Interesante explicación sobre el monocromador.
Por otro lado, parece que he llegado a un límite de velocidad de labview. Resulta que he podido enviar por el primer pin del puerto paralelo una secuencia cíclica de unos y ceros, variando la duración de los pulsos elementales. Como si fuera un puerto serie. Pero cuando disminuyo el tiempo de duración por debajo de los 500 microsegundos, el tren de pulsos de desbarata. Lo he probado con un lazo FOR con un CASE, una secuencia flat, una secuancia stacked... pero siempre me da el mismo resultado. Nada por debajo de los 500 microsegundos como duración del impulso elemental.
Pasé a probar el puerto serie, pero parece que no tengo bien instalado el labview, porque me da un error y me dice que debe ser porque faltan los driver para trabajar con esos VI del puerto serie...

¿Qué creen?. ¿Qué estoy haciendo mal?
 
Ese problema tambien lo tuve cuando quise trabajar con el puerto serie en labview, para que trabaje el puerto serie tuve que buscar y descargar el archivo que faltaba, ahora no recuerdo el nombre del archivo, pero si era algo grande como para subirlo, asi que no te queda mas que buscarlo por la red.

Por otro lado dudo mucho que con el puerto serie puedas solucionar el problema, ten en cuenta que labview sigue sometido sistema operativo por lo cual labview trabaja solo cuando el sistema operativo "le da tiempito".
Me párese mas pertinente que labview haga de control y que un microcontrolador sea el que genere la secuencia de unos y ceros para el sistema con el que se quiere interfazar.
 
bueno dejen que cuente mi experiencia.

el labview no tiene la plasticidad del C++ y ami igualmente me dio dolores de cabeza por que en C la salida del puerto paralelo era exactamente de 1ms y en el labview por mas optimizado el código me salia alrededor de 3.4 mili segundos "según era 1 mili segundo" eso lo comprobé haciendo muchos barridos.

y como dices la secuencia aveces se llegaba a destripar si lo hacia muy rápido.

no se si fracase o me di por vencido pero termine usando C++, por lo exacto que era , bueno eso fue lo que hice .

pero si a ti se te facilita el Labview es mas bien cuestion de optimizar el codigo.

en el icono de foco puedes ver paso a paso como se mueve el codigo en labview y ver que es lo que esta fallando, hacer muchas funciones dentro de un ciclo hace que truene el programa y se desbarate.
 
Gracias por responder, Saint. Estoy de acuerdo contigo en que tendré que poner un micro como interfase. Es que estaba tratando de evitar eso para que fuera más sencillo, pero parece que aquí la solución no es el camino más sencillo.

Estaba viendo también que al usar el puerto paralelo como si fuera un serie, usando un solo pin para enviar el tren de pulsos, estos no salen con la duración que le indico, sino con mucha más.

Me tengo que complicar con el micro, como me dices. Por lo tanto, tendré que seguirles pidiendo ayuda para avanzar.

Gracias nuevamente a todos.



Trilo, para probar, lo hice lo más sencillo posible. Un lazo stacked donde el primer cuadro envía un 1 y el otro cuadro envía un cero. Puse el reloj pulsera (porque mide en miliseg) dentro del cuadro y el VI "out port" también dentro. Saqué el control del tiempo fuera del lazo para que sirviera para ambos cuadros y empecé a bajar el tiempo de espera. después de 0,5 ya se destruye el tren de pulsos.

Usé el stacked, el lazo for, el case, Flat... me da el mismo resultado.
 
Última edición:
cuando dices que se destruye el tren de pulsos, te refieres a que el programa tarda mas de 0.5 ms en hacer que el puerto cambie de estado (0->1) o que la señal que se ve en el osciloscopio en vez de aparecer cuadrada aparece deformada pero conserva el semi-periodo de 0.5ms.
si es el primer caso, es problema del programa.
Si es el segundo, el problema el harware del puerto paralelo.

que tal si subes una imagen de la forma de onda que tienes en el osciloscopio, quizá se pueda "matufiar" algo.
 
Ambas cosas suceden. Mientras estoy por encima de 0,5, se ve perfectamente el pulso y la pausa, pero duran más de o,5 cada uno (no cambia de estado en 0,5 ms). Cuando bajo a 0,49 ms, lo que se ve en el osciloscopio es un reguero de puntos que no tienen una secuencia adecuada. Ni se parece a lo que veo en 0,5. Este reguero parece que es que le pido demasiado a ese pin del paralelo. Aunque lo puse en modo ECP, que según la literatura, puede accionar a más de 1 Mhz de trasnferencia. Claro, esta velocidad seguro que es cuando envía en paralelo el byte.
 
bien, pues aparentemente no queda de otra mas que usar un microcontrolador.
debido a que el micro controlador es capas de solucionar el problema, habría que pensar si todavía es necesario el uso de la PC tomando en cuenta que en el micro controlador de puede implementar un teclado y un LCD para el control visualización de alguna información, bueno eso lo decides tú.

empecemos por el micro controlador, ¿que micro controlador conoces, manejas, puedes conseguir?.
que compilador o ensamblador tienes para el micro controlador.

esto asumiendo que tienes, puedes conseguir el grabador para el micro controlador.
 
Como microprocesadores tengo el AT89C51, encapsulado cuadrado, el AT 89C52, encapsulado rectangular y hasta un D8085AH, recuperado de placas ya viejitas.

El asunto más grave es que nunca he tenido que programar micros, porque siempre me dediqué a baja integración y circuitería analógica. Pero bueno, esto es un nuevo reto, que siempre es interesante para mí. Los viejos necesitamos siempre tener algo interesante que hacer al levantarnos en la mañana, porque si no, caemos en estado depresivo. jejeje...
 
... Casi asegure que responderías que contabas con un pic o avr, pero lo del AT 89c51/AT89c52 por fortuna no me sorprende "aunque hacer raaaaaaato que no lo programo", con el 8085 ni nos metemos pues a este microprocesador aparte de programarlo hay que hacerle el mapeo de memoria, aumentarle periféricos, memorias, etc.
Preguntas.
¿Cuentas con el grabador para este micro controlador (AT89C51/52)?
¿Programaste algunas ves en asm o en C?
Luego veremos el mejor modo de solucionar el problema.
 
No tengo el programador, pero puedo conseguirlo. Si hago algunas gestiones, puedo conseguir un pic y que me lo programen, pero eso es más engorroso. No he programado micros, pero sí conozco gente que lo han hecho y puedo contar con ellos.

Una pregunta: ¿Y si... utilizo un multiplexor en vez de un microprocesador?. Todavía no tengo idea de cómo será el diseño. Lo que controlaría mediante la PC es los relojes del multiplexor para dar la salida de cada canal que me convenga para conformar el byte que necesito en cada momento.
Lo que he querido hacer con LABView es el instrumento de control del funcionamiento del bloque, para después de reparado saber si hace todas las funciones para lo que está previsto. También, cuando lo traen al taller, hacerle una revisión y conocer cuál es el defecto en su funcionamiento. Todo esto con el bloque cerrado, sin abrirlo.
 
Un multilexor no creo que sea buena solucion, un MUX, entrega "señal" en una sola de sus salidas en un instante d tiempo, para entegar mas de una salida en un mismo instane te de tiempo aparte del mux se nesesiatria un latch, pero sigue siendo poco practico para el caso ya que el que controle al mux y al latch tendria que tener una frecuncia de trabajo mayor "para este caso, los pulsos de contros tendrian que ser nemores de 0.5ms", pero como tu puerto paralelo no responde correctamente a esos tiempos entonces no se podria.
te aseguro que con un micro controlador seria mas facil, por ejemplo:

labview tendria el interface Humano maquina (botones, swtche, leds,etc), mediante puerto serie labview le mada ordenes al micro controlador para que este haga una secuencia u ortra, "dentro" del microcontrolador estarian las secuencias y las generaria continuamente hasta que le llege al orden de cambiarlas, detenerse , etc.

con respecto al AT 89C52/51 es suficiente pero no existe mucha documentacion, tutoriales, etc., de modo que si mas adelante quieres profundisar los conocimeintos sobre progaracion de este micro controlador sera dificil, mientras que con los PICs y AVR tienes mas prestaciones y un mundo de tutoriales, ejemplos, grabadores,etc., por lo cual te recomiendo ahora o mas adelante "le metas mano a PICs o AVR".
Bien. ahora decide si trabajaras con AT89c51/52 o PIC, "pues este tema ya lleva tiempito y hay que sanjarlo de una vez".
 
Muy interesante, amigo Saint. Te agradezco el tiempo que me has dedicado. A tí y a los demás especialistas que han participado. Valoraré con qué micro trabajaré, según tus recomendaciones.

Gracias
 
Atrás
Arriba