DAQ PCI card selection - counting pulses as a function of AO position

[John_P1]

Hi Josh,

The FIFO -> PC step is handled by the USB Controllers and OS, so you don't really have control over the priorities of the transfers.  Minimizing bus activity and processor use is always a good suggestion for applications such as this, but beyond that there is not much else you can do.

You will likely run into problems pulling data off of the board fast enough with USB 1.1, although you would need to try it out to be sure since transfer rates are highly system dependant.  I would strongly recommend sticking with USB 2.0--the benchmarks mentioned in my earlier post were taken with USB 2.0 and should provide more than enough for what you need for this application.

If you are interested in more information about the USB protocol, www.beyondlogic.org has a good overview.  Here is a link to a page from their USB in a NutShell course that deals with data transfers (we use Bulk on our DAQ devices).

-John

[John_P1]

Hi Josh,

I hope all is well.  Strangely enough, I ran into a post the other day that seems exactly identical to what you are trying to do.

While I hadn't heard of this specific use-case before for our DAQ devices, it seems that it may be a popular application given the two very similar help requests.  You mentioned the DAQ device would be a replacement for an old instrument control system, so I was just curious about which instrument you are replacing and if there is a standard name for what you are trying to do.

I might try to post this as an example on our Developer Zone Community if this turns out to be a common application (and I can find the time to polish up the code).  I am just not sure what to call the code so others can find it easily on our website.  I am also interested in any links or additional information you have about the application so I can do a bit of reading myself since it sounds like interesting stuff.

-John

[josh_duffin]

Hi John,

nice find on the other post - we ultrahigh vacuum scientists seem to all want to do the same thing. I am replacing the dying control computer (an early 90s vintage 386) as it's really getting tired.  This machine is interfaced to the SPA LEED with a legacy Burr-Brown board containing only the two AO channels and the counter input.  I think it might have been custom-made for the original supplier of the instrument. However, my application is not XPS or QMS (though I use both of these techniques in the same system!), but SPA LEED, which requires me to sweep an electron beam in 2D across a detector (a channeltron), while I record the counts from said detector as a function of the beam's position.  The link I included to Wikipedia has more detailed references, but they are a bit dry.  

In a nutshell - the electron beam is a signal reflected from a sample, and contains a series of intensity maxima. The goal is not only to record the position in 2D of the spots of high intensity, but also to measure their profiles, which are characteristic of the structure of the surface where the signal originates.

SPA LEED is a totally different technique from QMS or XPS, but the way in which I and the other poster are attempting to operate are essentially identical, save for the fact that mine happens in two dimensions, so I require two AO channels (rather than one) and I draw an intensity chart rather than a linear graph.

I think the key issue for both the other poster and myself is ensuring that the incoming counts are recorded in good synchronization with the voltage increments and the counts - that is, we want to make sure that the counts are measured accurately and precisely for every individual pixel, (in my case, so I can record the profiles accurately).  I have come across similar posts for people attempting to do the same, but their input signal is measured by AI, not a counter, so the situation is a bit different.

I think it would be a big help to have a worked example on the DZ, but I would not call SPA LEED a "common" technique.  XPS and QMS are definitely more widely used, and including the example in 1D might suffice to understand the general solution, and perhaps link here for the 2D version.  As for what to call it, it's a bit hard to be specific since the techniques are dissimilar and might not initially seem to be related. Prior to posting here, I was searching on terms like "AO", "pulse counting", and "synchronization", so that might give you some idea of a generic name.

Like you, I have limited time to work on this - the instrument I want to control is in Italy, and I'm in Canada at the moment, working on a totally different experiment.  As you might imagine, coding is not high on my priority list this month, especially since I don't have a DAQ device to play with.  Rest assured that in a couple month's time I'll be bugging you again with this, since I'm sure I'll find a way to become confused again. 

Thanks again for all your help.

-josh 

[John_P1]

Hi Josh,

I finally got the chance to put together an example on our community site:

Synchronize Analog Output Sample Clock with TTL Pulse Count

I think it should be pretty close to what you need to do--let me know if you have any feedback.

-John

[josh_duffin]

Hi John,

thanks a lot, it looks really efficient - but I can't download the main .vi to try it out, it says "queued" next to the link placeholder.  Any chance you could post it here to give me my instant gratification?

At any rate, we seem to have converged on the same solution, but your code looks a lot more streamlined.  I'm itching to see how you solved the problem I was having of mapping the 1D array of buffered counter measurements to the correct position in the 2D graph.

-josh

PS - I'm now running my own code (with your suggestions, of course) on a USB-6211 and it seems to execute properly, but of course I won't be in a position to test it on the SPA-LEED until I get back to Europe this September.  We still have to purchase a device for that project, so I hope it moves faster than the usual pace of things in Italy (I fear not though) 😞

[josh_duffin]

Never mind about the queued business, I got it!

-j 

[josh_duffin]

Ok, really nicely done.  I see how you're using the "samples per channel" input on the NSamples grab on the counter, I thought before it was somehow related to the internal 20MHz frequency from your previous example.  You're just grabbing exactly one line of the image at a time, and appending this to the 2D matrix for the chart, right?

I'm getting an off-by-1 error at the end of the loop though:  you check to see if Nx * Ny samples have been acquired, but it's getting one less than this and timing out waiting for the final one.  I'm not sure why this might be happening.

FWIW the error isn't being caused by the throwaway single sample on the first iteration (clearing some sort of indeterminate state?) or the "resetting" of the AO channels back to Xmin and Ymin.

Almost there, I think.

-josh 

[John_P1]

Good catch, there was a bug with the number of steps parameter.  When setting a minimum voltage of 0 and a max of 10, it should require 11 steps to achieve 1V increments, not 10.  I fixed the problem and re-posted the code to the same page.  This should fix the timeout error.  Both the main and sub-vis have been changed, so be sure to re-download both.

You're correct that I'm reading back one row of data every time and inserting it to the next row of my array to be shown in the intensity graph.  There are other ways to achieve similar results, but this was the first that came to mind.  Let me know how it goes!

-John

[josh_duffin]

Hi John,

still getting the timeout error - it seems to occur no matter how many points are in the AO array, it's always off by one.

This sounds like a timing/triggering issue - it wants to measure that last point, but perhaps the AO task is already finished.  This suggests that the AO is actually leading the counter by 1 cycle?

-josh

[John_P1]

Hey Josh,

Good call, I almost forgot about this...

The 621x boards actually automatically throw away the first sample of a buffered period measurement.  So, when we throw away one sample in software we leave ourselves one sample short as you have noticed.  The code should work if you delete the segment that acquires the single sample.

I had tested the code on a 6251 without any problems, but this board does not throw away the first sample.  I'll post an update to the community site for 621x boards, which are currently the only family of DAQ devices that do this.  Thanks for the feedback!

-John