Pausing a write operation on DAQmx

[LionelMRI]

Hi all,

I am using a DAQmx with cards NI9402 and 9264 to control current amplifiers for an MRI system. I am planning to do that by using a waveform array triggered on channel 3 of the NI9402 (high-speed digital input).

The difficult part is that I need to pause the write operation after a given number of points have been written until the digital signal goes back to zero, at which point the rest of the buffer can be written.

I am not happy with my current solution as it looks ugly and is rather slow. There is a minimum delay of 70 ms between the two writes operations, which is not acceptable. I need a minimum wait time of 10 ms.

I am not familiar with Labview but I think that there may be a way to use the clock signal to do this? Unless someone can see a better way to proceed?

All the best,

Lionel

[VoltronP]

Hello Lionel,

I suggest you look into using a simple state machine architecture combined with software timing. You would do your initial set up outside of the loop of the state machine and then have a few state to cycle through inside the actual architecture. The states will be something along the lines of:

1. Send all samples – 1000
2. Software timed wait until done
3. Send all remaining samples
4. Software timed wait until done

You can always combine the send samples and wait functions into one state and add a trigger between the states.

You can find examples on how a simple state machine architecture works in LabVIEW under Help >> Find Examples…  then search for State Machine Fundamentals.vi This example will show you how to implement a simple state machine.

As for software timed acquisition you can once again go to Help >> Find Examples… then search for Voltage On Demand Output. This VI will give you an example of software timing.

Regards,

Viktor

[cody_a]

Is the width of the digital signal coming in on channel 3 of your 9402 known prior to run-time?  Does it vary over time or is it constant?  Is the 10 ms "wait time" you mentioned the maximum acceptable latency from the time the pulse goes low to when the next write operation occurs?

It might be possible to do this with some hardware signals, but it is very likely going to require software interaction.  Would you at all consider changing hardware?  Doing this on FPGA would be pretty simple and give you much better performance.

[cody_a · Accepted solution]

Hey Lionel,

I thought of a way to do this entirely in hardware.  You'll need two of the cDAQ chassis's onboard counters, all 4 channels of your 9402, and some external wiring (including a BNC T to get it working though).  I briefly verified that this method works, but I probably haven't thought through every possible corner case.  My code works as follows:

1. Set up a finite counter output to generate N samples, where N is the number of samples to generate after the initial rising edge of the trigger signal.  Output this pulse train on 9402 channel 0 (PFI 0).  This task should use the rising edge of 9402 channel 3 (PFI 3) as a start trigger.
2. Set up a different finite counter output to generate M samples, where M is the number of samples to generate after the trigger signal goes back low (or total samples minus N).  Output this pulse train on 9402 channel 1 (PFI 1).  This task should use the falling edge of 9402 channel 3 (PFI 3) as a start trigger.
3. Using a BNC T, combine the PFI 0 and PFI 1 outputs then wire them to 9402 channel 2 (PFI 2).
4. For your analog output task, use a finite output task set to generate N + M samples with the sample clock source set to PFI2.

I tested this with a PXIe-6363 set to output a 4000 point sinewave at 1MS/s output rate.  With N set to 2567 and M set to 1433, I got the following output.  I can change the N and M values and it still works well.

I would post my code, but honestly I just made a couple quick modifications to the Voltage - Finite Output and Counter - Finite Output shipping examples (under DAQmx in the Example Finder), so I'm not sure how much value it would add.  Let me know if you have questions though, or if this approach is not feasible for some reason.

[LionelMRI]

Thanks for the answers!

To VoltronP, I did try your software-based solution but that generates poorly reproducible delays in the execution of the code, which messes up with the synchronisation. I measured variations of up to 5 ms in the execution delay, which is 3 orders of magnitude too high for my use.

However, the software-based solution is very nice! I think this should solve the problem nicely, and it is not even difficult to implement and to code. Thanks a lot to Cody A for helping!

Lionel