continuous output problems

[monty]

We are using a PCI-MIO-16E-1 in a synchronized generation/aquisition application, using Labview on a double processor, 512MB, W2K machine. The ouput Update clock is routed to RTSI1 with RouteSignal.vi; AIClockConfig.vi uses this pin as the scan clock source. This setup is similar to the Labview examples which uses PFI5. When we used PFI5 we saw spikes on this signal.

One of the two output channels (a square wave with a certain duty cycle) is connected to PFI0/Trig1; AITriggerConfig uses PFI0 as the source of an analog trigger. This signal is also connected to the PFI3 line; AITriggerConfig uses PFI3 as the source for a digital scan clock gate to aquire data only when the square wave is 'high'. (no spikes are visible now.)

The VI is sup
posed to run continuously, that is, the output is started with AOStart, number of iterations=0. This implies a continuous aquisition based on the signal connections described above. The problem we encounter is that the generation occasionally stops, which in our case means aquisition stops as well, without generating errors. This stopping does not neccesarily coincide with high processor activity or high memory consumption. Furthermore, this scheme worked OK on another (slightly faster) computer with the same card.

We have tried increasing the buffer size of the output to about 10 periods of the square wave, without result. Debugging shows that the input buffer is emptied fast enough to keep up with the scanning. The current 'workaround' we implemented is to give another AO control on the timeout of the DAQ occurrence we use. This re-starts the generation (and aquisition) which usually keeps running after this.

My question is what can cause the halt in the continuous generation
?

Regards,

Dirk Faber

[Filipe A.]

Dirk;

In fact, there is an issue in between the driver layer (NI-PAL) that talks with NI-DAQ and dual processor machines. This issue is being addressed by our R&D department, and the new version of the driver (NI-PAL 1.6.1) will contain the fix for that. At this time we also can't give you an exact date for the release of that driver, but I advise you to keep visiting www.ni.com, to double check if the new version of NI-PAL was released.
That problem shows even if you disable one of the processors on the BIOS.
For now, the way to guarantee the perfect operation of the DAQ task is to work on single processor machines, or to keep using the workaround that you guys managed to find for your particular instance.
I'm sorry for the inconvenience that might cause to
you.

Regards
Filipe A.
Applications Engineer
National Instruments

[monty]

The above mentioned problem was solved.

Some test VI's, without the complicated timing signal routing, showed that the problem was indeed with the continuous generation. When using (for example) the "Continuous Sine Wave" example the generation would stop as soon as memory or processor activity from another VI was introduced. Error 10843 was returned in most cases, indicating transfer problems to the device memory. One solution was to use FIFO memory for the buffer, however, our waveforms are larger then the FIFO size, so this would not be a good option. By using interupts in stead of DMA for the generation the output ran flawless. This was also true for the measurement program described above.

At this point, I'm not sure if this behaviour is related to the NI
-PAL issues described by Filipe, but I'm sure he can answer that one.

Dirk.