LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Issues Driving a Stepper Motor

Hey all,

 

So I am working on driving a linear actuator using a NI USB 6501 DAQ card and an Anaheim Automation MBC25081TB Step motor driver. Currently, the linear actuator makes 1 eighth step in the clockwise direction for every iteration of the while loop. However, when I switch to CCW the motor makes multiple steps for every iteration. Using an oscilliscope, I can see that the DIRECTION and CLOCK signals that I'm sending from the NI USB 6501 to the step driver is the same for both CW and CCW and is on time with my code. 

 

My current configuration, has the DIRECTION and CLOCK signals being sent from the NI USB 6501 to the MBC25081TB driver, the ON/OFF input of the MBC25081TB is connected to the +5V output of the NI USB 6501, and the MS1 and MS2 inputs are connected to the NI USB 6501 but no signal is being sent. The JP1 of my MBC25081TB is set to position 1-2 (sinking). And the specifications for the generic brand motor (linear actuator) are: 1) 18 deg step angle, 2) 4-5VDC, 3) 0.5A, and 4) 3 mm pitch on the screw. The MBC25081TB driver is receiving power through a Phihong PSC12R-120 outlet plug.

 

Attached is my code and I'll include a link to where the same linear actuator can be bought from that has more specifications should you need it.

 

Link to linear actuator: https://www.seeedstudio.com/B04F-5V-DC-18%26deg%3B-Stepper-Motor-p-1901.html

 

Any help is much appreciated, thank you.

0 Kudos
Message 1 of 6
(3,617 Views)

I believe that the VI I attached in the original post has the correct default values, but if not here is the correct one. Sorry about that.

 

Again, any help is greatly appreciated.

0 Kudos
Message 2 of 6
(3,608 Views)

Caution for future: updating both clock and direction simultaneously may be a future problem.  The direction *state* will need to be stable at the instant of the clock *edge*.  When you transition both at once, it's hard to predict what state direction will be in when the clock transition is registered.

 

This doesn't explain your current observation of multiple steps per clock.  It could explain no steps or a wrong direction step if those arise in the future.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 3 of 6
(3,565 Views)

Thanks for the observation, I think I have seen that issue come up before and I didn't know what was causing it. I made some changes to my code yesterday and it seems to work properly now. All I did was remove the wait function in the CCW case between the two write functions. This stopped the multiple steps and the motor now goes both CW and CCW. 

 

Would you suggest writing the direction and clock separately? And do you see any issue with the change I made that seemed to fix the issue? Thanks for your help

0 Kudos
Message 4 of 6
(3,560 Views)

It's unclear to me why removing the waits would have an effect on the # steps.    Setting that aside, yes, I'd suggest for each step you first write the direction bit, then toggle the clock high-low with two more writes.   (The direction write only *needs* to happen once initially then every time it changes.  You could check for the change to decide whether the write needs to happen.)

 

Another very general comment: your board will limit you in this app.  You'll be stuck using software-timed DO for all your stepping signals.  The rate will be limited and variable under windows.  Thus, there's limited value in putting big effort into optimizing code.  The better answers will be found in more capable hardware.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 5 of 6
(3,552 Views)

Thanks again Kevin, unfortunately this is the hardware I'm limited to, it's either the NI USB 6501 or the NI USB 6009 OEM. Either way, at this point, both seem to work just fine with the program.

 

I did implement the change you suggested and made the DIRECTION and CLOCK signals be written separately so thank you again for that. Seems to be a bit smoother now.

0 Kudos
Message 6 of 6
(3,544 Views)