Digital Trigger after Counting a Specific Value

[synergymus]

I have a few questions on an application I'm developing.  I'm still fairly new at labview (3-4 applications) so I would appreciate any criticism/advice on the way I've coded this VI.  I'm still learning the best/common way of doing things in Labview

Application: I have a single photon counting detector connecting to a counter on a PCI-6259 controlled by Labview 2009 and DAQmx 9.0.2. The detector outputs TTL pulses.  I have two other devices which will be trigger on/off by TTL high/low using DIOs.  The two devices will be turned on (TTL high) at start and off (TTL low) after a specified number of counts.  I would also like to perform the same action but turn the devices off after a specified amount of time.  There are some other bells an whistles as you can see.  

Question 1:  I would like to be able to abort the counting but clicking the start/stop button off.  The way I have the VI coded now I cannot activate the start/stop button while the counting loop runs. I previously coded this VI using a hierarchy of while loops and case structures, but when I switched to an event structure the button stopped working.  When inside an event triggered on a button "change value" is the button disabled?

Question 2:  When I originally created this VI, I was mostly concerned about triggering at the specified count value.  The timing was only for references.  This is why I put the timing in a separate loop and I didn't care about the lack of synchronization.  I would now like to perform the experiment based on time as well.  How can I properly synchronized the timing with the counting?  When I use the"time" method I don't really care about the counts, so I could create a new event with the "time" and "count" loops switched.  This seems clunky to me.  Is there away to count to a certain value while knowing the exact amount of time it took?  Maybe a freq measurement?

Question 3:  When this program exits it can leave devices in unworkable conditions.  When is it appropriate to reset a devices?  If I choose not to reset the devices but would just like to set all digital outs to low upon exit what is the best way to capture the stop application button in the VI toolbar and execute this action.  

Thanks much

[synergymus]

Question 1:  I would like to be able to abort the counting but clicking the start/stop button off.  The way I have the VI coded now I cannot activate the start/stop button while the counting loop runs. I previously coded this VI using a hierarchy of while loops and case structures, but when I switched to an event structure the button stopped working.  When inside an event triggered on a button "change value" is the button disabled?

Well I guess I posted too early on this question.  I fixed this by moving the entire event into a case structure in the main loop.  Is this acceptable?

[EricS.]

Hi synergymus,

That is an OK way to do question 1.  Note that the event structure will queue events, however.  So if you click "Load" and then "Start" and then "Load" a whole bunch, it will run through that queue of events, one per outer loop iteration.  If that's OK, then you're good.

Question 2:  If you're concerned about time, I would use a waveform data input from your counters instead of U32.  Waveform data types return the time value of the samples as well. It has a t0 (time of first sample), and dt (time between samples) you can use the Get Waveform Time Array.vi, which automatically multiplies out the t0 and dt for the entire waveform and gives you an array of those time values.  The waveform data type also has a Y array, which is the array of actually values, counts in this case, read from your device.  You could search the Y array for the count value you're interested in, and then look at the corresponding time, and subtract that time from the first t0, will give you the total time it took to count that many values.

Question 3:

Do not use the Abort Button in the toolbar.  This will abort the VI and not release the hardware resources.  If you do this the devices will return an error the next time you try to run your VI, saying the resource is reserved.  The Abort Button is to be used as a last resort.  You should implement a stop button, much like you have a start button.  The stop button should:

1) Stop your outer while loop

2) Clear all DAQmx Tasks (this frees the resources)

In your code you could simply replace the Boolean constast on the far right with a boolean control of a stop button.

[synergymus]

Thanks Eric, I need some qualifications

---

Eric S wrote:

That is an OK way to do question 1.  Note that the event structure will queue events, however.  So if you click "Load" and then "Start" and then "Load" a whole bunch, it will run through that queue of events, one per outer loop iteration.  If that's OK, then you're good.

---

 Is this true even if the buttons are disable, like in my example.  So while I'm in the read/pulses and trigger loop if I press "Load" will it queue even though it is disabled at that point.

---

Eric S wrote:

Question 2:  If you're concerned about time, I would use a waveform data input from your counters instead of U32.  Waveform data types return the time value of the samples as well. It has a t0 (time of first sample), and dt (time between samples) you can use the Get Waveform Time Array.vi, which automatically multiplies out the t0 and dt for the entire waveform and gives you an array of those time values.  The waveform data type also has a Y array, which is the array of actually values, counts in this case, read from your device.  You could search the Y array for the count value you're interested in, and then look at the corresponding time, and subtract that time from the first t0, will give you the total time it took to count that many values.

---

Can you send an example, I couldn't get this to work.  I tried using  Counter 1D DBL N Samples but there were no timestamps (well the timestamps were all the same).  Should I be using a different DAQms Create Channel Version.  I can sort of see how this may work with some of the counting version maybe count the sample clock ticks between ever pulse (pulse width measurement)?  

---

Eric S wrote:

Question 3:

Do not use the Abort Button in the toolbar.  This will abort the VI and not release the hardware resources.  If you do this the devices will return an error the next time you try to run your VI, saying the resource is reserved.  The Abort Button is to be used as a last resort.  You should implement a stop button, much like you have a start button.  The stop button should:

1) Stop your outer while loop

2) Clear all DAQmx Tasks (this frees the resources)

In your code you could simply replace the Boolean constant on the far right with a boolean control of a stop button.

---

 I will implement this.  Here is my latest version with both time and pulse experiments working.  Although the time is not dependable as stated before.

[synergymus]

So I thought of another solution to fix the timing accuracy problem.  Perform a buffered counting measurement on the sample clock using the pulses as gates.  So then the count in each gate would be the time and the total number of gates would be the pulse count.  I'm not quite sure how to set this up without physically connect ctr1 to ctr0 which I don't want to do.  If I set up a pulse train on ctr0 then set a counter reading on ctr0 will it route the pulse train internally or will it fail since the ctr is already used?  I will try it out today and see what happens. 

[synergymus]

Okay, so I set up my application using a pseudo period measurement.  I set up a buffered edge counting measurement using the 80Mhz timebase the source and my signal as the gate.  I then take the time the total number of samples as counts and the total number of ticks as the time.  This works pretty well but it requires more calculations in the acquisition loop which creates more overruns.  With the previous version the final total count was almost always equal to max count, now it is always more.  It is most consistent and with in an acceptable margin for my application.  

I also experimented with using a buffered period measurement, I think this requires more calculations in the acquisition.  

Are there any glaring issues?

[EricS.]

You're correct, that if you have those controls disabled then the event of clicking them do not queue up.  I didn't see those property nodes when I glanced through your code the first time.

Also, unfortunately the counter input tasks don't have waveform as a data type to return.  Only analog and digital input tasks can return a waveform datatype with t0 and dt parameters.

I want to confirm what exactly you're trying to do with the time.  Do you want to acquire for a certain amount of time and then stop, or do you want to know the time that each number of counts have come in?

If you simply want to stop after a certain amount of time overall, could you simply have a "Tick Count" VI (which you had in the earlier versions) at the beginning when you start the acquisition, and then call "Tick Count" again, compare the new value and the old value, and if the difference is greater than the time difference that you want, stop the acquisition loop.