LabVIEW code review, is user error making this code slow?

[tareyes]

Hello, I have a simple program that is sending a single pulse out of a DT9834 DAC device.

The only code beyond the VIs that pass commands to the DAC is to build an array that has the following features:

• The total number of samples in the array can be specified. (By default this will be 120000)
• The position in the array can be specified. (By default this will be at 0.15, or sample 18000)
• The Voltage value can be controlled. (By default this will be 2 to represent 2V)
• The total number of samples with a voltage value starting from the position in array specified can be controlled (By default this is 25)
• The number of iterations can be controlled. (By default this will be 0, to represent one single pulse)

This seems like a simple program that would not lag at execution. However, if I attempt to run continuously it will lag, waiting an indeterminate amount of time in between each pulse. It is being output at a sample rate of 500kHz.

This is an issue because when trying to collect this pulse on my DAS (SlicePro SIM), it is not triggering properly. 

My output pulse variability, with all the controls such as voltage, total samples, etc., is not really necessary. I can change these values to a static 120k samples, starting at 18k, for 25 samples of 2V, the remaining samples being 0. But does this really matter? Is my loop that is building an array effecting my program running smoothly?

Would it be a more efficient program if I went the route of making a .csv file and reading from that, or some other method of building this array of samples to provide to the write command of the DAC VI?

Thank you for any help on the matter, below is my VI:

[GerdW]

Hi tareyes,

---

@tareyes wrote:

This seems like a simple program that would not lag at execution. However, if I attempt to run continuously it will lag, waiting an indeterminate amount of time in between each pulse. It is being output at a sample rate of 500kHz.

My output pulse variability, with all the controls such as voltage, total samples, etc., is not really necessary. I can change these values to a static 120k samples, starting at 18k, for 25 samples of 2V, the remaining samples being 0. But does this really matter? Is my loop that is building an array effecting my program running smoothly?

Would it be a more efficient program if I went the route of making a .csv file and reading from that, or some other method of building this array of samples to provide to the write command of the DAC VI?

---

• Why are there orange controls to define an integer number of loop iterations???
• Why do you create 2D arrays when you need a 1D array at the end???
• Why don't you use InitArray instead of those loops???
• Why do you need to initialize and kill the DAQ task in each iteration???
• Why do you need two indicators for the same 1D array???
• Why is there a While loop when you know the max number of iterations before starting the loop? (Atleast you should know that although you could change the "Number of pulses" while the loop is iterating…)

---

@tareyes wrote:

Thank you for any help on the matter, below is my VI

---

No, there is no VI.

Just an image of a block diagram. We cannot edit/debug/run images in LabVIEW!

See this image of a VI:

Do you see the simplifications?

[tareyes]

Hello GerdW, thank you for your response and help on the matter.

To answer the orange controls, I made a quick change in the VI to convert to I32.

For the 2D array, I was unaware there was a smoother method to build an array to provide to the write command.

I did not know that InitArray was capable of building the customizable array I was looking for, however now that most of my testing for what kind of waveform I need is done, it doesn't need to be as customizable anyway but figured it wasn't effecting it much.

the DAQ needs to be initialized and killed for each iteration because due to the timing controls on the DAQ, the only options are "finite" and "continuous". If ran continuously, I do not know how to limit the number of pulses it will send. Possibly by putting an overall timing for the program to execute? But wouldn't that still require a loop?

the two indicators for the same 1D array was only for diagnostic purposes while I was attempting to build the waveform I needed.

I have properly attached the VI this time, my apologies for the oversight. the VI labeled with "18.0" was "saved for previous version"

Overall I am pretty inexperienced working with LabVIEW, but have been rapidly trying to acquire more knowledge as I am using it to develop some testing systems. 

Thank you for the further assistance.

[GerdW]

Hi tareyes,

---

@tareyes wrote:

the DAQ needs to be initialized and killed for each iteration because due to the timing controls on the DAQ, the only options are "finite" and "continuous". If ran continuously, I do not know how to limit the number of pulses it will send. Possibly by putting an overall timing for the program to execute? But wouldn't that still require a loop?

---

• When the sample rate is fixed at 500kS/s then you don't need to set the timing again.
• With DAQmx you typically write the output buffer before starting the task: does the DataX device really require to start the task before writing the output data?
• When the task is "finite" then it should output just your data. In the next iteration you "just" need to provide a new waveform and "run" again - that's how DAQmx would work…
• Do you really need to change sample rate, number of pulses, pulse duration while the loop is iteration or are these values fixed for a "test run"?

[tareyes]

Hi Gerdw,

The sample rate, and all other values for the construction of the waveform would be fixed for the test run. Should I try putting these VIs outside of the loop? I will experiment with that.

The DataX device does not require the task to be started before the write command, it only requires that a start command is provided if a buffer is being used. I will also experiment with the positioning of this command.

My lack of knowledge on the use of LabVIEW is on full display, I did not consider that some of these VIs only needs to pass arguments a single time. This is probably an issue with other VIs I have attempted to build as well.

I can see the clear implications of this, as the VI is passing this data to the DAC through USB 2.0, which is going to add a delay with each iteration. 

Thank you for your continued support, it is greatly appreciated.

[Bob_Schor]

Are you trying to output a periodic signal, or one without obvious periodicity (such as random noise)?  For a periodic signal, you basically create a buffer having one (or more) periods of your signal, load it into the DAC, and then run it in "continuous sampling" mode, stopping when you want the signal to stop (see the LabVIEW Example, Voltage - Function Generator).  [Note that the data sheet for the DT9834 mentions the D/A as "Optional 16-bit deglitched D/A: 500 kS/s/ch for
waveform generation", suggesting that this fast sampling is designed for "continuous sampling" and function generation].

The idea here is that you load up "memory" in the DAC device with the waveform you want to generate, set sampling to Continuous, and start the DAC.  It will output the waveform in its memory over and over and over until you tell it to stop (the Example shows just this happening).

Is this what you want to do?  If so, let the Example be your guide.  [Hint -- once you open the Example, save it to your Desktop or Your Documents (as opposed to "my" Documents) and edit it as appropriate (for goodness sake, change the Icon!).

Bob Schor