Recently I used labview to control the velocity of a stepper motor. I had timed loop running off the 1kHz clock. Also in the VI (but not within the timed loop), I had a control and simulation loop, with a period of 5ms that read the encoder count from the stepper motor and displayed the position and velocity of the motor (velocity through a derivative and filtering). The timed loop included a square wave VI to control the input frequency to the motor. The data was sent to the DAQ with (sample on demand). However, at some inputted frequencies (400 deg/s or 222Hz), the motor seemed to be beyond its pull-in frequency or at its resonance frequency. Yet, when I connected a function generator to the motor, the motor ran MUCH smoother (no griding noises), ran at 222Hz, and even beyond up to 1600Hz!! Much larger than with Labview. I understand that I cannot exceed 500Hz (nyquist rate) in labview. Initially, I suspected the timed loop was finishing late, and it was (very seldomly). I simplified things and the timed loop doesnt seem to finish late, yet I still see this same behavior- controlled through labview, the motor has a dead band at about 222Hz but works again at 300Hz. I'm relatively new to labview- is there anything I could be doing wrong or is the timing of the sent signals not perfectly correct? Now that I've typed this I realized I should check the labview output with an o-scope. I didn't think posting my code would be needed for this issue, but if so, I can definitely post it.
Solved! Go to Solution.
Is your LabVIEW code running on a Windows operating system, or is it on a real-time target? What DAQ device are you using?
Windows has no guarantees on timing execution, even for timed while loops, and while it can run really fast, doing software timed output with the sample on setting is not going to work well.
Try outputing your square wave using hardware timed DAQ commands where you write the entire square waveform and us continuous sampling or N samples.
You should definitely use the hardware timing available in your DAQ board.
It doesn't sound like you've taken into account the further limitations of using a 1 kHz resolution software clock. There are very few discrete frequencies you can even *theoretically* hit. All *attempted* intervals would need to be an integer multiple of the 1 msec resolution. So you can only hope to try to hit 2 msec (500 Hz), 3 msec (333.33 Hz), 4 msec (250 Hz), 5 msec (200 Hz), etc. Not sure how you were trying to hit 222 Hz, but I promise you weren't achieving it consistently.
Thanks for your reply. I really appreciate the insight. So with hardware timing would I be able to only achieve integer multiples as well?
Hardware timing should allow you to acheive about any frequency the device allows since you will be controlling it by frequency rather than by an integer value of milliseconds.