Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

pcie-6323 counter

I am using 6323 counter - continuous output.

 

I would like to have 2 counter output (cntr0,cntr1) going at the same time. It seems like when the  Counter-countinuous Output - stay on. vi (below ) is done, the output turns off even if I did not call the stop task.v...I will call the .vi 2x- once for each counter. This .vi is actually just the counter-continuous output .vi example without the stop task.

 

Is there a way to keep ctr0 and ctr1 going after the .vi are don

0 Kudos
Message 1 of 5
(1,798 Views)

Adding

As i understand it, the counter task will keep running after start task.vi at which time i call the Stop Task.vi. Is this correct

0 Kudos
Message 2 of 5
(1,795 Views)

I'm guessing you're running that example vi as a stand-alone and that's why the counter output doesn't persist, even without an explicit call to DAQmx Stop.

 

It's kinda subtle, but it follows a more general LabVIEW rule.  References and (many) resources get automatically cleared up and released when execution ends.  The specific formula is that this cleanup happens when the top-level vi in the hierarchy that opened the reference finishes running.   In the case of a stand-alone vi, the vi itself is its own top-level.  Thus right after starting the task, execution ends, triggering LabVIEW's auto cleanup which automatically stops and clears the task you just started.

 

Turn your example into a subvi and pass the task refnum back out as an output terminal.  Call it from a different top-level vi, feed the task ref into a While loop that waits for you to click a Stop button or something like that.  You'll see that the counter task and output signal persist just fine in this situation.   The task won't get the auto-cleanup treatment until you click Stop to end execution of the top-level vi.

 

This is similar to the behavior you'd get from a full app.  Your subvi could config and start the counter task, and it would stay valid as long as the top-level vi in your app continued to run.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 5
(1,773 Views)

Thanks for that very good explanation. Can I run the .vi by reference , like invoke node and stop it at a later time.. I could put the loop at the end of the .vi, so it will keep running.

0 Kudos
Message 4 of 5
(1,734 Views)

Could you run the vi by reference?  Yes.

 

Are your schemes for keeping it in run state for a while and stopping it later good ones?   I don't know.  You'd have to describe them more.

 

A very simple and decent approach would be to pass in a valid Notifier (or Queue) refnum when you launch it.  Instead of having a loop, you can just Wait on Notification or Dequeue with a -1 (infinite) timeout value.  Once you get the message to shut down, you can stop and clear your counter task on the way out. 

 

Though not recommended, this approach works out even if you fail to send the shutdown message.  As the main app finishes executing, the Notifier (or Queue) will be destroyed.  This will cause your dynamic vi stop waiting, producing an error as the refnum becomes invalid.  And then, just like before, you can stop and clear your counter task on the way out.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 5 of 5
(1,729 Views)