Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DaqMx Timing Node

Can someone point me toward a knowledge base article or other useful information on this set of properties? The help I have found within the software does not satisfy my curiosity.

 

The reason I am looking at this is out of curiousity if I can perform the following function, but even if it is not possible, I would still like to better understand the Timing property node.

 

I am curious if I can use the timing properties to replace my current operation? I wired a digital output of a 6713 card to the ai0 of a 6133 card to trigger finite acquisition. Both cards reside in a PXI chassis. I plan to add a second 6133 card that will be triggered off of the same digital output by jumpering the wire currently going from the 6713 do to 6133 ai0 over to the second 6133 ai0.

0 Kudos
Message 1 of 6
(2,552 Views)

Hello deskpilot,

 

Information about many of the DAQmx property nodes, including the DAQmx Timing node can be found here:

 

Developer Zone: Basics of NI-DAQmx Property Nodes

 

As for your particular application, I went ahead and wrote some code that should work for this situation and published it on our community site.  The diffence between this solution and the one you have described is that timing and triggering can be routed through the backplane of the PXI chassis using PXI Triggers.  In this case there is no need for any external connections between your MultifunctionDAQ boards.

 

The code can be found here:

 

NI Communities: Using PXI Triggers with Analog Input and Output

Regards,
Dan King

0 Kudos
Message 2 of 6
(2,534 Views)

Dan, thank you, that looks very cool. This is basically what I was toying around with, but decided it wouldn't work. I can't open the vi because I have 8.2, but I think I can figure it out from the screen shot.

 

Where I get confused: why is the PXI_Trig1 the onboard clock and why is Trig2 the trigger output, and what is the link to ao0? When I turn on the signal to the ao0, this is when the trigger will be exported to the Dev4 and 5? Also, do I have to share clocks between the output and acquisition cards, or can I just share triggers?  

 

If I understand the adaptation of this to what I want to use it for, I think it will go like this:

 

I will have two seperate while loops, one with finite acquisition tasks set up just like your device 4 and 5 except referencing a digital edge and finite samples on the clock. These tasks will wait for the DaqMx write (or perhaps just the start task?) in a seperate loop  inside of a case structure to be turned on when I want the trigger to be sent?

 

Finally, any particular reason for checking is task done inside of the loop?

 

Again, thank you very much, this is very helpful and looks to be a great improvement over my current setup.

0 Kudos
Message 3 of 6
(2,512 Views)

Hello deskpilot,

 

Setting PXI_Trig1 to the onboard clock and PXI_Trig2 as the start trigger is completely arbitrary.  The only thing you need to make sure of is that the PXI Triggers you export the start trigger and the clock you export are used in your other tasks as the clock source and the trigger source, respectfully.

 

The PXI Triggers are actually lines on the back plane of the PXI chassis that are common to all of the cards in the chassis.  Once you export a signal to one of these lines, it effectively shares the desired signal with all of the cards in the chassis.

 

The link to the analog output channel is that you are using the analog output task's sample clock and start to time and trigger the analog input tasks.  This will ensure that no samples are read until the generation of your analog output begins.

 

As for the need to share clocks, it is not necessary.  It is perfectly alright to only export the trigger and use different clocks for each card, or only share the clock with two of the cards and use independent clocks for the other card.  On larger systems it is possible to share multiple clocks and triggers (among other things) between different sets of cards using different trigger lines for each clock or trigger.

 

As for your specific task, with finite acquisition, the number of total samples you are planning to take, along with the rate, will somewhat determine the architecture of your application.  The main concern here being that you are not taking enough samples to overflow your buffer.  If you are taking a relatively small amount of samples (1 million or less) than I would recommend getting rid of the while loops all together and performing a single read of all of your desired samples.

 

Some things you should pay attention to in this case:

 

  1. That the timeout input of the DAQmx Read VI is at least 10% greater than your number of samples divided by the rate of your sample clock (as determined by the DAQmx Timing VI).
  2. That your number of samples per channel input on the DAQmx Read VI is specified, otherwise the VI will take all of the samples currently in the buffer, then continue, prematurely ending your program.
  3. You could also, if desired, remove the DAQmx Is Task Done VI from the analog output task.

 

Speaking of the DAQmx Is Task Done VI, you would use this VI in a continuous measurement or generation to monitor for errors.

 

I hope this answers all of the questions in your previous post.  If any of this is unclear or if you have any other questions feel free to post again and I will do my best to clear thing up.

Regards,
Dan King

Message 4 of 6
(2,475 Views)

Dan, again, great stuff. The reason for the while loops is that there is a parrallel continuous acquisition occuring through this PXI on an SCXI at the same time. My 6133's in the pxi chassis will average 1Ms/s for .5 seconds, but could go as high as 3 Ms/s for 1 second, depending on what I am sampling. The necessity for the while loop remains either way because of the simultaneous continuous acquisition at about 4 khz for up to a minute. The high speed finite occurs at about 15 seconds in to the low speed continuous.

 

I tried to replicate your code with interpretation to fit my app, and while it ran without errors, it did not trigger my finite acquisition. I am unsure of how this should work. I am exporting a start trigger from the ao card to the 6133, but what start trigger? Doesn't there have to be a trigger before I can export it? Perhaps you could save your vi to be compatible with 8.2 so that I can make sure I didn't miss something?

 

I was able to do something similar after trying your method by connecting the 20 MHz clock to the trigger channel by using Daqmx connect terminals. Since I cannot make this connection until the time that I want the trigger to be sent, I feel I am giving up some speed over your method since the connection (I assume) could be made prior to entering the loop using the export signal vi. The time delay in using the connect terminals runs 15 - 30 ms, and this may be as good as it gets since I am relying on the software to make the decision to connect. I would still like to see if there is any improvement in consistency with the export signal set up. Thanks again, this has all been very helpful.

0 Kudos
Message 5 of 6
(2,469 Views)

Hello deskpilot,

 

I went ahead and saved a different version of the vi on the Community Site that can be opened with LabVIEW 8.0 and later.

 

Here is a link to the page on our Community Site:

 

NI Communities: Using PXI Triggers with Analog Input and Output

 

The new version is the second choice in the downloads section.  Try out using this vi and come back with any questions.

 

As for there having to be a trigger to export, when you tell DAQmx to export the Start Trigger to a PXI Trigger Line you are telling the driver to send a Trigger when the task starts.  Even though there is not a trigger enumerated in the analog output task, once the DAQmx Start VI executes, a digital pulse is sent on the specified Trigger line and is read by the other tasks.  The order of execution of the tasks is very important in this case, as you want to set up the start triggers on the analog input tasks and start the analog input tasks before starting the analog output task.  This will ensure that all of the tasks will start as close to simultaneous as possible.

Regards,
Dan King

0 Kudos
Message 6 of 6
(2,449 Views)