How can I increase velocity setpoint precision, and obtain average motor current using NI 9505

[MKHokie]

Hello,

I have an application that is roughly based off of the example found in ...\examples\CompactRIO\Module Specific\NI 9505\Velocity Control (closed loop)\Velocity Control (closed loop) - NI 9505.lvproj

The "niFPGA Discrete PID.vi" that that this example uses takes an INT16 in for the velocity set point.  The issue that I am having is that in our mechanical setup, the difference between setpoint increments equates to a large changes in mechanical velocity i.e. a setpoint of 1 equates to about 4mm/min of movement to the piece attached to the screw, and a setpoint of 2 equates to about 11 mm/min.

I would like to have finer control over the motor velocity such that I can obtain speeds in between integer setpoints.  Any suggestions?

Also, does anyone have any suggestions on how the motor current sense output of the 9505 can be used to calculate an average current value (the amount you'd expect to see if you put an ammeter in series with the motor) and not the current during the "on" phase of the PWM cycle?

Thanks

[MKHokie]

Hello,

I have an application that is roughly based off of the example found in ...\examples\CompactRIO\Module Specific\NI 9505\Velocity Control (closed loop)\Velocity Control (closed loop) - NI 9505.lvproj

The "niFPGA Discrete PID.vi" that that this example uses takes an INT16 in for the velocity set point.  The issue that I am having is that in our mechanical setup, the difference between setpoint increments equates to a large changes in mechanical velocity i.e. a setpoint of 1 equates to about 4mm/min of movement to the piece attached to the screw, and a setpoint of 2 equates to about 11 mm/min.

I would like to have finer control over the motor velocity such that I can obtain speeds in between integer setpoints.  Any suggestions?

Also, does anyone have any suggestions on how the motor current sense output of the 9505 can be used to calculate an average current value (the amount you'd expect to see if you put an ammeter in series with the motor) and not the current during the "on" phase of the PWM cycle?

Thanks

[Burt_S]

Hello,

Is the problem that you need higher resolution than an I16, or is it that you need better resolution at lower speeds?  Controlling velocity at low speeds is a difficult problem.  Some simple solutions that would prevent you from having to change your control algorithm would be to use a higher resolution encoder or to use gearing to effectively increase the encoder resolution.  The big challenge is that the controller can't know how fast the motor is moving without getting updates from the encoder.  There are more advanced control algorithms designed for low-speed control, but unfortunately I am not an expert in them.

As for the average current, this is essentially already done for you in the example.  The current sampling is triggered by the PWM generator and is set to sample mid-way through the PWM high time.  As the current is linearly rising during the high time, sampling at the mid point is equivalent to taking the average.  Sampling half-way through the low time should give you the same result assuming the duty-cycle isn't changing.  The major exception to this is if the current changes through the motor so quickly that it rails, but this shouldn't happen if the motor meets the inductance specifications of the drive.

I know this isn't a full solution to your problem, but hopefully it at least gives you some ideas to consider.

[MKHokie]

Burt S,

Thanks for the input.  When I mentioned higher resolution than the I16 I was hoping there was some way to get the PID vi that came with that example to accept a fractional setpoint, or some other means by which I could get finer increments of mechanical velocity than what the whole integers were giving me, and this issue is most prevalent at low speeds.

NI's support recommended that I slow down the velocity loop speed, so I changed it from 250us to 500us, and this allowed me to adjust the motor speed in finer increments, but I will also look into getting a higher resolution encoder for this particular motor.

As for current, the motor that I'm most interrested in having accurate current for is a Maxon RE30, which according to the datasheet is 24V and 0.119 mH inductance, which I guess is below the inductance spec for the 9505.  So given that, what adjustments can I make to the current sampling such that it returns an average value?

Thanks

[Burt_S]

Slowing down the loop rate is also a solution as long as you can live with the performance hit this may cause.  I am not aware of a PID vi that excepts a fractional setpoint, but even if there was one you would still need a way to measure a fractional velocity for it to be very useful.

As mentioned in my last post, the method of sampling the current half-way through the PWM high time to get the average does not work well if the rate of change of current through the motor is high.  This is especially true if the current starts to rail.  I don't think that the NI 9505 is capable of reading the current quickly enough through a PWM cycle to use a different averaging technique other than the one it is currently using.  You might be able to come up with a model of the system that allows you to estimate where the appropriate sample point is based on the duty cycle, but this approach has a lot of drawbacks in addition to being challenging. 

Increasing the PWM frequency is another thing that could help, but I believe that the example is already using a PWM frequency that is half of the maximum supported by the NI 9505.  I think that this motor inductance is far enough out of specifications that doubling the PWM frequency won't be enough.

The easiest answer is to simply put an inductor in series with the motor.  The inductor will limit the rate of change of the current and should allow you to take accurate current readings.  The only major downside to doing this that I am aware of is that your motor won't be able to accelerate as quickly.  Again I hope this at least gives you some options to consider.

[MKHokie]

Burt S,

Thanks for the tip about putting inductors in series with the motors, I ordered some 100uH, 330uH, 470uH and 680uH power inductors (220's were out of stock) and have been doing some experimentation. 

Do you have any suggestions as to how much inductance I should look to add?  Should it be the minimum that gets the inductance to meet the 9505 spec, or are there any ratios that should be adhered to?

I'm seeing some promising results with regards to the 9505 current measurement on the motor that is 0.119mH when I put a 470uH in series with it, however I'm now having some issues with this motor occasionally getting "disabled by drive" when I'm switching velocity between 0 and say 50% of max, and getting its velocity to go all the way to 0 when I command that.

There is another motor in this system that is also undersized at 265uH, and even when I put as little as 100uH in series with this one, I begin having issues with it being "disabled by drive" particularly when changing velocities.

Any ideas what may be causing this behavior?  Could it be the velocity loop PID gains? - if so any general advice on how the to adjust those for the new inductance.

BTW - these are the same motors for that drill project (that you also commented on), figured I'd keep the electrical stuff in this thread.

It's still early on in my experimentation with these inductors, but I also made another observation that when I add the inductors to both of those motors, the signal coming from my load cell gets quieter when both of the motors are on, thou the load cell exhibits a larger offset.  I'm guessing this is an EMI issue, does anyone have any ideas what may be going on?

Thank you for your assistance.

-MKHokie

[Burt_S]

Hello,

Adding inductance to meet the minimum inductance spec of the 9505 should be sufficient to get a good current reading.  As for the Drive Disable issue, when changing the velocity setpoint, are you doing this gradually or are you stepping it up?  If the problem doesn't occur with gradual changes, manipulating the PID gains or writing a routine to more gradually increase the velocity setpoints could be a solution.  If this doesn't fix the problem, could you save the state of the Current Sense and Commanded PWM Duty cycle when the fault occurs?  This information might help shed some light on what exactly is happening.