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

[josh_duffin]

Hi John,

I removed the 1st sample throwaway from the loop, but it still times out when I run it, waiting for one more sample that never comes.  It seems to occur regardless of the number of points in the loop.

Any other ideas?

-josh 

[John_P1 · Accepted solution]

Hi Josh,

There is now a seperate version of the code for the 621x boards.  I found a 6218 to test on to make sure the code runs.  I just had to tell the counter task to expect to acquire one less sample (subtract 1 on the number of samples to read input).  I also removed the part that acquires the one sample to throw away as we mentioned before.  Thanks for catching the problem, this probably saved someone else a good deal of trouble if they ever need to use the example code.

Here is the link again for your convenience:

Synchronize Analog Output Sample Clock with TTL Pulse Count

-John

[josh_duffin]

Hi John,

the 621x version does run correctly for me too.  I'm having a bit of trouble understanding the flow as you have treated it, would you mind clearing up one detail?

Let's say I want to draw a 4x4 pixel image, so I need a total of 16 samples.  The raster generator  you include with the code actually generates n=17 points for the AO, the last one being a 'reset' to the lowest x and y voltage.  As you have it set now, the counter takes n-1 samples (16) which is the correct number of pixels - but I'm wondering where the extra point lies in the timing diagram.  That is, will the i=0 counter sample match with the first AO point (as it should), or will the i=16 counter sample match the last AO point (being the 'reset' point), and hence be off by 1 throughout?  If the latter, we should add an extra sample at the beginning of the raster to match the phases, correct?

I can't think of a good way to check this without the instrument, can you inform me?

Otherwise, this looks perfect.

-josh 

[John_P1]

Hi Josh,

We are interested in the amount of pulses that occur between sample points, since the sample clock itself represents the transitions from pixel to pixel.  So, at the first sample clock tick we merely want to initialize the counter and begin generating the first pixel.  At the end of the first pixel, we have the second AO sample clock tick which will latch the count value into memory.

So, the last sample (17) is the one that latches the 16th pixel's count into memory and restores the AO to the initial state.  If you don't want to go back to the initial position, another option would be to simply repeat the last X and Y values of the AO.  On the 621x, we tell the counter to acquire 16 samlpes since the first is automatically discarded for us.  On the other M series boards, we need to acquire 17 samples and manually throw the first away (since this sample does not represent the counts that occurred during the first pixel, but rather the number of counts that may have occurred before the AO has started).

So, AO[0:15] represents the voltage values of the pixels.  Counter [0:15] represents the number of pulses that occurred at each pixel.  AO[16] is just the last value that you want your X and Y to revert to when the test is complete (and we use the sample clock edge to latch in Counter [15]).

-John

[josh_duffin]

Hi John,

that makes perfect sense - we need one final 'extra' tick of the sample clock to force the final count into the buffer.

I'm tagging this problem as solved, but I'll post back here in about six weeks after I get it working in the field.

Thanks again for all your help, I don't think I would have gotten this far alone in six months, let alone six weeks.

-josh 

[josh_duffin]

Hi John (hope you're still listening),

I got the DAQ board finally, and it seems to be operating very nicely.  I'm just wondering about a modification that I can't seem to make happen.  I'd like to do a continuous 'high speed' acquisition so that  the user can tune the instrument.  This seems to be more complicated than simply changing the sampling mode to 'continuous', can you advise?

Best,

-josh 

[John_P1]

Hi Josh,

Good to hear from you again, I hope all is well!

By 'high speed' I'm assuming you don't want to call the entire code over-and-over inside a loop, which would be one way to make this run "continuously".  Changing sampling mode to continuous is a good start, but the problem is that the original code reads in a single line at a time, then draws it.  At higher rates, the overhead of re-drawing the graph so frequently might be preventing you from pulling samples from memory fast enough and you will eventually overwrite your data.

Changing the sampling mode to continuous as well as graphing all of the data at once instead of line-by-line should allow the code to execute continuously.  I think I made the original code line-by-line since we had said a maximum of 400x400 at 10 kHz, which would be 16 seconds to draw the entire frame.

One other thing to mention is that you will need to take out that last sample (you had asked about it in an earlier post) from the raster pattern.  This sample was used to latch the last count into memory, but now we will just use the start of the first sample of the next acquisition to latch this sample into memory.

The attached code seems to work well for me, let me know how it goes!

Best Regards,

John

[josh_duffin]

Hi John,

yup, that does the trick.  I have no idea why my attempts wouldn't work, I never got anything but an empty array from the counter after the first complete raster cycle.  FWIW I did remove the 'throwaway' first sample in your example, as you mentioned before my USB-6212 does this automatically.

I could use some advice about flushing out the counter/AO buffer - I'm monitoring the AO signals on a scope. If the user clicks the 'stop' button, the tasks halt and get cleared, and the AO channels simply hold at whatever output voltage they were on when the button was pressed.  However, when I start a new acquisition, the AO seems to OCCASIONALLY carry on from where it left off before starting the 'new' frame.  This of course causes all kinds of errors with counts not being available due to buffer size mismatches, etc.

Any way to flush out the AO (and presumably also the counter, I don't have any inputs wired yet)?  Any idea why it only happens sometimes? 

Thanks a lot,

-josh