update voltage of analog output on digital trigger

[synergymus]

I'm using a PCI-6259 to generate two analog voltage signals.  I would like to change the voltage on one channel for a user specified amount of time on response from a trigger.  In this case a01 would be set to 0V.  At trigger a01 would output voltage x for y seconds and then return to 0V.  So it is an variable length analog pulse.  So I was looking at Gen Mult Volt Updates-Int Clk-Dig Start example. If this is the best method or should I just put the normal DAQmx Write Vi a loop and change the timing using some triggered event?  I would like the pulse to be retriggable if possible.  If second method is best can you point me to some example code to get started.  Thanks

Oh yeah I'm using Labview 8.6 with NI-DAQmx 8.8

Message Edited by synergymus on 11-04-2009 03:57 PM

[RT4CY]

Hello synergymus,

Thank you for posting on the forums!  I understand you would like to use the PCI-6259 to produce two analog voltage signals based on an external trigger.  There are several different approaches we can take, I'll make one suggestion and see what you think.

If you open the Example Finder, Browse by Task to the following example:

Hardware Input and Output»DAQmx»Analog Measurements»Voltage»Acq&Graph Voltage-Int Clk-HW Trig Restarts.vi 

While this example is written for Analog Input, you can apply the same concept to an Analog Output task.  Essentially, we are committing the task, waiting on a trigger, starting the task (once a trigger is received), performing the read (in your case you will perform the write), stop the task, wait for next trigger, etc. etc.

As you said, you will have the DAQmx Write inside the loop, so you can reconfigure the data.  Note that the device will continue to output the last value that you write to it.  So just make sure that your last value is a zero, and the device will continue to output 0V until it receives the next trigger.  The duration of the "high time" is under your control.  For example, if you set the update rate to 1 Hz beforehand with the DAQmx Timing VI, each sample of your data will correspond to a length of one second.  So to generate 7V for 10 seconds, just write out an array of 11 elements (the first 10 elements will have the value of 7, the last element will have a value of 0). 

If you do implement this strategy, one thing I would suggest is to provide a dialog (maybe a sub VI) to configure the level and duration of your analog signal.  The reason I say this is because you want to make sure that on the next iteration of the while loop, you are providing new data before calling DAQmx Start.  Note that even though DAQmx Start is called, your device will not produce the signal until the trigger is received.  DAQmx Start is essentially an "arming function" which simply gets the device ready to start.  Once the trigger is received, your data will be written out.

For fast trigger rates, this may not be the best implementation.  This is due to the overhead of having to stop and restart the task.  For faster trigger rates, we may want to consider the use of counters (which are retriggerable) to produce a sample clock for the AO task.  Another approach would be to implement a Pause Trigger for the AO task.  See page 5-5 of the M Series User Manual for more information.

Finally, I would like to inform you about our new X-series boards, which support Retriggerable Analog Output operations.  With this feature, you can load waveforms into the output buffer and generate a unique waveform corresponding to each incoming trigger.  See the following article for more information.

NI-STC3 Timing and Synchronization Technology

Please let me know if I can be of further help.

[synergymus]

Rod,
 
Thanks for your reply and suggestions.  I had a family emergency I've only recently began to address this problem.   I attempted your suggestion and was able to get something which intermittently worked.  The problem was likely related to not using a subvi as you suggested.  In any case, I decided to try something a little easier first so I could have something which worked.  I created this vi (attached), which has the functionality I required but uses a manual trigger (fire button) instead of a TTL trigger.  In the final product I intend to have an option to either use TTL triggers or Manual
 
Initially I have some questions regarding this manual vi:
 
 
1. As you can see, I put the entire AO task inside an event panel.  Is this wasteful?  I would rather not create and destroy the task each time I press fire.  There will be two separate situations for repeat firing: with or without parameter changes.  The first I believe can be implemented with your previous suggestion, however, the case where the parameters change baffles me.  In particular can I change the value of DAQmx Timing's samples per channel input after I've called it or would it have to be called again?  I would appreciate some guidance with this.

2.  Each analog channel will correspond to a particle function in the application.  Instead of the user having to remember which channel goes with a particular function I would instead like to use a text ring.  The user would select the function and the program would provide the channel.  How do I create the physical channel data type to initialized DAQmx Create Channel? 
 
I had more but I can’t remember right at this moment so I’ll just leave it at that for now.  Thanks for you help.

[Brandon_B]

Hello synergymus,

You are correct that it isn't very efficient to recreate your task each time the event is triggered.  Take a look at the VI in the attached image which basically creates the task once, then just starts, waits for it to complete, and stops the task each time the event is called.  This is a much more efficient method to perform your software triggered analog output.  Also, be sure to include some timing in your loop, such as the Wait Until Next ms Multiple VI, so that your processor doesn't become bogged down with your loop running as fast as it can.

You mentioned that you would like to be able to change the rate of generation per event.  You are also correct that you cannot change the generation rate after the task has been created.  If you do wish to do this then the setup you have now is the best method because it will allow you to recreate your task each time the event is called and thus change the rate of generation.

The last part of your thread mentions that you would like to be able to change the channels associated with the task based off of a function the user selects on the front panel.  I've also included a way to do this in the attachment by using an enumerated control with a case structure.  You can then put a channel constant corresponding to each function associated with the case.  Take a look at the attached image and let me know if you have any questions.

Regards,