help on 2 digital out signals

[cig438]

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

[TheWoost]

Hi,

I looked at your code and think I got a pretty good idea on what you're trying to accomplish.  I modified the shipping example "Multi-Function-Synch Dig Read Write With Counter.vi" to match the functionality, and have attached the modified VI.  A couple of important things to point out:  Since you mentioned using the counter0 output for your timing signal, the VI that I have provided sets up a counter task that will output the desired frequency.  Also, because both of the lines are on port0 they must be included in the same task or an error will be returned.  I have included both lines 6 and 7 in the same digital output task with a counter output frequency of 40Hz.

Why is the counter output frequency 40Hz when you want one digital line to generate at 20Hz?  Because the number of samples for each digital line must be equal, you have to modify your data to get the desired frequencies.  By writing 001100 to line 6 and 010010 to line 7 (this matches the output pattern from your VI), you are effectively generating at 20Hz on line 6 and 40Hz on line 7. 

Since you're new to DAQmx programming, I would recommend checking out the Developer Zone article for Getting Started with NI-DAQmx.

Let me know if you have any other questions.

Regards,
Andrew W
National Instruments

[cig438]

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

[cig438]

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

[Ed W]

Hi,

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

To do this, you will need to use the DAQmx Write property node, “Regeneration mode”, before starting the task.  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.

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

Continuous, Correlated Digital Output on an M-Series DAQ Device without On-Board Regeneration

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

Ed W.

Applications Engineer
National Instruments

[cig438]

Thanks - I understand the need for the "do not regenerate". I have DAQmx driver ver.8.3 & so my  minimum buffer requirements are apparently 130 samples.

Attached is an updated VI where I introduce a zero signal of size 130 (& 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 & the 3 waveforms are sent out from the 6221.
However once they are sent out, they must be in sync with each other & 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...  I want to be proven wrong 

Feel free to update my attached example !

ak

[cig438]

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 & eventually appears at the output terminals of the board.
3)  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 & 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) & modify it to include a changing 'choice'.

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

ak

[Ed W]

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.

When to Use the DAQmx Start Task and DAQmx Stop Task VIs

Using buffers does not mean that the acquisition or generation will be software timed.  In fact, most of the time, buffered generation will still be hardware timed.  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.

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

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. 

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

Are LabVIEW global variables good or bad, and when is it OK to use them?

Ed W.

Applications Engineer

National Instruments