DC motor - constant speed

[jgarcia]

I 'm a light user of Labview and need some assistance.

My objective is to make the dc motor retain constant speed even when a load is applied.

The tools I have to acquire data with are:

NI USB-6211

Labview 8.2

Optical Encoder - 1000 pulses per revolution

My main concern is writing the PWM VI to do this.

My first guess is to set use a DAQ assistance to acquire a signal as a counter input from the encoder.

Not really sure what to do with that because I am kinda lost from there.

How would I use that info to adjust the PWM of the output signal?

All help is appreciated. 

[Jochen]

Hi jgarcia,

this doesn't work at all. Your application requires closed loop control. This means you need deterministic behavior (= stable timing of the control loop) for single point I/O operations. With your setup this is not possible due to the fact, that both the USB and Windows introduce a lot of jitter (using a PCI DAQ device would make things a bit better, but you still couldn't get reliable control behavior on a Windows operating system). For a control system reliable timing is at least as important as proper tuning of the control parameters.

For motion control tasks it's much better to use a device like the PCI-7342, that runs all control operations in a realtime environment onboard. Other options include using a realtime operating system and PCI or PXI DAQ hardware or a cRIO-System with drive interface modules. For a single-axis system, the PCI-7342 is probably the most cost-efficient solution.

Sorry for the negative answer, but with your current hard- and software setup you will could easily waste a lot of time on a poor solution.

Kind regards,

Jochen Klier

National Instruments

[Brian_Beal]

You failed to mention one important piece of hardware, the drive. What are you planning to use?  Although PWM generation for motor control really needs to be done with a real-time system, as Jochen has pointed out,  PID control can be done with acceptable results for non demanding applications under a Windows environment.  If you have an off-the-shelf DC motor controller that takes an analog signal for speed, then you might be able to use your existing components.  Although  most DC drives are open loop and give OK speed control, a closed loop system it required to truly keep a set speed.

Message Edited by Brian Beal on 11-02-2009 06:14 AM

[Jochen]

Hi Brian,

my rigid statement about the impracticality of Windows for closed loop control applications is based on two reasons:

1. Depending on the application type non-deterministic behavior for control applications can cause hazardeous situations or damage to the machine. Even if Windows might provide acceptable control performance for some non-critical applications, I never would recommend this for any application where I don't know all circumstances exactly.
   
2. In the original post there is a statement about changing loads which implies aggravated circumstances for this application that typically requires a fast and stable control loop.

Additionally USB is really a worst case scenario for point by point applications. That's why NI doesn't support any USB DAQ devices under LabVIEW Realtime, but this issue is independant from Windows.

Jochen

[Brian_Beal]

Hi Jochen-

Yes, I agree with what you say.  For process critical or safety applications, Windows is not a good choice.  For lab or experimental, it might work.  For industrial applications, my philosophy has always been to have the process control in discrete controllers, and have a Windows/Labview interface for DAQ, recipes, etc.  A stripped down(no Office or add-ons) version of XP is remarkably stable, but still not deterministic.

Brian

[jgarcia]

The purpose of my setup is just strictly to perform a lab experiment.

It does not need to be a fantastic setup or highly efficient.

It just has to adjust itself when there is a load.

The DC motor I'm using is just a cheap off the shelf motor.

From the posts already, it seems I do not have the optimum equipment to do this experiment.
The question I have is, can it be done with the equipment I have? Even if it may not work that well.

Message Edited by jgarcia on 11-02-2009 12:48 PM

[Brian_Beal]

You cannot drive a motor from a DAQ card directly.  You need an amplifier.  What motor are you using?

[jgarcia]

My dc motor is a Pacific Scientific 2VM61-000-2.

Here are few specs on it.

http://www.pacsci.com/support/low_inertia_pmdc/lowinertia2vmsupport.html

I am using it in conjuction with a mosfet driver connected to 24 VDC.

[Joey9310]

Hello, I'm currently working on a project like this (using the USB 6211) and I am running into a similar issue. I understand that this may not be the best solution since I'm working in a windows environment, but this is only for experimental purposes in a educational environment, and I'm on a limited budget. I've connected the shafts of 2 dc motors together. I power one motor, and use the other motor as a tachometer (it generates a dc voltage directly proportional to speed). I've created a analog channel to measure the tachometer voltage and created a calibration graph using a non-contacting tachometer by taking various data points at different input voltages. I can determine the speed of the motor efficiently, but I'm having a issue using PWM. Is there possibly another way to vary the voltage to the dc motor thus controlling the speed? I was thinking maybe having some way to compare the actual speed and the set speed of the motor, then depending whether it is positive or negative labview either increases or decreases the voltage.

[Matt-J]

Hi Joey9310,

Are you using an amplifier in conjunction with your DAQ device? Typically, a motor drive would be used as an intermediary, so it may be difficult to get working with your configuration. As for the logic part, you could certainly use LabVIEW's build in mathematics functions to compare the set speed and read speed. If you are continuously acquiring data, you could perform said logic, then store the new "set speed" value in a shift register, which would then be used in the next input/output iteration. I hope this information is helpful.

Best regards,