12-01-2011 11:01 AM
Hi Oli,
Yes, it does. Is there any limitation regarding the array size or update frequency?
What examples use that?
Regards
12-01-2011 11:12 AM
Hi Luiz,
The only limitation on array size would be based on your RAM, but I doubt that you would get anywhere near that. There is also a limit to the size of the buffers you can have on a DO, but you shouldn't reach that either. If you do, you can have two different datasets by splitting the array. We can deal with that later if you find that you have issues.
It would be similar to the 'Cont Write Dig Port-Int Clk.vi' and 'Cont Write Dig Port-Ext Clk(which can be found under Hardware Input and Output > DAQmx > Digital Generation). Here the 'Pattern' array is written and it can be updated as the program is running to output the new data.
We would instead fill the data and the program would automatically work through the columns of the array. On each clock pulse, the output would move to the next column in the array and each row would be output to a DIO port.
'Correlated Dig Write With Counter.vi' and 'Write Dig Port.vi' might also be worth looking at.
Regards,
12-02-2011 04:14 AM
Hi Oli,
I tried to run both 'Cont Write Dig Port-Ext Clk.vi' and 'Correlated Dig Write With Counter.vi'.
With the first I can only use the 100kHzTimebase as clock source. When trying 20MHzTimebase it outputs "Onboard device memory underflow" regardless the pattern array size.
With the second I can get up to 5MHz and after that I get the "Onboard device memory underflow" message again. Therefore I would need a readout interval of 40ms. I can live with that, but I would like to have a faster clock.
One idea I can try is to use the external waveform generator (I have a 100MHz TTI TGA12104) to generate faster csclk clocks triggered by the NI-6259.
I will give it a go a get back to you asap.
Regards
12-02-2011 04:32 AM
Hi Luiz,
The problem "Onboard device memory underflow" is caused by system and/or bandwidth limitations. The driver can't write data to the device fast enough to keep up with the device output rate, so the buffer is emptied and the device throws an error. You can reduce the sample rate or also try reducing the number of programs running on your computer. USB shares resources across the southbridge (depending on your motherboard architecture), so if you can do the following, it might help:
Unplug any USB devices that you don't need when your code is running, that would also help. (external HDDs, printers etc.)
If you have a fancy mouse or keyboard with a high poll/report rate (like a gaming grade laser mouse for example), replace it with a normal/low spec one or turn the report rate down.
Make sure that you plug your 6259 into a different USB port to your keyboard and mouse (a port is usually a pair of USB connections)
Make sure that the 6259 is connected directly to your computer (i.e not a hub) and to a port on the back rather than the front (front headers can have lower transfer rates).
Try a shorter USB cable.
Check you have the latest drivers for your USB.
Hopefully that might get you a little bit more speed out of your USB headers.
Let me know how you get on with the external clock too.
Regards,