VeriStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Running DAQmx waveform in Veristand

Hi, I'm fairly new to Veristand and am trying to work out the limitations and what is/isn't possible.


We are running a split windows/RT system using hypervisor and the main focus of our VS use will be the stimulus profile editor to perform timing critical testing, other testing will be done using conventional teststand.

 

We have a NI 6733 AO card used for waveform generation (100 - 20kHz). I have already written a driver for the card for LabVIEW RT and windows etc and all works well. Is it possible to control this card within veristand to generate tones and play these back continuously with realtime control of amplitude, frequency etc?

 

I have written a custom model for our DIO card (6528) using DAQmx and the custom model wizard and this works OK so understand some of the basics as to how to work with DAQmx and models. However, I am unable to understand how to incorporate the AO card in the system given that it has an internal buffer from which it replays the data. In a traditional driver so long as the DAQ task is not stopped or closed the waveform generation continues, but in Veristand the model is continuously called so how would this work? One way would be to have the main execution loop simply run the model for a time period matched to the frequency of the waveform and the model control loop rate, but then how would you be able to change the frequency. Another way would be to have the Veristand model run similar to the RT control of this (ie a continuously running loop) but I don't think this is the correct approach and when I've played with this it leads to the RT hanging after the model is deployed - I'm guessing that the model is waiting to complete before returning. So I've gone full circle on this a few times now and would appreciate any ideas or suggestions on this.
Thanks

 

0 Kudos
Message 1 of 8
(8,671 Views)

Hi F7ash,

 

Thanks for your post. Sorry that this response has come so late!

 

You are right that the internal buffer can cause problems with data transfer. Veristand does not currently support waveform acquisition/generation as only static DIO is supported. They also suggest that the hardware you use supports hardware-timed single point sampling, which yours doesn't. 

 

You can find this information here

 

If you require more information please ask.

 

Many thanks,

Eden S
Applications Engineer
National Instruments UK & Ireland
0 Kudos
Message 2 of 8
(8,613 Views)

Hi F7ash,

 

Although using models is one way to get custom LabVIEW code into NI VeriStand, it is not the only (or usually recommended) way.

 

In this case, you would have much more flexibility putting your code into a custom device.  Custom devices are plugins that you can write to execute custom code in the NI VeriStand engine.  Unlike models, you have a lot more control over how and when the code executes.

 

To get started, it's probably best to take a look at the Easy Custom Device Tool.  This tool should allow you to write your AO code without requiring you to understand all of the details of the custom device framework.  If you wish to learn more about custom devices, there is a wealth of information available online in the Custom Device Developer's Guide.  Although, learning all of these details should not be necessary right now if you just use the tool above.

Message 3 of 8
(8,603 Views)
Thanks for the replies. I figured the custom device route was the way to go and already have developed one custom DAQ device using the custom toolset. Even using this approach I wasn't sure on the best approach to take- again linked to the buffer issue. Have you had any experience of this? Can I have a continually running loop in the custom driver?
0 Kudos
Message 4 of 8
(8,592 Views)

So I assume what you're trying to do is similar to the "Cont Gen Voltage Wfm-Int Clk.vi" example (from LabVIEW's example finder), where you write a waveform to the task, start it, and then let it continuously generate:

 

AO Example.png

 

Your specific implementation would be a little different than the above example, since you want the ability to change amplitude or frequency, and set a new waveform to be generating.  To do this, you would stop the task, write a new waveform, then start the task again.  Is this correct?

 

Read over the documents included in the Easy Custom Device .zip to get an understand of how to use the tool.  In order to make your AO custom device with the tool, you would do something similar to the following:

 

Configuration Data: This would include any settings that you may want to make in System Explorer, but that don't need to be changed at runtime.  This could include Physical Channels, Min/Max Values, Samples Per Buffer, Cycles per Buffer, etc...  These settings will show up on the main page of your custom device.

 

Channel Data: These are things that the user reads or writes at runtime.  In your case, you might have two Input Channels (Amplitude and Desired Frequency), and one Output Channel (Resulting Frequency).

 

Real Time System Data: This is data you pass between states of your code.  In your case, I think this would just be the Task Refnum.

 

Init VI:  In this VI you would create the task, generate the waveform (based on the default values for the freqency and amplitude channels), set the task timing, and write the waveform to the task (the first 4 VIs in the above example).  The created task would be stored in the Real Time System Data cluster, and the Actual Frequency would be written to your output channel.

 

Start VI: This VI would call "Start Task" to begin generation of the initial waveform.

 

Execute VI:  This is the VI that gets called repeatedly while NI VeriStand is running.  This will be an asynchronous custom device, so the code won't actually run inside of the main VeriStand loop (and therefor you won't block execution if your code runs late).  However, the main loop will communicate the channel data to your code every iteration, allowing you to respond to user input.  Inside of this VI you will first check if the Amplitude and Desired frequency are the same as the previous iteration.  If they are, this means that the user hasn't changed any inputs, and you should keep generating the existing waveform.  So if the channels haven't changed, don't do anything else in this VI.  This is similiar to the "Add" custom device example described in the "Example Walkthrough.docx" which is included with the custom device tool, where the file is only written to if one of the user inputs has changed.

 

If either of the channels has changed, this means that the user is requesting a new waveform to be generated.  In this instance you would stop the task, regenerate the waveform, set the sample clock, write the waveform, and start the task again.  This is basically the same as doing both the "Init VI" and the "Start VI" from above (except you don't need to create the task again).


Stop VI: This executes when the system is shutting down, so in this VI all you need to do is clear the task.

 

 

Hopefully that helps give you an idea of how to get started with your custom device.  You might need to make some changes from what I described above, but it should be a good starting point.  Hopefully it can help you adapt your existing code into the custom device template.

 

Message 5 of 8
(8,584 Views)

In regards to your question about having a continually running loop in a custom device, the general answer is yes.  Anything which you can do in LabVIEW you can do in a custom device.

 

However, the Easy Custom Device Tool is written in such a way that there is already a loop which calls your "Execute VI" in time with the main NI VeriStand loop (or at a decimation of it).  So, it would not be a good idea to put a continually running loop inside of the Execute VI of the Easy Custom Device tool.  Instead you would need to follow an approach  like the one I descrbed in my above post.

 

If you wanted to have more control of the execution of your custom device, you could develop one from scratch and use the techcniques mentioned in the developers guide I linked in my first post.  However, this would be a lot more work and has a big learning curve, so for now I'd recommend sticking with the Easy Custom Device Tool.

0 Kudos
Message 6 of 8
(8,583 Views)

Hi Devin,

 

Thanks for the excellent post - very helpful. Sounds as if I was going along the correct lines with what I was doing and your post has confirmed it. I was starting to get quite frustrated having learnt a lot of what can't be done the hardway despite having read the documentation (of which there's is little) so decided to post to check here, regroup and work on something else. I'll be back on this next week and hopefully will have this up and running shortly.
Many thanks agian..

Henry

0 Kudos
Message 7 of 8
(8,577 Views)

You're very welcome!  Keep us updated on your progress and let us know if you run into any problems.  Good luck!

0 Kudos
Message 8 of 8
(8,572 Views)