LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does Digital Input and Counter Pulse width not work together in a while loop?

I'm not including code because an example can be created quite easily. I'm using USB-6341 Daq and LabView version 15. Create a while loop. Outside the while loop create 2 Tasks. One for Digital Input single line input. I used port 0 line 0. I have a square wave signal feeding this that has a period of 1.5 seconds, 50% duty cycle, 0-5 volts.

The other task is a counter input for measuring the same signal. Setup up for doing pulse width measurements. Using Cnt0, PFI9 as input.

Inside the while loop is a Digital Read Single Channel, Single Sample. Also, another Read VI for the counter That is 1 Channel, 1 Sample. Also there is a stop button.

If I run both Tasks together only the counter task works and not the Digital In. No errors are generated. If I run only the Digital Input task by itself after removing the counter task, then the Digital Tasks works fine.  I tried all sorts or variations of running these two tasks together in a single while loop, Trying to start one task before the other one starts for example, or using a Reserve Control Task VI per examples found in this forum.

What does work for me is two parallel while loops one for the Digital In and another for Counter Pulse Width measurements. But I can't use it that way. I have to process both in the same loop. I even tried a Consumer/Produce loops which works but I am unable to use it due to the counter task being in it's own loop is causing me issues.

Basically the DAQ is monitoring analog inputs, Digital Inputs, performing digital outputs, and doing pulse width measurements.

I stripped everything out except Digital inputs and Counter pulse width measurements which don't work together in a single while loop. 

I am monitoring a power supply voltage that is powering up another circuit. This circuit creates continuous pulses I have to measure with the DAQ. The power supply is going to be cycled on/off several times over a period of hours. I monitor amplitude of the pulses, as well as the Pulse width. I don't want my LabView application to think there was as error with the measured signal when the power supply is being cycled. Basically it needs to ignore any failed limit checking I do when power is cycled off. Can anyone offer some advice it would be greatly appreciated. Thanks.

0 Kudos
Message 1 of 3
(1,671 Views)

No one is going to want to take the time to create your example for you. If it's that simple, load one up to show us what's going on and people will be more willing to help. Plus, all of your constants for setting up your tasks may be different, as well as how your error wires are run.

 

What happens when you try to run your program? What does "doesn't work together" mean? Does it return bad data, an error, no data, etc? We need much more information.




Heads up! NI is moving LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 2 of 3
(1,666 Views)

Yep, please post the code but *first*, set reasonable values on your front panel controls and save all as defaults.

 

The behavior you describe is not a necessary behavior and is not a device limitation.   If the code works in parallel loops, there's a way to make it work in the same loop.  I strongly suspect something in the code sequencing or lack of error handling or, well, *something*.  But I've gotta see it.  (Though it may turn out that parallel loops are a better idea anyway for a variety of reasons, not merely because it happens to work the way you coded it.)  

 

Note: pulse width measurements work a little different than many other tasks.  It'll use "Implicit" timing and wait for the next full pulse before it can return a measurement.  It won't return immediately.  If you start just after a rising edge, it won't return a value until almost 1.5 + 0.75 sec later after the next rising/falling edge pair.  In general, your wait time can vary from 0.75-2.25 sec for a pulse with 50% duty cycle, 1.5 sec period.

 

P.S.  I would recommend you "Save for Previous Version..." as well, go back to 2014 or so.  

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 3 of 3
(1,647 Views)