Showing results for 
Search instead for 
Did you mean: 

Using DAQmx to output steady DC signal to a Counter

Go to solution

Hi friends.


I am sending output pulse signals of total duration of 100usecs (50usecs high and low respectively) to a counter using DAQmx Counter Output Time configuration. So far, it has been successful. However, I am now implementing a new case where the counter should output only in high mode for the entire 100usecs duration (essentially, this is a steady 5V DC signal). My trouble is that LabView does not let me enter '0' as a value for the low time in the DAQmx CO vi.

There's got to be a way around this. What would you suggest as an effective workaround to this challenge?



0 Kudos
Message 1 of 7
Accepted by topic author ooyeniyi

Several possibilities:


1. Merely commit your CO task instead of starting it.  That'll put the output into its Idle State, which you've configured to be idle High.


2. Set the longest high time possible.  This will be more than 40 seconds using the default timebase, and by explicitly configuring to use the slower 100 kHz timebase, you could extend it to to many hours.


3. Use a DO task instead of a CO task when you have this particular situation.


4. This one isn't truly a solution, but in many cases it could be "good enough".  Set the minimum possible low time (2 cycles of the internal timebase -- so probably either 20 or 25 nanosec).   Depending what the pulse train is being connected to, it may not show any response at all to such a brief low pulse.  (A motor for example would be unlikely to show any appreciable response.)



-Kevin P

0 Kudos
Message 2 of 7

Beautiful suggestions there, Kevin.

My preference is for the first one. To be clear, by commit you mean to setup the DAQmx create virtual channel, set an output channel and trigger, but not include the Start Task DAQmx. Is that right?

0 Kudos
Message 3 of 7
Accepted by topic author ooyeniyi

"Commit" includes what you mentioned, plus one more thing.  There's a special function called DAQmx Control which you'll need to use to "commit" the task.  It's on the DAQmx sub-palette named "DAQmx Advanced Task Options".


DAQmx tasks automatically progress through a state machine before actually starting.  First the task is *verified* to make sure the device supports the config params you set up.  Then needed resources get *reserved* (preventing other tasks from trying to own control over them).  Next those resources are *committed* which brings the task right to the verge of actually running.  And finally the task starts running.


More info here.  Not mentioned there is that when a counter output task is "committed", the output pin will be driven to the configured Idle State.


(Another case where "committing" a task can help a lot is when a task needs to be started and stopped iteratively in a loop.  (For example: a finite triggered acquisition on a device that doesn't support retriggering.)   A task that's committed before being started will only revert back to committed state when stopped.  This helps reduce the overhead time used to stop and restart the task.)



-Kevin P

Message 4 of 7

Thank you Kevin. That was particularly helpful w.r.t understanding and implementing

0 Kudos
Message 5 of 7

Any ideas for releasing the task after committing it? 
Committing the task places the counter output in the idle state (i.e. steady high of 5V); even when the program is not running in LabView, I still get a sustained 5V high on the oscilloscope. I would like to programmatically terminate the committed task, but using Control Task DAQmx with action at Abort or Unreserved is not working; neither is the Stop Task nor Clear Task DAQmx tools.

0 Kudos
Message 6 of 7

Hmmm, well here's another non-obvious tidbit of info.  What you observe may be related to a board-level policy known as "lazy uncommit".    Here's one link to more info, you can probably find more now that you know what to search for.


Options for forcing the output pin back to low might include any of:

- programmatic board reset (as mentioned in the link)

- setting the terminal to Tristate condition (as mentioned in the link)

- clear the real counter task, briefly commit one with low idle state & then clear it again

- create a DO task for the port/line combo corresponding to the PFI pin in question, set the state low before clearing the DO task


None are particularly elegant, but they ought to get the job done.



-Kevin P

0 Kudos
Message 7 of 7