Avoiding Resource Reserved Error -50103 when using Independent Outputs

[Julespeak]

Hi all,

I'm currently working on a VI for performing Auger spectroscopy.  Part of the program acts as a lock-in amplifier for focusing on the the amplitude of an input waveform at a specified reference frequency and another part should act as a kind of sweep generator.  In the main execution loop of the program, I first want to set the sweep control, wait for an appropriate amount of "settling time," and then read the input waveform and perform the lock-in analysis.  At the beginning of each loop iteration, the sweep control should be incremented by a small amount.  I was able to complete a VI which performed all of these tasks successfully (with the help of a few topics I found here on the forums).

Up to that point, I had been using an external function generator to create the reference waveform, which would be read in to the program so that its frequency could be measured for the lock-in section of the VI.  In an effort to conserve ADC resources for the primary input channel, I decided to try generating the reference with the second DAC on the NI PCI-6221 that I'm using.  After creating a second output task to which I assigned the other physical output channel, I set up a waveform buffer for generating the desired sine wave, and then I promptly started running into these pesky resource errors.  I understand now that setting up the outputs in this manner will not work since the first output task created will dominate all of the resources of the DAQ; the best solution to the problem I came across on the forums was to come up with a scheme of condensing the two outputs into a single task.

The trouble with this approach is that my two outputs have very different requirements.  There is the reference signal, which should be written continuously for the duration of the VI's operation (i.e. as soon as the user specifies a frequency, this output should begin acting just like a function generator).  And then there is the sweep control, which should be re-written for every execution of the main loop with gradually increasing DC values.

Is there any way that I can configure the output task so that I can treat these two channels as if they were independent?  At this point, it is starting to seem like my best bet might be keeping the reference signal as an external input, even though this would mean sacrificing a great deal of my ADC capabilities.

-Jules

P.S. - I am not including a copy of my VI since the block diagram is cluttered with the input methods (which work just fine).  My problem can essentially be reduced to that of generating a DC signal that increments with each iteration of a loop while simultaneously generating an unbroken sine wave.

[DianeS]

You certainly can.  Look at the following picture.  The key here is "Do Not Allow Regeneration" on the analog output.  This allows you to change the output signal "on the fly".

This should get you pointed in the right direction, at least!  To generate the DC waveform, I used the square wave generator and set the duty cycle to 100%.  This just made it easy to ensure that the sampling parameters were consistent for the two channels.  There are other ways you can do it.  Hope this helps!

[Julespeak]

This example looks great, and it addresses most of the problems I was having with my own VI.

One thing I still can't seem to get down is the addition of "settling time" into the main loop.  I would like for the execution to pause (without stopping the generation of the reference signal) so that the experiment will have some time to adjust to the new sweep values before I try to measure my input.  I tried adding a Wait Until Next ms Multiple block into the loop in your VI, but when I set it to anything other than 1 ms, the program stops working right.

Thanks so much for your help,

Jules

[DianeS]

Let the analog generation rate and the number of samples per generation set your loop timing.  Don't add any additional wait functions.  Doing so will goof up your analog generation.

The way the code in the picture is set up, the loop will iterate every second.  This is because I set the clock sample rate to 1kHz, and set the waveform generation number of samples to 1000.  It takes 1 second to generate 1000 samples, therefore that's the amount of time it will take the loop to execute.  Because the generation is performed in hardware, the analog generation is still continuous.

If you want your loop to take longer to execute, adjust those numbers.  For instance, when you generate your waveform, if you set the number of samples to 2000 and leave everything else the same, the loop will take 2 seconds to execute.  If you were to set the number of samples to 500 and leave everything else the same, the loop would iterate every 0.5 seconds.

Does that make sense?

Also, be more specific than "the program stops working right".  That tells me absolutely nothing.  What, specifically, no longer works correctly?

I've attached an example, which is basically the same thing I showed earlier, except that I've added some code that calculates the loop iteration time, so you can see for yourself how changing the number of samples in your waveform affects your loop speed.

One other thing to keep in mind that's very important:  if you have other code in your loop which takes longer to run than your analog generation, you are going to run into problems with your analog generation.  The loop won't iterate until everything inside it has finished executing.  If your analog generation takes 1 second, but you have another subVI which takes 2 seconds to execute, your loop will take 2 seconds to execute, leading to analog generation buffering errors.

You only want a single timing source in your loop.  When you're doing hardware-timed analog generation or acquisition, that should be your timing source.  Does that make sense?  From your original description, it sounds like you might want to consider a different architecture, something more like a producer/consumer.  If your analog generation needs to be continuous, you probably want it in a separate loop.  You can use queues and notifiers to communicate between loops.