2 EC Motion Step Motors and Drivers for a Strain Gauge Calibration Rig

[hgfm]

Hi Guys,

long time reader, first time poster.

My current project is to use two step motors to calibrate strain gauges. I have a basic idea of LabVIEW, although I have had to teach myself so I am just stumbling through it and working things out as I go. So you may need to dumb it down a bit for me.

I have two rather large step motors and accompanying drivers from EC Motion. I have never dealt with step motors before, nor have I had much contact with LabVIEW.

Version of LabVIEW: 7.1

Motors: 2 Phase SECM2913-E4.0A with planetary gears on the end

Drivers: ECMD288.xxx

I have a few initial questions that I hope someone could help me out with.

1. What is the best way to connect the drivers to the computer? Do I need to connect them to an NI DAQ board to use them with LabVIEW or can I use a usb, parallel or comm port or something else

2. Do I need NI Motion or SoftMotion to make the program to drive the step motors?

3. How do I send the controls to the driver? What icons do I use? This is the main bit that I am stumped on. I have started writing the program, but just the easy safety bits for the user interface.

If anyone could give me any hints I would be very grateful! If I haven't given enough info or something let me know.

Thanks!

[Jochen]

Hi,

before I can answer your questions could you please post a link to a datasheet of the motor drive?

To better understand your needs, could you please tell us a bit about the type of motion control that is required by your application? E. .g do you want to drive the motors to certain positions and take measurements when these positions are reached or do you want to take measurements that are synchronized to the motors' positions while the axes are travelling (this could improve your system's throughput)?

Do you need to run any special motion profiles except trapezoidal trajectories (acceleration ramp, constant velocity, deceleration ramp), e. g. sinusoidal trajectories to test the dynamical charcteristics of your strain gauges?

LabVIEW supports a whole range of motion control options. The better you specify your requirements, the better we can advise you.

Thanks and kind regards,

Jochen Klier

National Instruments

[hgfm]

Thanks for the quick response Jochen,

I have attached the driver data sheet, and the one for the motor just in case you want to see it too. There isn't much in the one for the motor though.

What I would like to do is have the motors fixed to the base of the rig and drive a threaded rod that will cause a displacement. I will attach a paint drawing illustrating what I mean, because it might not be clear.

The idea is to obtain a calibration curve from the strain gauges, so we need to have output values for corresponding displacements. So the motion of the step motor is probably only going to be a defined number of steps then wait for a defined number of seconds. Nothing too complicated. The strain gauge measurements should be continuous because I will require feedback from the strain guage so that the motor will stop at a specified point and also maybe slow down the step rate if the rate of stress gets too high. I have a pretty good idea of how to do this except for getting the information from the strain gauge into LabVIEW. It doesn't need to be complicated at this stage, so I would prefer to keep it as simple as possible.

At this stage, nothing complicated. I would have thought that since the number of steps were so small that it would be more a digital signal (simple on off). Trapezoidal would be better though, then you wouldn't get sharp loadings. Although, if you had the speed slow enough it probably wouldn't matter would it???

It doesn't have to be anything fancy, so the simpler it can be done the better. All we would like to have is a calibration curve that plots strain gauge output values against known displacements. And a few safety things thrown in that will avoid any damage to equipment. The only other thing is that we would like to be able to adjust each motor to make sure they are level. I know how to make it select just one motor, I just don't know how to send the signal out to the motors.

Let me know if anything is unclear

Thanks again Jochen!

[Jochen]

Thank you for the informative explanations and attachments.

I think a very good fit for your application is the PCI-7332 motion controller. This device is supported by the NI-Motion driver, that provides interactive configuration in MAX, an easy to use API and all the synchronisation and safety features, that you need for your application.

This is how a simple linear move looks like in LabVIEW:

The 7332 supports the step/direction interface required by your motor drive, so this would be a good fit. You can start and stop multiple axes simultaneously and the 7332 monitors limit switches onboard and if you equip your motors with quadrature encoders, the board can detect motor stalls, which might be useful to avoid tilting of your mechanics, if one of your motors stalls or looses steps for some reason.

Adding quadrature encoders would be also very useful to synchronize the position information with the calibration measurement. With an encoder connected, the 7332 can generate digital pulses at certain positions (breakpoint generation), that can be used to trigger a measurement on a data acquisition board. If you are using an NI DAQ board, you even can route the signals internally through the RTSI lines from one board to the other one, reducing external cabling.

Quadrature encoders are highly recommended for your application, but if this is not applicable, there are alternative approaches that we could discuss.

Instead of a motion control board you also could use the digital lines of a DAQ board to control the motors, especially if you don't need to run acceleration ramps, but programming will be much more complicated, you might see a lot of jitter, which could result in step losses and there are no safety features like following error tracking or limit switch monitoring, that run independtly from the PC in hardware on the board. So with this said, a motion control board like the 7332 will amortize quickly, as it reduces development time and troubles significantly.

