Simulate Signal Express VI is sending two periods of the wave per loop iteration - how can I reduce this to one period?

Question

Hello,
I've been trying to use the Signal Generator Express VI and DAQ Assistant in order to generate an output waveform, as seen in this NI tutorial video:
http://www.ni.com/academic/students/learn-daq/generate/ (timestamp is at 2:07 for what I'm trying to do)
For background, I'm trying to move a piston device using Labview. The sine waveform is intended to move the piston at a smooth speed. For every loop iteration, the Simulate Signal VI running into my DAQ Assistant moves the piston to its maximum displacement and back twice. I cannot determine why this is occuring.
The settings in my "Configure Simulate Signal" tab are as follows:
Frequency: 1Hz
Phase: 90 deg
Amplitude: 2
Offset: -2
I would like my piston to only reach its maximum displacement and return for every iteration of the loop. I've tried adjusting all of the settings within "Configure Simluate Signal" but I can only work in even numbers - sending the piston back and fourth two, four, or eight times, ect.

Answer 1

The Simulate Signal VI is set for integer number of cycles and the default frequency set in the Cycles per Second control is 3.75 Hz. That results in the signal containing three complete cycles and the data array contains 8000 elements, not the nominla 10000 specified in the Express VI dialog.
If you only want one cycle, you need to specify the signal so that you only get one. Either reduce the frequency or reduce the number of samples.
As you have noticed Express VIs do one thing exceedingly well: They obscure what is going on inside.  I pulled your signal generation code out into a separate VI and then created a generator which will generate the same signal but allow you to select the number of cycles. It uses the Sine Waveform.vi from the Signal Processing  >> Waveform Generation palette.
I also recommend that you change the structure of your program. The use of sequence structures is discouraged in LabVIEW  because they defeat dataflow are very inflexible when changes need to be made. A Producer/Consumer Design Pattern plus a state machine would probably be a good choice. This will allow separation of the daq acquisition from the saving to file so that the timing of one does not constrain the timing of the other.
Setting the Analog Input Read to read multiple samples simultaneously and using the hardware timing of the data acquisiton device will get data faster and the timing will be precisely (compared to software timing) controlled by the hardware.
Writing to the same file in parallel loops probably results in some strange behavior such as differing numbers of writes from acquired data compared to generated cycles. As the file grows, the writes may slow down due to the OS needing to fragment or reallocate space for the file.
Lynn
Attachments:
Signal generator.vi ‏49 KB