How to read multiple channels simultaneously with minimum delay

[ballbouncing]

The purpose of using 100KHz time base is that I found no simpler choice. I can choose 20MHz and 80 MHz which I think are too much. I have just set the clock to onboard but it finally collects nothing, it is collecting constant 0. I attached the code for more conveinence. 

I plan to recoed the data at minimum constant 1 KHz. Thats why I am using the timed loop to have constant Khz data. 

Synchronization is anothre issue. I have 3-4 other data acquisition loops in the complete version of this application. They must work together synchronously. In the complete code,  I have used time-loop with "Create 1KHz Source" as their "Timing Souce Terminal" to keep loops synchronized. If I want to use this simple while loop, then how can I synchronize them together.

Thanks

Amir 

[ballbouncing]

The purpose of using 100KHz time base is that I found no simpler choice. I can choose 20MHz and 80 MHz which I think are too much. I have just set the clock to onboard but it finally collects nothing, it is collecting constant 0. I attached the code for more conveinence. 

I plan to recoed the data at minimum constant 1 KHz. Thats why I am using the timed loop to have constant Khz data. 

Synchronization is anothre issue. I have 3-4 other data acquisition loops in the complete version of this application. They must work together synchronously. In the complete code,  I have used time-loop with "Create 1KHz Source" as their "Timing Souce Terminal" to keep loops synchronized. If I want to use this simple while loop, then how can I synchronize them together.

Thanks

Amir 

[Dennis_Knutson]

Just leave the clock source alone and use the default.

As mentioned several times, it is the selection of your sample rate that determines how fast you sample. The timed loop DOES NOT.

Your approach does not synchronize. They will operate independently. If you use a queue (producer/consumer) to pass data from one loop to another, your other loops will not operate on the data until it is actually ready. Using a timed loop on anything other than a real time OS is generally a waste of time. It does not guarantee anything other than you can be notified when the loop is late.

[ballbouncing]

Hello agani,

Thanks for your last guidance as it worked pretty well in the analog data acquisition. But apparently this is not teh case in linear encoder. As attached to this message, I have a linear encoder as well that I need to sample at 1Khz. 

The current code give the error:

Error -201002 occurred at DAQmx Start Task.vi:1; Sample Clock Rate must match the frequency of the internal timebase specified as the Sample Clock Source....

Could you please help me on this one as well. Should I use external sample clock or ...?

[Kevin_Price]

1. Instead of specifying your sample clock source as "/Dev1/100kHzTimebase", specify it as "/Dev1/ai/SampleClock".

2. Add some dataflow sequencing to make sure you start your encoder task before the ai task, preferably with the error cluster that passes in and out of all the DAQmx vi's.   You ought to be using and paying attention to that error wire anyway.

-Kevin P

[ballbouncing · Accepted solution]

Kevin,

Here is the revised code according to your guidance. It runs with no error but it does not count, i.e. encoder indicator on the Front Panel is always 0: (Position = 0).

Could you please let me know where the problem is.

Thanks.

Amir.

[ballbouncing]

Kevin,

I corrected my mistake, and it worked. Thank you very much.

My last concern is about the actual sampling rate. How can I make sure that I am truely sampling at 1KHz. Because when I write the data into .txt file some samples are repeated, they are exactly the same. This means that I am not actually running at 1KHz. Also delay is anothre issue, i.e. I need to know the current sample in the while loop belongs to how long (msec) ago in the phyical process or at sensor contact.

Thanks.

Amir

[Dennis_Knutson]

Now you've changed your code so that you are no longer sampling at the specified rate. What prompted you to change to 1Sample mode? You switched to software timing instead of what you originally had which was a precise 1 msec sample rate. I don't understand your reasoning at all nor do I understand your obsession with using an unsynchronized timed loop.

Stop making random changes. Go back to the N channel read. Adopt a producer consumer architecture where you do the file write of the multiple samples in the consumer loop.

Undo marking your thank you as the solution to the thread.

[Kevin_Price]

You should put your encoder & AI tasks into the same loop.  Read the same # of samples from each task (maybe 100-250 or so for your 1 kHz task).  Combine them and transmit them via queue to a separate file-writing loop.   You can find examples for this kind of thing by searching for "producer consumer".

Now then, for the "decision" stuff you mentioned in your original post.  Let's say you read 100 samples at a time.  You are now refreshing your measurements and can make new decisions 10 times a second.  If you want your decision to be based *only* on the very most recent measurement(s), ignore the first 95-99 of those 100 samples and base your decision only on the most recent 1-5.

This gives you a decision-making rate (control loop rate) of 10 Hz but with a very low latency.   Don't try to run a 1 kHz control loop, at least not yet.  First get comfortable with hardware-clocked samples, producer-consumer queues, and low latency decisions at <= 10 Hz.

After you understand and work through everything it takes to get it all going at 10 Hz, you'll be in a better position to grapple with the additional issues you'll face when aiming for a 1 kHz control loop in Windows.

-Kevin P