LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

count digital events timeout not working

Labview 8.0, PXI-6229

I need a function which will wait for the falling edge of a signal, and then move on to another vi I have not yet defined. It should timeout if the edge
does not happen in a couple of seconds. Seems pretty simple.

I am using the "count digital events.vi" example, and the event counting seems to work fine. The timeout feature (in the while loop) will not timeout.
I have made slight modifications to the example since I could not use it as-is. I am looking at only one signal, using falling edge only. Since I wish
to exit the loop on any count, I have wired the data output to a ">0" comparison feeding an additional "OR" to the loop stop. This part all seems to
work, it is just the timeout that doesn't.
.




0 Kudos
Message 1 of 6
(3,291 Views)
Hello tadk:

I think you misunderstood the timeout input of the "DAQmx Read.vi".  According to the help file, it is the "specifies the amount of time in seconds to wait for samples to become available".
So it is actually checking if the samples are available, it does not care wether you have the falling edges or not.

In my opinion, if you want to stop the vi after a specified amount of time, you might want to check the number of iterations in a while loop, connect it to a comparisson function, then to the "OR" gate of your loop stop.

I hope this helps.

0 Kudos
Message 2 of 6
(3,290 Views)
This example & block diagram is almost identical to "Read Dig Chan-Change Detection.vi" which was the first one I tried to use.
The timeout in this example works as I expect. If no edges occur, the loop will timeout.  The timeout causes an error which stops the loop.

Since the same polymophic VI is used inside the loop as the "count digital events" example, I expect the timeout should work the same.
Unless there is a bug....

Unless I am totally off the mark, the only way samples could ever be available is if edges occur. Am I wrong?
I do see there is a loop timer inside the 1st example but not the second. 
0 Kudos
Message 3 of 6
(3,288 Views)
Hello tadk:

Yes, in the "Read Dig Chan-Change Detection.vi", you have the timing vi to be your source of samples.
In this case, the samples will be available dependent on the rising and falling edge of some digital lines.
If there are no rising and falling edges, then there will be no samples, and if this occur for a long time, a time-out will occur.
But if you remove the "DAQmx Timing.vi", it will no longer wait for samples to be available.
Just like what happens on "Count Digital Events.vi"



0 Kudos
Message 4 of 6
(3,283 Views)
I am confused then, because in the 'change-chan' example, the timeout is obviously controlled by the read vi, not the timing vi.
could I add the timing vi to the count-events example?

At some level I know that in order to detect an edge, you either continously take samples comparing every two successive
ones for change, or you can use an edge-triggered device. I suspect the 'change-chan' uses the first method, I don't know
what the 'count-events' uses, but I would guess the second method. 

I see a bigger problem for me. The big picture is I want to wait for a falling edge, delay 300ms, and then measure an analog
voltage. I was planning to use a mux-dmm examples I have found to do the actual measurement. Because I am using Teststand,
I had a step that senses the falling edge, a step that delays, and a step that measures. The problem is when I try this the mux-dmm
example has a long setup time so the actual measurement takes place long after the 300ms delay. It seems like I need to use the
dmm-mux in continous mode first (say every 1ms), and then somehow trigger off the falling edge to pick off the 300th sample.  Unless
there is a way to synchronize samples.

I would prefer to use the dmm-mux, but I also have some analog inputs on this card that I suspect would have very little setup time.


0 Kudos
Message 5 of 6
(3,278 Views)
Hello tadk:




@tadk wrote:
I am confused then, because in the 'change-chan' example, the timeout is obviously controlled by the read vi, not the timing vi.
could I add the timing vi to the count-events example?


Yes, but the timing was set before the read vi.  So the settings are already saved to the DAQ task even before the read has begun.  So the read would then rely on the timing settings of the task.  You can use the timing vi on the count events example although take note that the timing vi checks for change detection of the digital i/o and not the counter i/o.



@tadk wrote:
At some level I know that in order to detect an edge, you either continously take samples comparing every two successive
ones for change, or you can use an edge-triggered device. I suspect the 'change-chan' uses the first method, I don't know
what the 'count-events' uses, but I would guess the second method. 


You got it on the other way around.  The "change-chan" uses an edge-triggered device which was set on the timing vi.  The "count-events" continuously take samples.  As you can see, when you run the vi and there's no edges, the value read are always zero.  When there are edges found, the number of edges will be stored on DAQ memory.  The read vi on "count-events" would then read the number of edges found on the DAQ memory



@tadk wrote:
I see a bigger problem for me. The big picture is I want to wait for a falling edge, delay 300ms, and then measure an analog
voltage. I was planning to use a mux-dmm examples I have found to do the actual measurement. Because I am using Teststand,
I had a step that senses the falling edge, a step that delays, and a step that measures. The problem is when I try this the mux-dmm
example has a long setup time so the actual measurement takes place long after the 300ms delay. It seems like I need to use the
dmm-mux in continous mode first (say every 1ms), and then somehow trigger off the falling edge to pick off the 300th sample. 


In your project, it seems that it is better to use the "change-chan" example as your reference.  Although there seems to be a problem with your DMM with a very slow set-up time.



@tadk wrote:
Unless there is a way to synchronize samples.

If you're using NI PXI-DMM cards, then it is possible.



I hope this helps.  Please advice if there's anything else that you need.




0 Kudos
Message 6 of 6
(3,266 Views)