Real time

[Apolión]

Hola:

Tengo el siguiente problema:

Hice un pxi target (el chasis es el 1042 y el controlador es el 8186, con 256 MB en RAM) con la utilería de usb para crear un target como PC, además le agregué

un scxi 1000 (con los siguientes bloques 1520,1540 y 1124 (no recuerdo muy bien es de salida de voltajes)) por medio de la tarjeta PXI-6259, hasta aquí todo bien, es decir; lo puedo administrar con el MAX.

Realice una aplicación en RT para hacer un control de un actuador, para lo cual necesito generar una señal senoidal desde 0.5 hasta 20 HZ como la referencia a seguir, esto con datos (un arreglo) ya que se requiere un seguimiento punto a punto de la señal. Para frecuencias de hasta 5 Hz todo funciona bien, el problema es cuando la frecuencia aumenta ya que la señal generada se reduce a 3 Hz. Conecté un monitor al target y cuando la frecuencia es de 5 Hz los indicadores muestran que el proceso del CPU esta cerca del 100%, y al aumentar la frecuencia el indicador baja a cerda del 60%.   

Se me olvido mencionar que la aplicación de control está en un While time loop de microsegundos, por como quiero generar la señal los ciclos con los que tengo el problema es a partir de 555 hasta 139 microsegundos de delay entre ciclo y ciclo.

¿Mi problema se debe a cómo hice target el pxi? aunque cabe mencionar aquí, que lo mismo pasa con una PC target que cree, las características de la PC son: procesador de 800 MHz, 400MB de RAM y 40GB de disco duro, y la tarjeta que hace la comunicación es una PCI-6250.

¿Le falta memoria al PXI? ¿Es la tarjeta que comunica al SCXI?

Saludos y Gracias.

Apolión

[BeCeGa]

Hola Apolion el problema no es de el target sino del programa.

Cuando estas trabajando en LabVIEW en tiempo real, LabVIEW administa las treads dependiendo de la prioridad:

Si tienes 2 loops con la misma prioridad LabVIEW distribuye el tiempo del procesador en forma equitativa entre los dos. Ahora como hace esto no puedes calcular en forma deterministica cuanto tiempo van a tardar. Por ejemplo supongamos que por ciclo de reloj tu programa puede realizar 6 operaciones. Si tienes 2 loops y cada uno requiere 4,  para poder terminar los dos se va a tardar 2 ciclos de reloj.

Ahora si cambias la prioridad, y uno tiene mayor prioridad que el otro, LabVIEW primero le va a dar todo el tiempo que requiere el de mayor prioridad y lo que sobre se lo dará a los demás treads. Con el mismo ejemplo anterior, si uno de los loops le doy mayor prioridad lo que realiza es de las 6 operaciones siempre le va a dar 4 a el ciclo principal y las dos que sobran se las va a dar al de menor prioridad. Con esto en 2 ciclos de reloj, la de alta prioridad se va a ejecutar 2 veces mientras que la de menor prioridad solo una. Pero con esto garantizas que tu loop principal siempre va a terminar en el tiempo que tienes.

Hay un fenómeno adicional que puede producir esto que se conoce como starvation. Por ejemplo si mi loop principal requiere 6 operaciones, no me van a quedar operaciones libres para el otro loop por lo cual nunca se va a ejecutar.

Si en una computadora de escritorio corres un ciclo while sin tiempo vas a ver como se satura el procesador, (se va al 100%) sin embargo si tu le agregas un wait por ejemplo de 1ms, vas a ver como ya no se satura. Esto se debe a que entre ciclos estas dando tiempo de descanso al procesador. La timed loop es similar a un Wait Until Next ms este no garantiza el tiempo de espera sino que forzar el tiempo a el de tu loop. Ahora el problema que estas teniendo es que por ejemplo si por la frecuencia que le diste a tu programa por decir 1hz el tiempo de cada ciclo es de 1ms, pero si las operaciones que realizas dentro toman más de 1ms, tu ciclo se retrasa y no deja espacio libre en el procesador por eso ves que se va al 100%

Aquí para corregirlo si tienes más de 1 ciclo while a el que no está encargado de la generación bájale la prioridad o súbela al que está encargado de la generación. Si solo tienes un ciclo while, saca de este todo lo que no es de alta prioridad por ejemplo escribir al archivo o comunicarse en red a tu computadora y dale menor prioridad a este segundo ciclo. En las timed loops mientras más alto sea el número de prioridad mayor es la prioridad que tienen.

Saludos

[Apolión]

Gracias Benjamín:

Voy a considerar tus comentarios y después escribo para ver como voy.

Saludos y de nuevo gracias.

Apolión

[Apolión]

Hola Benjamín:

Ya solucione mi problema para generar mi señal y no tener problemas con el procesador. Muchas gracias por la Ayuda.

Ahora tengo otro problema, en mi mensaje de arriba te mencioné que estoy trabajando con un PXI y un SCXI, el cual, tiene una tarjeta de strain gage, de LVDT y una de salida de voltaje. En mi aplicación necesito tomar lectura de un sensor diferencial de presión y un LVDT y aplicar un control PID y salida de este mandarla por la tarjeta de voltajes, al programar la adquisición de datos de sensor de presión y del LVDT me marca un error de recurso ocupado, y alquilar la lectura del strain gage se quita el error, con la de voltaje no tengo problemas. Mi pregunta es que si puedo ocupar las dos lecturas en una misma aplicación.

Saludos.

[Coamín]

Estimado Apolión

Lo que entiendo de tu problema es que estás intentando de realizar 2 lecturas de canales (ya sean de presión, voltaje, corriente) y al realizar esto te arroja un error de recurso compartido. En primero quisiera preguntarte si estás utilizando los Vis de bajo nivel de DAQ o estás ocupando el asistente DAQ. Por otro lado, si estás utilizando dos asistentes en paralelo accediendo a la misma tarjeta vas a tener problemas, solo dentro del mismo asistente deberás agregar un canal adicional en la tarea. Esto lo puedes hacer solo dando clic sobre el símbolo de + en el configurador del asistente DAQ.

Si tienes algún problema te pido me lo hagas saber y con todo gusto te ayudaré.

Saludos

Coamín Cruz

AE México