Make DAQ code perform faster?

[Notay]

Hi - I have a DAQ code which I have uploaded as a image below. The basic idea of the code is to get angular displacment from a shaft encoder and a voltage signal simultaneously. I have gone for a queued data operation to improve speed and a tdms for rapid writing. Currently I am getting roughly 2/3 signal writes per shaft degree at around 1300rpm shaft speed.

I would prefer at least 6 readings per degree at that speed to improve the resolution. My shaft encoder is a 720 pulse per revolution encoder which is wired up as a angular displacement counter as shown in the code. The 720 counter will read at a resolution of around 0.125 degrees, and not 0.5 degrees (due to the nature of the way it is wired in MAX following this http://www.ni.com/gettingstarted/setuphardware/dataacquisition/quadratureencoders.htm)

Is there any other way I can improve the speed of the code and writing?

Many thanks for your help.

[mikeporter]

What does the note on the code mean where it says the program "hangs" when the stop button is pressed?

What needs to happen faster, the acquisition or writing to the file?

Why are you mucking around with the dynamic datatype? It's not really necessary and might be complicaing things.

For troubleshooting purpose, in the lower loop read and display the queue depth. (Use the Get Queue Status function)

Mike...

[Norbert_B]

It would have been better to attach the VI since somehow i cannot zoom the image and with the given resolution, it is hard to read.

But from what i am seeing, you are NOT synchronizing AI and CI by any means. There is a start trigger for AI, but it is not obviously connected to CI, but to PFI9 (what is connected there?)....

My guess is that AI should sample with the resolution of 0.125 degrees.

Given your encoder, you will not achieve this in a decend way because the encoder itself only supplies 0.5 degrees per 'channel' (i'm not sure if this is the correct term). The easy way to go would be to use the A channel for instance as external sample clock for AI. And here you go: perfect synchronization. but only with a resolution of 0.5 degrees.....

Another thing is that your CI is not buffered which is most probable the reason why you are not achieving a resolution of less than 1 degree right now.

hope this helps,

Norbert

[PaulieQ]

Hi,

Use for each data acquisition (encoder and analog) a different while loop. You could read the encoder continuously at a very high frequency but in your case you read one sample at a time (1 ms from LabView loop) and you also wait for the Analog Part (being both in the same loop). -- As far as I see your Encoder Counter and Analog Input are not synchronized!! Is this what you wanted to achieve? Be careful that the Counter works with a clock and Analog Input with a completely other clock!!

I manage to read position from a quadrature encoder with more the 2 MHz sample rate using a USB board (USB-bulk Transfer Mode). With your PXI using DMA (Transfer-Mode) I think you can reach even more.

Of course it hangs. Your second loop never stops. After the first iteration there occur no error that could stop the second loop!!!

Paul

PS: You have a Quadrature Encoder. That is why you have a resolution of  0.5dgr / 4 =  0.125dgr !!!

[Notay]

Hi -many thanks for the replies. I have taken some time to adjust my code and have now attached the code (using labview 8.6). Currently removed the writing to file code since I would like to get the sync operation correct first.

I have attempted to sync my DAQ loops and now used two separate loops for each DAQ operation. I am using the Z marker channel of the encoder (PFI9) to start trigger the AI and using the sample clock of the AI on the CI and with a combination of flat frames to help sync the loops. On testing it appears the loops do sync and start at the same time. Tried using the highlight execution and tend to get error of -200279 due to the slow execution. I have also made sure the sample rate is the same so that the loops run at the same frequency.

I have a few questions though:

1) Is this the correct way to sync the loops - are there any faults with the way I have done it?

2) How can I stop the bottom loop without using local variables?

3) If I a queue system as before to write all the data to a tdms file, would I need two separate queue systems (and hence have 2 separate data files) since I have two DAQ loops or is there a way to write all the data, using the queue system, to one file?

Many thanks for your help.

Notay

[PaulieQ]

Notay,

Now, it is not necessary anymore to use two loops :). I told you in my previous post to use two because I didn't know if you want the both read operation (AI and Encoder) synchronized. In your first post they were not synchronized so I told you to use two loops in order to achieve higher speed on the Read Encoder part.

If you synchronize them (like you did here), both will sample at the same speed so you can use only one loop.

Some remarks:

1. If you use "highlight execution" the loops will run very slow, the hardware buffer is not read (or read very slowly) so you'll get a buffer full error (is this the -200279) error?

2. You should read the Counter and Encoder in the same way: NSamples and set the value to 10 or 20 .. 200 -> With one read you get 10..20 or 200... samples. For both of them. Here you have to find a trade-off. If your sampling rate is low you should use a lower N for NSample (to avoid time-out from read block). If your sampling rate is high read 100, 200 ... samples at once. 

Take a look in the attachment. Hope everything is ok. I couldn't test it.

Paul

[Notay]

Hi Paul - thanks for your reply

I cannot open the vi - please can you convert it to labview 8.6.

Also please can you clarify your second point - for example if I have a rate of 1000hz and a number of sample per channel as 100 - does that mean that ever 0.001second I get 100 data points from one read?

[PaulieQ]

Here you go.

[PaulieQ]

"Also please can you clarify your second point - for example if I have a rate of 1000hz and a number of sample per channel as 100 - does that mean that ever 0.001second I get 100 data points from one read?"

No. If you have 1000Hz you get a sample every 1 ms. But, you can define how many samples you read at once. If Fs = 1kHz and N = 100 you will be able to read the 100 samples every 0.1 second.

For example if you are using a 1MHz clock to acquire data, and you read only one sample at a time (N=1) you could have some problems. The LabView loop has a 1ms delay. This means you will read a 1000 samples/sec when N = 1. The board instead acquires samples with 1 mega samples/sec and every second you read only 1000 from them -> the buffer will get full -> error. 

[Notay]

Hi PaulieQ - just tested your program and I first get an error on the property nodes for both stop buttons - error 1193 - so my attempted fix was first replace mechincal latch action of boolean to 'switch when released'. This did not work so just for testing purposes of your program, removed it altogether.

Tested the program and found the top loop works fine and is in sync and elements do go into the queue. However they are not displayed on both 'array' indicators in the case structure - my guess is it something to do with the '# pending out' line is wired to the case structor - but I may be wrong.

Am I right thinking that once there is a single element in the queue the case structure should allow that element to be released from the queue and displayed on the array indicators?

Many thanks.