USB 6211: Drive two stepper motors from Analog Output

[tony78]

Dear all:

I am trying to control two different stepper motors from a NIDaq 6211 using the analog outputs. See attached a very much simplified version of the code.

Here more details about my wiring and setup.

- both motors are powered and controlled from their own supplies and motor controllers. All I have to do is input a square wave of appropriate frequency into each of the controllers.

- Motor 1, STP+ is wired to AO0, Motor 2, STP+ is wired to AO1, both STP- are wired to AOGnd.

- I am trying to run a 50Hz loop in which the required driving frequency for each motor is computed and updated.

The problem now:

If I configure the software just for one motor, say Motor 1, I select as my output channel AO0, and everything works fine. If I configure the software for Motor 2 and switch the output to AO1, it also works. However, if I want to drive both together, the second motor just twitches.

Any suggestions where my thinking is wrong?

Thanks in advance,

Tony

[tony78]

... and here with the promised attachment.

[margasan]

Hello tony,

I would use the board´s counters instead of the AO, as the counters are designed to output square wave ( TTL), and very easy to change the output frequency on the fly, if this does not work for you , I would stop using the express VI ( signal generator , daq assistance) and try to use the daqmx API.

Rergards

Mart G

[SnowMule]

Are you going through some sort of driver board?  Steppers themselves need more than one power/signal wire. 

Problem is that the M-series DAQs can only do one thing at a time.  A task can be configured to contain multiple channels, but you can't build/output waveforms for multiple channels like you describe with these devices (that i'm aware of, anyways).

Using the M-series USB DAQs and analog outputs, you'll need more than one DAQ. 

[tony78]

Gents,

thanks for your answers. Unfortunately, I have to say that LabView is and will remain exactly what it's name says: Good for "viewing" stuff at the "lab". Here is why.

Our system:

- one optical quadrature encoder with 200ppr.

- two stepper motors that are driven with varying frequency, depending on the encoder rotational velocity

- the two steppers are powered independently, and each has it's own dedicated driver. We simply supply a squarewave of the appropriate frequency to the input port of the driver hardware(s).

Does not sound very difficult, no?

We thought: Hey, Labview let's you program everything using neat little boxes and wires, let's give that a try for once. I have been messing with getting this stuff to work for almost two weeks (very little Labview experience outside of engineering school to that point). After fighting my way through the tutorials I was finally able to read the quadrature encoder and connecting and controlling one stepper worked quite ok. However, I noticed a huge delay between the encoder signal and the motor reaction. Once I started thinking about controlling two motors things went down hill.

Let's face it: LabView is a load of crock for anything beyond simple data acquisition.

Here is my status today:

I heard about Arduino the first time this past Friday and immediately ordered an Arduino UNO with a Data Recording shield (which comes in components and you're required to solder it up). I received the package yesterday morning, downloaded the development interface and started playing with it. About 30 minutes ago, I completed the first closed-loop full functional system test: I read the encoder at 50Hz, compute a rotational velocity, and calculate the frequency required on the two motors. I output these two signals on two separate pins and feed them into the stepper drivers. Assynchronous timer interrupts take care of my continuous line toggling at the appropriate frequency. My code is a whopping 3884 bytes huge. And guess what: no inexplicable delay between encoder reading and frequency output.

Labview will not be used in our company for anything other than simple data recording. It's not transparent, you don't see what the heck is going on and debugging is an impossibility. Furthermore, we can't affort to pay engineers to play with this stuff as long as I have (also because I invested my private time) to end up on a dead end road. We need solutions, not more problems.

We use Matlab, CATIA, Nastran, subversion, and MS Studio for our product development on a daily basis. These are reliable, zero-bs workhorse engineering tools. Labview is NOT part of that group for a reason.

Regards,

Tony