Discussion:
help on 2 digital out signals
(too old to reply)
cig438
2007-03-22 22:40:08 UTC
Permalink
I have the 6221 card & need to output 2 signals that are in synch with each other. I need hardware-timed operation.
Attached is a vi which is based off of the NI example : Write Dig Chan - Ext Clk.vi
Basically I use PFI12 terminal which is the counter0 output for this
card to create the timing for the 2 digital signals that I need to
output : SCLOCK & SDATA.
Running this VI gives me error 200462 @ Start Task for the clock task :
generation can't be started because output buffer is empty.

Can someone explain why I get this error ?
I'm new to DAQmx & have been trying different methods & looking
at different examples to output 2 signals in synch with each other - if
know of a simple way of doing this, I would appreciate it.
There's so many variations I don't know which way to turn.

Any advice would be greatly appreciated,
ak


3 series D.vi:
http://forums.ni.com/attachments/ni/70/6584/1/3 series D.vi
cig438
2007-03-23 23:10:10 UTC
Permalink
Yes thanks - that seems to be the only way to do it if I have to have the same rate for all channels.

Attached is version A which works !!

I'd like to make one change : let the user vary the 'choice' variable
on the front panel & have the vi respond by sending out the updated
waveforms. My attempt at this is version B.
So I place everything inside a while loop & get an error telling me
that I basically I can't perform a write while the previous task hasn't
finished.
I changed the sampling to finite & 42 samples per channel (the
length of the waveform I'm sending out). I also observed the Boolean
output of the Is Task Done vi & it outputs a true, yet I get the
error. I'm not sure why.

I've also tried placing the Clear Task vi inside the while loop but I believe I got the same error.
I think I just need to give the current task time to finish & based
on that thumbs up, proceed to update the waveforms that will be loaded
into Write.vi.
I'm having trouble with it though --

ak


Dig Write Sync Counter -A.vi:
http://forums.ni.com/attachments/ni/70/6589/1/Dig Write Sync Counter -A.vi


Dig Write Sync Counter -B.vi:
http://forums.ni.com/attachments/ni/70/6589/2/Dig Write Sync Counter -B.vi
cig438
2007-03-26 22:10:11 UTC
Permalink
Still having problems with this.
Here's a very similar vi with everything inside the while loop.
When I highlight execution, it works ! But when I run the vi normally
it just sits there - I've never seen this before. Is there some timing
issue going on that creates this discrepancy ?

ak


Dig Write Sync Counter -C.vi:
http://forums.ni.com/attachments/ni/70/6592/1/Dig Write Sync Counter -C.vi
Ed W
2007-03-28 15:40:17 UTC
Permalink
Hi,

 

The DAQmx Write function writes data to the device?s buffer.  Although the data must be written to RAM first, it is then transferred to the device?s buffer. 

 

The functionality of the Start Task (and Stop Task) is described in the following Knowledge Base entry.

 

<a href="http://digital.ni.com/public.nsf/websearch/0622DCB1E143EB7F86256D270078B07F?OpenDocument" target="_blank"> When to Use the DAQmx Start Task and DAQmx Stop Task VIs</a>

&nbsp;

Using buffers does not mean that the acquisition or generation will be software timed.&nbsp; In fact, most of the time, buffered generation will still be hardware timed.&nbsp; However, the use of buffers may increase the latency of the generation, meaning the period between when the data is initially written to the buffer and then out of the device.

&nbsp;

The property node refers to the amount of space left in the device?s onboard buffer.&nbsp; Because data is being constantly output at relatively high speeds, the amount of space is constantly changing.

&nbsp;

Otherwise, because your VI is relatively large, I would recommend getting the example VI attached to the previous post?s KB entry to work, and then apply those changes to your VI.&nbsp;

&nbsp;

Also, I would recommend cutting down on your use of local variables (or even better, completely removing all of them).&nbsp; You actually don?t need any of them to achieve the same functionality as your current program.&nbsp; Local variables (as well as global variables, shared variables, etc.) do not obey LabVIEW?s dataflow paradigm, and they can lead to race conditions.&nbsp; There is a nice Developer?s Zone article about the caveats of variables.

&nbsp;

<a href="http://zone.ni.com/devzone/cda/tut/p/id/5317" target="_blank"> Are LabVIEW global variables good or bad, and when is it OK to use them?</a>

&nbsp;

Ed W.

Applications Engineer

National Instruments

Ed W
2007-03-27 00:40:08 UTC
Permalink
Hi,

&nbsp;

Typically, when performing digital generation, there is an onboard buffer that holds the samples to be generated each iteration.&nbsp; When you setup the task, this buffer is filled, and regenerated during each output.&nbsp; However, since you want the data to possibly change during each iteration, you will need to turn regeneration off.&nbsp; By doing this, you will be writing to the buffer each iteration ? this will end up slowing down the output.

&nbsp;

To do this, you will need to use the DAQmx Write property node, ?Regeneration mode?, before starting the task.&nbsp; Wire a constant value of ?Do Not All Regeneration? to this property, and DAQmx will know to rewrite the buffer during each iteration of the while loop.

&nbsp;

There is a Knowledge Base article that includes an example program, demonstrating this exact functionality.&nbsp;

&nbsp;

<a href="http://digital.ni.com/public.nsf/websearch/7E2B7CFA5F440AB68625706200567EE3?OpenDocument" target="_blank"> Continuous, Correlated Digital Output on an M-Series DAQ Device without On-Board Regeneration</a>

&nbsp;

I hope this helps.&nbsp; Please post back if you have further questions.

&nbsp;

Ed W.

Applications EngineerNational Instruments
cig438
2007-03-27 15:10:12 UTC
Permalink
Thanks - I understand the need for the "do not regenerate". I have
DAQmx driver ver.8.3 &amp; so my&nbsp; minimum buffer requirements are
apparently 130 samples.

Attached is an updated VI where I introduce a zero signal of size 130
(&amp; thereby create the buffer ?). I get error 200292 @ Write :
some/all samples couldn't get written to buffer yet.
Increasing the rate or the write timeout didn't avoid the error - it
appeared a bit later anyhow. I do not want to have to increase the
sample rate if at all possible !

Please help me understand what's going on. For my app, it's OK if
there's a delay between when the user selects a new choice &amp; the 3
waveforms are sent out from the 6221.
However once they are sent out, they must be in sync with each other &amp; at the rate specified.
Also my preference would be to set the buffer some other way besides initially writing a set of zeroes to the 6221.

I'm worried that what can be accomplished straightforwardly with a
micro-controller may become unwieldy using the 6221...&nbsp; I want to
be proven wrong&nbsp; :smileyindifferent:

Feel free to update my attached example !

ak


Dig Write Sync Counter -D.vi:
http://forums.ni.com/attachments/ni/70/6594/1/Dig Write Sync Counter -D.vi
cig438
2007-03-27 21:40:16 UTC
Permalink
Based on what I've read online, here's my assumptions :

1) the DAQmx Write functions writes data to the buffer. Under default
conditions, the buffer refers to the computer RAM, as opposed to the
onboard RAM of the 6221.
2) the DAQMx Start Task function sends the data from the buffer into
the 6221 onboard RAM where it gets conditioned appropriately &amp;
eventually appears at the output terminals of the board.
3)&nbsp; whenever buffers are used, it is no longer a hardware-timed operation
4) the Space Avail property of the Write Property node refers to the
samples per channel space available in the computer RAM buffer not the
6221 buffer

Please let me know if my assumtions are incorrect.

Attached is an updated vi where I allow access to several property
nodes. I get error 200288 : attempted to write sample beyond the sample
generated. I guess that means I'm trying to write into a slot in the
computer RAM allocated buffer that is not available. I notice the Space
Avail flying down to zero &amp; then I get the error. If I can get the
write operation to overwrite the previous 42 samples in the buffer, I
think this could work !

As a reminder, all I really want to do is to take the version A vi (see
earlier post) &amp; modify it to include a changing 'choice'.

Still looking for a solution - any help would be greatly appreciated !

ak


Dig Write Sync Counter -E.vi:
http://forums.ni.com/attachments/ni/70/6598/1/Dig Write Sync Counter -E.vi
Loading...