Timing pulses after a trigger using a pci6602 card

[John129]

Hi,

I am currently trying to design a program to determine the number of clock cycles which have passed between a trigger and a series of signal pulses  i.e. n signal pulses arrive after the trigger and I want to output an array which contains the time each arrive at, after a certain time another trigger arrives and the process is repeated.

I am currently using a pci6602 card and would prefer it if the program used daqmx.

[josswern]

You can use a buffered period measurment for this, given the fact that you know the number N of pulses which arrive after the trigger signal for each cycle.
just set your buffer accordingly.
then set up your measurment to use the internal clock as source, feed your pulses to the gate for the counter.
I've done this for up to 16 channels (2 6602 cards) in parallel, using traditional daq, should be possible with daqmx as well (in theory, at least - see my other thread w.regard to 6602/daqmx 😄 )

[Kevin_Price]

Adding to the previous reply:

- You'll need to configure the counter to use the trigger as a digital "Arm Start" trigger.  (search forums / site for more info)

- As far as I know, the "Arm Start" trigger can't be configured to be re-triggerable.  So you'll probably need to call DAQmx Stop after reading your first set of data and then call DAQmx Start to re-arm the counter for the next trigger.

-Kevin P.

[John129]

Thanks for the help and sorry for the late reply but have been busy on other things and just got back to this program. To clarify above n is a variable i.e. I could have 10 counts in one cycle and 1000 in another. Have been trying the suggested methods but am getting the dreaded  200141 error   although sometimes it works ok. Was thinking of measuring the trigger pulses using the same method and then subtracting the trigger pulse times from the signal times but was wondering if they both will have the same initial zero in the timebase.

Thanks
John    

[Kevin_Price]

Your recent idea is right on target.  Using the trigger pulses as data acq task triggers would require you to anticipate the next trigger so you can perform software calls that stop and restart your task in time to react to the next trigger signal.  If there's no way of knowing which pulse is the last one before the next trigger (or you have only a few msec to react between the last pulse and the next trigger), a triggered task really isn't the best option.

You can leave all the timing in the hardware if you go ahead and simply timestamp both the trigger pulses and the signal pulses using 2 simultaneous tasks.  Then some fairly simple post-processing will get you the data in the form you want.  To get their zero times in sync, both should be configured to use the same digital "Arm Start" trigger, which is found only in the DAQmx Trigger Property Node.   I've often created my own trigger signal using either another counter or a digital output bit. 

-Kevin P.

[John129]

There is however the problem of the 200141 error which is starting to bug me. Last week or so I tried a virtually identical program to the one I'm working on today and didnt get the error but today it seems to want to give me the error 90% of the time. Any ideas on how to get rid of it?

Thanks

John

[Kevin_Price]

I don't usually get that error unless the the pulses I'm timestamping are electrically noisy, either picking up short noise glitches or ringing on transitions.  Another possibility is receiving several consec pulses at a high burst rate, like in the 100's of kHz or more.

However, there are other general causes as well which tend to be more common for most people, especially those who are somewhat new to counter measurements.  (For the most part, I've learned how to avoid these).  They mostly revolve around how big a data acq buffer you create and how you program your app to read data out of it. 

Some very general suggestion would be to create a good-sized buffer, read from it maybe 10 times a second or slower, read data out in decent sized arrays (from 100 elements up to 1/2 the buffer size).  Can you post screenshots of the code that configures the counter(s) and reads the data?

-Kevin P.

[John129]

Curently the code I'm working on is a modification of the buffered event counting example (It will be added to a larger program later but I want a simple version working first). As I say it was rather strange as last time I was working on it, it worked ok only giving me the error ocassionally but noe it only gioves me an array ocassionally and I don't think the program has been changed since then

[John129]

hmm just found out the simple solution as to why it wasn't working. It turns out that the lead to the counter box wasn't secured properly which meant any vibrations in the lab was allowing a signal though at one time and not allowing a signal at another. I should really have considered this earlier but the fact that I was occasionally get the expected signal through kinda threw me. I kinda feel a bit silly now 🙂

[Kevin_Price]

Makes sense -- a bad connection could certainly produce the bursts of edges that can also lead to that error.

Meanwhile, post back if you have further difficulty expanding this into 2 simultaneously-triggered edge counting tasks plus post-processing.

-Kevin P.