From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange behaviour while start, modify and stop a counter output task

Hi all,

i realized a VI that allows me to start and stop a counter output task previously created in NI MAX. This VI is placed in a while loop and gives me the possibility to change on the fly T-High and T-Low values of the output signal. You can find it attached.

 

The VI works fine in all aspects except one: when i stop the task and restart it, the T-high and T-low values are always the same and correspond to the first ones i used. It seems not possible to restart the task using different values than those used when it was started for the first time. In the following an exemple:

 - Started using T-H=0,01 and T-L=0,01

 - Modified using T-H=0,002 and T-L=0,008

 - Stopped

 - Restarted using T-H=0,002 and T-L=0,008 (last values provided) -> problem: the signal is generated using the first set of values (T-H=0,01 and T-L=0,01)

 

I tried different methods without success. Thanks for helping me!

Marco

 

 

 

 

0 Kudos
Message 1 of 4
(3,017 Views)

This kinda rings a bell.  I was in a similar thread a little while back, hmmm, hang on a sec while I thumb through my bound hardcopy of the internet...

 

Ah yes, here we are.  See this thread.  It appears that you may be able to accomplish what you need if you:

1. explicitly "commit" the task using DAQmx Task Control.vi before starting it

2. retain on your block diagram the most recently written low & high times.

3. re-write those low & high times while the task is stopped (but still committed)

4. according to my earlier observations, these pulse specs should persist as the defaults for subsequent stop/starts until you override them with a different write-while-stopped

 

 

-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 2 of 4
(2,963 Views)

Hi Kevin, thanks for your answer. Last successful attempt was done using a "Clear Task" instead of a "Stop Task".

 

Even if it's not logical to clear a task knowing that it will be used again in the same session, i chose this way cause it seems to me to be the cleanest one.

 

Attached the VI. Bye

Marco

0 Kudos
Message 3 of 4
(2,954 Views)

The main difference between the more complicated stuff I outlined and your "Clear Task" approach is the turnaround time required for the task to be either stopped/restarted or cleared/reconfigured.  Clearing and reconfiguring will take longer, maybe a few 10's of millisec.  If your app doesn't care about that kind of time, clearing and reconfiguring should be fine for you.  If you later want faster turnaround, you can come back to consult the steps I outlined and try the other way.

 

 

-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 4 of 4
(2,940 Views)