I hope this helps,

Jochen

[hgfm]

Thanks again Jochen you have been really helpful,

I think you are right. I have read about NI Motion and it would make things infinitely easier. But we want to try using what we have here first (PCI-6133). I presume we can use the digital ports from this card to control the step motor. I'm pretty sure I know how to do the safety things, and in terms of the quadrature encoders that again would be a good idea. I think that we will try and get what we have working and then if it isn't good enough we will definately go with your idea. Again, I would think that the acceleration ramps would be good to have, but might not be necessary.

What sub vi's would I need to use to send the information to the step motor? And how would I get input from the strain gauge? What sub vi's would I need for that?

In terms of the step control matrix do I use a stacked sequence, an array or something else?

Thanks!

[Jochen]

To control the stepper motors you will need four digital outputs of the 6133 (2x pulse +2x direction). Please note, that your drive probably provides optocouplers as inputs and the current ratings for the digital outputs of the 6133 might be too low to drive these optocouplers - another issue, that could be easily resolved with the 7332, as this device is designed to connect to optocoupler inputs, but anyway.

Just be aware of this potential issue as you might have to use some external signal conditioning to interface the 6133 to the motor drives for the case, that you don't see any reaction when you send pulses to the drives.

In order to move the motors smoothly you will have to use hardware timed digital outputs. In case of the 6133 this means, that you have to precalcualte an array of digital patterns and output it with a certain update rate. E. g. to move the motors by 1000 steps, you could generate an array with 2000 elements to toggle the two pulse outputs with each cycle of the update clock. To determine the motors' velocity you could generate the update clock for the digital outputs with one of the onboard counters. Please refer to the shipping examples about "Correlated Digital I/O" how to do that.

Even at low velocities don't try to control the digital outputs with a software approach (e. g. FOR-Loop with single point writes to the digital I/O lines). Due to jitter and other potential delays on Windows his WILL result in bumpy moves with oscillations, step loss or even stalls. These issues might not occurr at every run at the same level of severity, but software timing is definitely not a reliable solution, so please don't try that.

The hardware timed approach might sound a bit complicated and in fact it is by far not as simple as using NI-Motion. Still it's not rocket science, but it will require some higher level of LabVIEW knowledge, which I can't provide in a discussion forum thread.

In general you should start with improving your LabVIEW skills - regardless which hardware you are using. Besides low-level know how (which vi do I need for which task) you also should make sure, that you start with a clear understanding of your application's requirements and map these to a fitting  software architecture. NI also offers trainings classes to get you started quickly.

Regards,

Jochen

[hgfm]

Hi Jochen,

I have had a decent crack at doing it with the PCI-6133 and standard LabVIEW software, but can't get it to output the signal.

So we are now looking at the PCI-7332 that you mentioned. I just have a few questions before we go ahead and order it.

Is it the best option? We have a budget of 2500€ for the board, cable and connector block, but obviously don't want to spend any extra on something we won't need. If there is something that will do the job better or more easily we would be interested to know.

Also, we currently have LabVIEW 7.1, is NI Motion separate or is it more of a plug-in/add-on. Would it work with 7.1 or do we need a newer version of LabVIEW?

You say it will be much easier to program, will you be available for guidance if I run into any problems?

Thanks very much for all your help.

[hgfm]

Bump

[Jochen]

Sorry for the late response, but I was out of office for several days.

To answer your question:

As already mentioned the PCI-7332 is an easy to use motion control board with smooth LabVIEW integration, so I would consider it to be the best option for your use case.

NI offers even more powerful motion control solutions for more sophisticated motion control tasks (e. g. distributed motion control, customized control algorithms, extreme performance requirements,...), but they are more complex and more expensive, too. So in your case I would stick with the 7332.

As a connector block I would recommend the UMI-7764.

LabVIEW 7.1 is 6 years old now, so it's not supported by the current version of NI-Motion anymore. In general upgrading LabVIEW is a good idea, as later versions of LabVIEW provide a lot of useful new features, a much better project managment and support for current operating systems (e. g. Windows 7), but if you need to use LV 7.1, you also can install NI-Motion 7.5, which is the latest version of NI-Motion, that supports LV 7.1.

NI-Motion ships with a lot of useful examples, that demonstrate all features of the 7332, but of course if you have any specific questions about using the board, you can post it to the forum, so the community (including myself) can have a look at it.

If you need more in-depth advice, your local NI branch might be able to provide training or consulting services to you to get you started more quickly. Please contact your local NI branch, if this sounds interesting for you.

I hope that helps,

Regards,

Jochen

National Instruments Germany