data overwritten

[edolch]

Hi,

I'm configuring a task in LabVIEW and a PCI 6251 to improve the presicion of  positioning  of a movement stage of two axes. I'm reading the position of the first axis from a laser encoder with a counter input (quadrature A B, linear position) and when the error signal is less than certain value then I write an analog signal to control the axis 2 (configured as on demand generation). See attached figure 'loop'. 
I have configured the reading of the position as HW Timed a clock rate and sampling rate of 2 Hz (see figure 'axis 1'). The program work very well but if I increase the frequency of aquisition, then appear an "data overwritten" error in the position aquisition measurement at counter input. Is there another way of doing this task more rapid?, I have heard that frequencies of 1 kHz are the maximum rate for an application like mine, limited by the loops contained in the program.

Thanks in advance,

Eduardo

[Guillem_A]

Hi Eduardo

Thanks for contributing.

I've peeked up your block diagram and it feels like you are abusing of the DAQmx assitant, calling 3 assistants per iteration is very demanding. Furthermore I am not sure whether is appropriate to leave "DAQ Assitant 2" unwired because LabView cannot guarantee the execution order of that task.

Could you upload your VI? I would, like to execute it on my own machine.

Just a question, are DAQ Assistant 2 and axis 2 target pointing to the same resource?

I would also try to perform the task without the assistant using the DAQmx tools (You will find them in the Functions Palette>>Measurement I/O>>NI DAQmx). For example on the usage of the DAQmx API (tools) refer to LV examples (LabView Help>>Find Examples and open in the file broswer Hardware Input & Output>>DAQmx).

Hope you found it helpful.

Just let me know about your progress. In the following posts you can write in Spanish if you feel more confident.

[edolch]

Hola Guillem, gracias por tu ayuda, adjunto el fichero 'control de posición' . Con respecto al DAQ 2 lo uso solamente para medir la señal analógica generada para el movimiento del eje 2, uniendo la salida analógica por donde sale la señal con la entrada analógica correspondiente.
Había pensado que el problema podían ser los DAQmx y que sería mejor bajar a un nivel más bajo de programación, así que con tu respuesta ya me animo a hacerlo. Una pregunta, ¿Es posible ejecutar tareas de medición y generación sincronizadas con el mismo reloj y leyendo este reloj en el mismo punto, por ejemplo PFI0?
Con respecto al programa le he hecho algunas modificaciones con algunas sugerencias que he leído en el foro, se trata de medir de forma continua y procesar series de datos, adjunto el fichero por si lo queres ver ('control de posicion 2'), de esta forma el control se actualiza más rápido, pude llegar hasta 300 Hz que todavía es muy bajo.

[Guillem_A]

Hola Eduardo,

Estoy estudiando tus VIs para ver si conseguimos optimizarlos. De todas formas las "herramientas" de DAQmx de más bajo nivel son la mejor forma que conozco para conseguir sincronizaciones auténticas. Si la temporización es un aspecto crítico de la aplicación definitivamente deberías prescindir del asistente.

Te paso un enlace con un tutorial sobre sincronización de tareas con DAQmx. Cómo verás (Figure 2 de Timing and Synchronization features) primero se crean las dos tareas, luego se configura el reloj y se puede elegir una fuente cableando una constante o un control a la entrada "source" (que en tu caso podría ser el canal PFI0 o el reloj interno de la tarjeta de adquisición).

La mayor sincronización se consigue mediante un trigger que dispara el inicio de la adquisición de la tarea más crítica (Figure 7 de Timing and Synchronization features).  Si vas a empezar a utilizar el API de DAQmx sin asistentes te recomiendo que trabajes sobre el tutorial Timing and Synchronization features...:

http://zone.ni.com/devzone/cda/tut/p/id/4322

También deberías incluir todas las tareas de adquisición que vayas a sincronizar en un mismo bucle.  Y sobre todo, sobretodo cíñete al máximo al esquema de flujo de datos. Con lo de flujo de datos me refiero a que no debe haber ningún bloque que no éste conectado a uno precedente para asegurar que se ejecuta en el momento preciso (En última instancia siempre se pueden conectar entre sí los terminales "error out" y "error in"). Una vez reescrito el código no se deberían dar más errores de overwrite para las rates que me comentas.

Sé que es mucha información de golpe. En cualquier caso espero los comentarios de tu evolución.

Recibe un cordial saludo.

[edolch]

Hola Guillem, gracias por tu apoyo, me parece muy interesante esta información y pertinente para el trabajo que estoy desarrollando así que de seguro me será muy útil, comenzaré a estudiar el tema inmediatamente. Estamos en contacto y muchas gracias de nuevo,

Eduardo