Using a cDAQ to control a stepper motor

[SHentchel]

Hello,

I'm looking for assistance and advise with a program I am writing for my company. I'm a long time LabVIEW user but relatively new to DAQmx. This program is used to drive a stepper motor by sending digital signals to a FET driver. Right now I send the driver an array of data points that walk it through each phase. This works fine at low speeds, but for our higher speed operation we need it to accelerate up to 1200  rpm using a per-defined acceleration curve. I've written the program attached to do this. The problem is that after it completes the acceleration curve it repeats the signal while it loads the steady state array. and this load takes over 1 second second to do, which leaves me with the question of how do I get the program to transition from acceleration to steady state?

[Kevin_Price]

Getting a step-timing motion profile *right* is an order of magnitude more difficult than getting it "almost right" or "close enough" or "usually ok".   Most efforts I've seen have ended up in one of the latter categories.

Many times, that's still fine.  It depends on the specific situation.  So can you give some background on why you're approaching this in such a bare-metal old school way rather than purchasing a commercial stepper controller?  What cDAQ chassis and modules do you have?  Can you consider using a desktop PCIe DAQ device?

What kinds of trajectories do you need to support?  Finite incremental position moves?  Indefinite constant speed slewing (with appropriate accel/decel at the ends)?   What matters most about the motion you generate and why?

-Kevin P

[SHentchel]

Thanks for the response.

I'm trying to create test software for a medical centrifuge my company creates. In the product, this motor controls the FET drivers with an internal FPGA, but the current firmware does not support and testing commands. The Motor is 60V, 2.4 Amp bipolar stepper motor, and I've been unable to find an off-the-self motor driver that can handle that kind of power and also provides phase control. Besides which we would like to use the products hardware for this test which means bypassing the FPGA and controlling the FET Driver directly.

For the test we will need to verify every position is correctly aligned, and that all sample are aligned on a half step, with the home position at phase 1. This is verified with the encoder on the motor. We then need to bring the motor up to it test speed (which could be anywhere between 600 and 1200rpm), taking optical readings as the centrifuge spins (the timing is handled by the encoder, I've already gotten that part working). Of course the motor can't just jump to though speeds, it needs to accelerate, preferable using the same acceleration curve the product uses. Once up to speed we need it to keep at that speed until the sample fully separates (determined by the optics) and then decelerate to rest. Form the perspective of the motor control, it's insuring the motor is at the correct speed is most important, if we can get it up to speed and insure that it stays at that speed I'd be willing to call that good enough.

[Kevin_Price]

Ok, sounds doable.  

1. I would add a couple bits to the DO stream and use them to produce a quadrature pair in sync with your phase bits.  That can be measured to verify step count.

2. You will need to service the data in your task's output buffer more carefully.    

3. Since you don't need to move a specified # steps, make life easier for yourself.  Always define the chunks of data you deliver to the task in terms of full cycles through all the phase bits.  Then the first sample of each kind of data chunk (accel, slew, decel) represents the same digital state.  This greatly simplifies *many* potential issues about stitching the segments together.

4. There will be tradeoffs between buffer size, chunk size of data to write at a time, latency between writing to the task buffer and having the signal show up in the real world.  Note that lower-level DAQmx settings exist that give you partial control over the latency, provided you've done the other programming carefully.

   Again, it's a big help that you don't have precise position control requirements.

5. I'd explore an approach that used a counter as my DO sample clock.   A counter whose frequency is changed on-the-fly via software might be good enough, though you're liable to see the accel/decel ramps become stairstep patterns with piece-wise constant plateus.   The looser your requirements are for the time or # steps used for accel/decel, the less likely this will be a real problem.

  A counter that supports buffered pulse output could do even better, but would take more development work.

-Kevin P

[SHentchel]

I appreciate the suggestion, but I'm still not clear as to how i can control the DAQ's output buffer. Is there a way I can write a second data stream to the buffer and not have it trigger until the previous one is complete?

[Kevin_Price]

Hard to say until we define precisely what you mean by the word "trigger".  It has a very specific meaning for DAQ boards, but is often used colloquially to mean other things entirely.

Generally, you can call DAQmx Write repeatedly to push data into the task's buffer, and the first sample from the new data you are sending will be placed immediately after the last sample from the previous data you sent.  The DAQmx driver API has some internal smarts built in so that if you try to push data that would overwrite samples that haven't yet been generated as real world signals, the DAQmx Write call will "block" and try to wait until enough samples have been generated to make room for the new data you're pushing.  If you've given DAQmx a long enough timeout value to wait that long, all will be well.  Out at the real world output, the signal will generate as a continuous stream.  You just have to keep feeding data fast enough to the task.

Feeding data too slow is known as a buffer underflow and will generally cause a task error.  (This might be avoidable with special task settings, but I'm not sure that's universal across all kinds of DAQ boards.)

Feeding data too fast will cause your DAQmx Write calls to block & wait for space to free up.  Once called with a long timeout, you can't cleanly interrupt such calls, and that can sometimes be a problem too.

DAQmx Write will generally not allow you to push new data into a position where it will be generated before data that was written previously.  There are task settings and properties that kinda seem to hint and suggest that you can force the issue, but have not explored enough to confirm or deny for sure.

To generate a trapezoidal velocity profile, you should be able to first write the Accel chunk, then write a Slew chunk N times, then write a Decel chunk.  Each write will naturally append the new data to the end of the old data.  All the Accel data will be generated before any of the Slew data.  All the Slew data will be generated before any Decel data.

-Kevin P

[SHentchel]

Thanks for all your help Kevin, I've been doing a bit of experimenting with DAQ writes, it appears that I would need to keep appending data to the buffer in order to get the motor to run at speed continuously. I'm a little worried about overfilling the buffers though as you mentioned. Can I use the DAQ trigger VIs to insure I don't write sample too fast. I'm not exactly sure how to use them.

[Kevin_Price]

I'd recommend looking at DAQmx events, though it's possible that they won't be as seamless for you on a USB-connected cDAQ as what I've seen on desktop plugin boards.

You can configure for an event to fire for every "N" samples transferred out of your task buffer.  So you can automatically know there's room to write another "N" samples to the task.   This should help you not run into buffer overfill problems.  From the DAQmx palette, choose "Advanced-->DAQmx Events".   (There's also a DAQmx property you can query that tells you how much space is available in the buffer.  I'd personally check this too, in case you build up a backlog of events for some reason.)

I just went back and reviewed the thread to get a refresh on the big picture.  It looks like the key thing is to operate a centrifuge at constant speed until you optically detect sufficient separation of "stuff."   You'll know better than I, but it *might* matter to also make the motion pretty smooth during accel and decel.  Motion jerk might disturb the suspended elements.  How significant an issue do you think motion jerk might be?

-Kevin P

[SHentchel · Accepted solution]

So I ran a few timing tests. It seems the issue is not the buffer but the rate of data transfer over USB. With USB 1.0 it takes 2-5 seconds to transfer a 10,000 sample packet. It can be done in .8 seconds over USB 2.0 but we need to transfer a package every .25 seconds in ordered to reach speed with the centrifuge. However I did find that the DAC can change clock speed in less than 2ms, so I converted the acceleration table from having dynamic samples to having a dynamic clock speed. The results are attached.

Thank you Kevin your help, I'm still learning the capabilities and limitations of DAQmx, your suggestions and information were very helpful.