Multifunction DAQ
DAQ PCI card selection - counting pulses as a function of AO position
Solved!
- last edited on by
Content Cleaner
Hi Josh,
This sounds very interesting, I think we can do what you need on the 6251, but I would like to verify the exact requirements first:
1) ao0 and ao1 share the same timing engine, so must be updated at the same time. The maximum update rate is 2.86 MHz, so the 0.01ms dwell time shouldn't be a problem (update at 100 kHz). The counter does not have to sample at the same rate as the analog output tasks.
2) From what I understand, you would like to count the amount of TTL pulses that occur during each pixel (AO update). These pulses may be coming in as quickly as 5 MHz. So, you're counting the occurence of 5 MHz pulses during the .01 ms dwell time. This should also be doable, as the 6251 specifications state that it may count up to a 20 MHz external signal.
I think the Analog Output side of things should be pretty straightforward, just build your waveforms in software, write to the DAQmx Buffer, and generate based off of the AO sample clock (100 kHz clock would give you .01ms dwell).
The counters allow for a buffered count edges task, which means that you sample the count register on the rising edge of a given sample clock. Of course, the 5 MHz signal would increment the register faster than the sample clock, but you can read the value of this register based off of the slower clock signal. The signal would look something like this (from the M Series User Manual😞
You would use the AO sample clock to latch the value of the count register into the buffer. In the above configuration, this also resets the counter value. If you need to keep a running total, you would just have to configure a Buffered Edge Count task instead of a Buffered Period Measurement.
One final concern is the transfer rate. The standard M Series counters have a small (2 sample) FIFO for buffered counter tasks. This could possibly be an issue if acquiring at 100 kHz while performing other activity on the bus (if you write a new value to the FIFO before the previous value has been read, the task will throw an error). As the Benchmarks for Buffered Counter Input with M-Series Devices article indicates, you should be fine at 100 kHz, but this is entirely system dependant and would be affected by other activity on the bus (i.e. the Analog Output task).
You may notice in the above benchmark article that the USB 621x devices can acquire data much more quickly on the counters. This is due to the fact that these devices have a larger FIFO than the other M Series. Unless there are other considerations that I am not aware of, you would probably be best with the USB-6218, which has 2 outputs up to 250 kHz. Our other M series would likely work as well, but you may be at the point where too much bus activity may interfere with the counter reads--I think the 6218 should be more reliable in this case.
So, to summarize:
- Based on my understanding, I think we can do what you are asking.
- The 6218 can acquire data faster on the counters, and provides 2 analog outputs at the rates that you require (100 kHz). Other devices may work as well, but the rate data is transferred over the bus will be system dependant so there are no guarantees.
- Use Buffered AO
- Finite if you only need to go through the data once
- Continuous if you need this to loop indefinitely
- Use the AO sample clock as a sample clock for the count register
- Configure a Buffered Period Measurement if you want to reset the register every time you read the value
- Configure a Buffered Edge Count if you want to keep a running total
I hope this clarifies things up a bit regarding our hardware. If I have misunderstood what you need to do, could you please post back a timing diagram or some sort of graphical representation of your signals so I can get a better understanding of the application. Thanks for posting!
-John
Hi John, thanks a lot for your reply, things are becoming more clear and I am feeling a lot more confident about how to go about this.
I think you understand the application quite well, but I'm posting the following timing diagram anyway, to confirm that we both are on the same page:
The example deals with a 4x4 pixel measurement, and as you suggest would use buffered event counting with the sample clock routed to the counter gate to properly sort the collected counts into the right xy positions. In principle this should work exactly as you describe with no problems.
I have a few questions though:
1) What might happen for larger sizes of measurements? Since the user should have the option to specify up to 400x400 pixels (with 100x100 being the 'default' size), will the buffered counter task still work? With 100x100 pixels we have 10000 individual samples for the counter, is this more than the FIFO size on the USB-6218?
2) What lead you to recommend the 6251 over the 6229? I'm looking at the specs for both AO and counters, I think they are identical, but I may be missing something.
3) The transfer rate issue you raise is a pretty good point, but since the page you refer to is now almost two years out of date, I am wondering if it's still relevant to our case, giving the normal computing advances one might expect in two years?
4) I think that some of my confusion stems from my misunderstanding the difference between a 'clock' and a 'rate' in the Sample Clock instance of the DAQmx Timing vi. Could you enlighten me a bit as to what these two terms actually refer to? More importantly, what should these values be set to for correct configuration in the example above?
I'm sure more questions will be forthcoming, but you have been a big help already.
-josh
- last edited on by
Content Cleaner
Hi Josh,
Thanks for the timing diagram--this is what I had in mind as well but seeing it on paper makes things alot more clear for us over here. To address your questions:
1) 160,000 (400x400) or even 10,000 (100x100) would be much larger than the on-board FIFO. Keep in mind that the FIFO is really just an intermediate buffer. During the entire process, the data is transferred to a buffer in RAM through USB Interrupts (DMA if using a PCI device). As long as this transfer can happen fast enough, you should be able to acquire data indefinitely. The potential concern with our 622x and 625x is the fact that this onboard FIFO is only 2 samples long. The 621x boards have a 1,023 sample FIFO, so although USB transfers are slower, the larger FIFO more than compensates for this and the end result is a larger sustained throughput for counter tasks.
2) Good point, I mistakenly read that you were looking into the 6251 for some reason (probably because it is the device that I am currently using). The counters should be identical on the 622x and 625x boards, so there is no problem here. The analog outs on the 622x differ from the 625x, but not by much--you can check the spec sheets for more details, both are capable of the rates you require. If you are going with a 622x, you might want to look into the 6221 since it also has the 2 Analog Outputs that you require and identical counters.
3) This is true, the transfers will be system dependant--the benchmarks are a bit out of date, so it could be entirely possible that your system will exceed the listed value. Keep in mind that the benchmarking was done with no other tasks transferring data over the PCI bus, so I am not positive how the AO task will interact with the counter measurement. This was the reason I had recommended the 6218, but the 622x or 625x boards are certainly a possibility. I believe our new hardware should have a 30-day trial period, so if you need some of the other features of the 6221 or prefer PCI form-factor this would certainly be worth looking into. The 6251 also comes in a PCIe form factor if you are interested in this.
4) Not a problem at all, it's common to have questions with sample clock vs. source etc. (especially when talking about counters). Your timing diagram is appropriately labelled, so it looks like you have a good idea of what is going on in the hardware. Your LabVIEW code would look something like this to configure the tasks:
The typical idea of a period measurement is that you use a known timebase to measure the period of an unknown signal. Here we are essentially doing the opposite, so the terminology may be a bit confusing.
-The Counter Input terminal in this case is the analog output sample clock. We are measuring the "period" of this signal in terms of ticks of the "timebase".
-The "timebase" in this case is not a timebase at all, but rather the external source that we want to count edges of. You can route any PFI line to this.
-The AO Sample clock is created on the board for you. So, here you would specify a rate. By not connecting a source to the AO sample clock, you will by default use the internal AO Sample Clock--this is a divide down from the 20 MHz timebase on the M series boards.
-On the Counter task, we actually use "Implicit" timing. This is because the sample clock is actually the signal we are measuring. That is, upon each period on the Gate, we will report back the amount of "timebase" ticks that occurred. There is no need to configure to use another sample clock (and indeed it is not possible to do so on a 622x or a 625x).
I chose to start the AO task after the counter, so the first edge of AO sample clock will latch in the first value to the buffer of the counter. You should typically ignore this value, since the value is essentially meaningless since the counter is started non-deterministically in software (see the timing diagram of my last post). The 2nd value in the counter input buffer will give you the total number of ticks that occurred in between the first and second AO sample clock edge.
I think we are on the same page here, so please don't hesitate to post back with any questions or concerns. I would imagine the 6221 could keep up on a modern system, but it is something you will have to try out to know for sure.
-John
- last edited on by
Content Cleaner
Hey Josh,
The 6212 is actually an ideal choice (I had mentioned the 6218 earlier but you shouldn't need the isolation or extra AI channels). All of the 621x boards have the 1023 sample on-borad FIFO for counter measurements, so these would be well-suited for what you need to do. If you don't need BNC connections, you can also look into the 6211.
I agree that the "samples per channel" inputs can be a bit confusing. To explain what they are used for:
The input to the DAQmx Timing function is used to configure how many samples to read/write in a Finite Task. Since I had configured a Continuous Task, I left this unwired. However, the input may still be used in a Continuous Task to increase the size of the PC Memory buffer beyond the default value. If you are going through the Raster scan only one time, you should configure your task to be Finite instead of Continuous (in this case you would set Samples per Channel to be 10,000 or 160,000 for a 100x100 or 400x400 Raster pattern).
The input to DAQmx Read is used to control how many samples you return per call to DAQmx Read. For a continuous task, you need to make sure that this is high enough to keep up with the data coming in. For instance, if the loop executes 10 times a second, you would need to be reading in at least 10,000 samples per DAQmx Read call (assuming a 100kHz sample rate).
This crude Paint drawing might help clarify how these parameters fit into the application:
If any of the buffers overflow, DAQmx will report an error. The transfer across the PCI/USB bus takes place automatically as data is being acquired, so you would just need to make sure that you are pulling data fast enough from the PC Buffer so it doesn't overflow. This is typically only a concern for Continuous tasks.
I'm not too concerned with the timeout/slow performance on the Counter task of the simulated device. Remember, we have AO sample clock latching values from the count register into the on-board FIFO--I don't think the simulated device realizes that this signal is going at 100 kHz (it seems to be simulating a 1 kHz signal instead). DAQmx Read will timeout if not all of the samples that you request are available after a certain amount of time (10 sec by default).
I hope this is helpful, please let us know if you have any other questions about any of this.
-John
