Synchronous 4xAI, 3xAO over RTSI

[MK_MTEngineer]

Hello!

My task is to control a hardware with 3 AO channels an read back produced data at 4 (minimal 1) AI channel simultaniously. I´ve got two PCI-cards: PCI NI 6711 for one of the AO channels and a PCI NI 6110 for the rest. Both are connected over RTSI. I trigger the output with the start-trigger of the input task and the samplerate is the same. When i use my written VI with a predefined amount of samples and readout the written and the read samples they are not equal (the readout is to small!). The hardware input buffer of the PCI NI 6110 is only 8192 samples. I need to readout 262144 (512x512) samples per second. I suggest i´m in trouble with the readout speed an the buffer size?! The frequencies for the output signals should be 256 Hz, 2 Hz and 1Hz (for the on on the NI 6711). Is there a way to manage this? If there is only the possibility to use one input channel under this conditions its also ok..but it must be possible because another programm we use uses the SAME hardware. Ok so far i hope you can help me... if you need more information of my programmed VI´s please tell me.

So far thanks,

Michael

[SFK]

Hello Michael,

your code is a bit complex, but it seems to me that there is no timing declared for the Z.piezo output task. You might want to check on that first...

Secondly, the onboard FIFO buffer of the NI-6110 is only used for buffering the DMA transfer to your computer's RAM, where a larger buffer will be used to buffer the measured values until they are requested by and copied to the application (here: LabVIEW). So buffer size itself should not be an issue with your application. Just configure the AI task to 262144 finite samples and you should be fine.

I do see some other problems:

a) you cannot acquire with exactly 262144 S/s on the PCI-6110 without an external clock signal generator. The closest internal sample frequency that you can set is 263157.9 S/s (= 20MHz base clock / 76). As this is a bit faster than the frequency that you expected, input and output signals will not be coherent, if your output is really clocked at 1 S/s, 2 S/s or 256 S/s. The easiest solution for this issue would be to share the sample clock between AI and AO, which would result in an AO sample rate of e.g. 513.98 S/s instead of 512 S/s.

b) reading your approx. 260 kS/s in blocks of 512 samples will certainly cause some CPU load, as the loop will have to iterate in less than 2ms. With file I/O in this loop, I cannot guarantee you that this will work. A possible solution might be to use a task configured for finite samples and a FOR loop to read these 262144 samples into a pre-initialized array (replacing its values block for block as you iterate through the loop) and to save them to disk afterwards. 260k samples equal 2 megabytes of RAM for each ai channel (when using an array of DBL), which is quite small compared to today's computers memory sizes.

My assumption is that you are losing samples (which would also cause an error code -200279) because your while loop iterates to slow. With the implementation mentioned above, you should be able to solve this issue.

Best regards,

Sebastian

[MK_MTEngineer]

Thanks Sebastian for your reply!

Yes you´re right! How could i forget about the clock of the hardware - really good point! 😉

Finite samples sounds interesting, but only the "scanpattern" has a defined amount of samples. It should be repeatable until the user stops with a button (more than one period of the scanpattern). Therefore it seems not to be possible to use finite samples, isn´t it?

Store the data in an array is also a essential idea, but then i have to write data to the harddisk continously in a parallel loop to the acquisition loop (with a queue)?! (I tried this before only after the user stops the acquisition and therefore i got problems with the memory).

Until now, i didn´t lost any sample - the error -200279 has not occured. But i have another problem: If i start my acquisition a second time, i get the error -200288. So it says something about that i want wo write data after the last sample?! But i want to restart on the first index... the offset property does not work in the used samplemode...Any suggestions what the problem could be? Can you help me a second time? (for the first time --> 1x kudos 🙂 )

Best regards,

Michael

[MK_MTEngineer]

Hello EVERYBODY!

OK ... once more I describe what I want to do....its complex, but is it that difficult??? (I invested really a LOT of time in this and now iam at a point where I really want to throw my VI´s all away [+Labview]).

First of all there are different scan modes the user can choose... this means there are three different waveforms for one scan mode, which have to control my scan-hardware (3x AO - two on the PCI-6110 an one at the PCI-6711; synchronized over RTSI-connection).

Starting the scan (= acquisition) should be done with a button, after the user has chosen the scan mode ( = waveforms and also the samplerate should be changeable).

At the same time there are 4 AI´s on the PCI-6110 which should read data synchronous to the waveforms with the dt rate of the waveforms and stored parallel on the hard disk (or after one scan period).

One scan-period is determined by the waveforms, which should have the same amount of samples.

The scan periods should be continuous until the user pushes a button (or an error occurs), for example the scan stops after 50 periods.

The samplerate should be 200.000 S/s.

Well and thats it!

Please, please help me! I´ve my back to the wall!!!

Best regards,

Michael

[MK_MTEngineer]

... is it possible to start a waveform-output task, run the task, stop the task, modify waveforms (and also their length) and then restart it without completely rebuild the task or write-buffer problems?

Would be really helpful...and one step away from the abyss... 😞

[MK_MTEngineer · Accepted solution]

So... there is no expert here i finally made it myself... if someone cares about the solution for 1xAI and 1xAO there it is ... the rest is really easy ... so thank you for your help!

Have a nice day!

[MK_MTEngineer]

...A Better version of LAST_CHANCE.vi - its cool for testing...enjoy!