[LBodnar]

I am developing a custom controller for VSD-A and use STEP/DIR mode to control torque.

I cannot figure out the way to monitor if VSD-A has been reset by a user in the middle of a sequence. This is required to reset the torque value in the controller to zero and re-sync drive and controller.

Suppose the controller commanded some required torque (e.g. 10) and then VSD-A has been power-cycled. It starts up in zero torque and if then controller winds down the torque to zero the drive will end up producing -10 as a result.

Any ideas? Thanks!

[Xerxes]

Have you considered using PWM input instead? It will be absolute, so you'll always know how much the commanded torque is. 50% PWM duty equals zero torque.

[LBodnar]

Have you considered using PWM input instead? It will be absolute, so you'll always know how much the commanded torque is. 50% PWM duty equals zero torque.

Yes, I have tried it and the quality was not very good. I have used 10-bit 10kHz PWM and zero torque was at 490 instead of 511 and the output was jittery. I am not sure if it was caused by non-symmetrical on-off times of optocouplers or something else but it was not very encouraging from the beginning. However, I liked the fact that when PWM stopped torque was also removed. This is great safety feature which unfortunately won't work with step/dir. Oh, well...

Ideally, I want to use SPI but this still remains undocumented as far as I can see...

[Xerxes]

The precision of PWM input is more than 10 bits, it's about 14 bits. Things you can try to reduce jitter:
-Reduce "input multiplier" from GDtool, this way input becomes less sensitive
-Replace HCPL-2531 optoisolator with faster HCPL-2631
-Use lower PWM freq to get more output resolution from µC (3 to 6kHz should be best)

And about the original question: If you wish to monitor if someone resets the drive, it should be sufficient to monitor logic supply voltage as it would be the only way to reset.

I sent you some guidance about SPI to email.

[LBodnar]

The precision of PWM input is more than 10 bits, it's about 14 bits. Things you can try to reduce jitter:
-Reduce "input multiplier" from GDtool, this way input becomes less sensitive
-Replace HCPL-2531 optoisolator with faster HCPL-2631
-Use lower PWM freq to get more output resolution from µC (3 to 6kHz should be best)

Let's see the SPI way if this doesn't work for you.

Kiitos for your support!
I have tried and did most of the tests on 3kHz PWM already and have not noticed any difference. I will try to get a faster optoisolator and see what happens.

I really want to try SPI mode control at some point.

[brodolomac]

Hi,

I saw this video (http://video.google.com/videoplay?do...92974890836012) for VSD-A fluxeon drive and I have one question for xerxes, granitedevices or anyone.

I found comment for this video:

AC servo turning thru a mixed mode sequence: 1) Running various speeds in velocity mode 2) Homing in position mode and positioning to 180, 90 and -360 3) Running various speeds in velocity mode 4) Homing in position mode and positioning to 180 90 and -720.

My question: Is it some mistake in 3)? I think it has to be 3) Running various speeds in position mode.

I say this, because running motor at low speed with encoder resolutions < 60000 is imposible in velocity mode, only in position mode with trajectory profile update every 5-10 ms. Or I am wrong?

[Xerxes]

brodolomac,
Techically velocity mode is a modfied position controller with some optimizations for velocity control, so it works at any speed.

[brodolomac]

When I say velocity mode, I mean velocity closed control loop. And position mode, position closed loop. So, am I right when I say that this low speed rpm on VSD-A is actually velocity mode using position control ( you give continous position commands in short time steps to achieve velocity tracking)?

[Xerxes]

When I say velocity mode, I mean velocity closed control loop. And position mode, position closed loop. So, am I right when I say that this low speed rpm on VSD-A is actually velocity mode using position control ( you give continous position commands in short time steps to achieve velocity tracking)?

Something like that.

Apart from that VSD-E has a "real" velocity controller that doesn't use position information anywhere but user probalbly won't notice the difference since it will also work at infinitely low speeds.

[brodolomac]

Thanks for answering the question. If we use servo motor with 1000 ppr then the lowest angular speed that controller can measure is fs/4000. Fs is velocity control loop update frequency and let say fs=4000 Hz. Then the lowest detected speed is 1 Hz or 60 rpm and it's not infinitely low speed. Speed estimation using some interpolation or observer is only remaining possibility that I know. Does VSD-E use speed estimation?

[Xerxes]

VSD-E control algorithm doesn't have any difficulties if speed estimation shows 0 most of time. An average is only that matters. Real minimum commandable speed is actually 0.0763 counts/sec or on 1000 ppr encoder 0.00114 rpm.

[brodolomac]

Use of averaging (filtering) reduces velocity control bandwidth by way of inserting delay in control loop. If we need fast velocity response in low speed, I'm not sure about use of averaging for speed estimate in velocity control. And again, we have to go back and use position controller for velocity control. I don't know how VSD-E works at low speed with just velocity controller. On VSD-A video I saw fast response in low speed.

[Xerxes]

You're right about effects of averaging, I used it in early VSD-A firmwares. VSD-E doesn't need or use averaging. Low speed operation was achieved by a more sophisticated velocity controller design. However, it is true that velocity can't be guaranteed to be perfectly smooth at low speeds if encoder resolution is low.

[brodolomac]

Do you use any kind of interpolation/prediction to get velocity values in between encoder pulses. I read a lot of papers with discussions about use of kalman filter and quadratic interpolation.

[Xerxes]

Do you use any kind of interpolation/prediction to get velocity values in between encoder pulses. I read a lot of papers with discussions about use of kalman filter and quadratic interpolation.

Not using those. I'll keep the impementation details

[brodolomac]

I would understand you're hiding implementation details if you have discovered a new technique for speed estimation. After your answers someone may believe that VSD-E is driven by magic forces.

[Xerxes]

I would understand you're hiding implementation details if you have discovered a new technique for speed estimation. After your answers someone may believe that VSD-E is driven by magic forces.

Well, there are few pieces of code in firmware that I think are somewhat innovative and I haven't seen similar implementation anywhere. Velocity controller is just result of several days of careful thinking & experimenting. No magic forces there.

[keebler303]

No magic forces there.

Maybe you could have a new product with the "magic forces" included. You could probably charge at least double.

Matt

P.S. Did you get the article I emailed you?

[brodolomac]

My questions and Xerxes's answers:

1q. You said that VSD use velocity mode for low speed? But I think it uses position mode.
1a. "Techically velocity mode is a modfied position controller with some optimizations for velocity control, so it works at any speed. "

2q. I said that too. Velocity control achived by use of position controller.
2a. "Apart from that VSD-E has a "real" velocity controller that doesn't use position information anywhere..."

3q. So, if it doesn't use position controller, then to get low speed control there must be some sort of velocity estimation with interpolation.
3a. "VSD-E control algorithm doesn't have any difficulties if speed estimation shows 0 most of time. An average is only that matters".

4a. Averaging reduces control bandwitdth and causes instability. Not usable.
4q. "You're right about effects of averaging. VSD-E doesn't need or use averaging"

5q. So, again, there must be velocity estimation (Kalman, polynomial interpolation...).
5a. "Not using those. I'll keep the impementation details"

No comment.

[Xerxes]

No comment.

I'm just wondering where would one need these implementation details. I just rechecked my code, it certainly doesn't use position info, averaging or magic. Anyone needing one should be capable of creating one after fully understanding how PI controller works.

Matt, I got the article, thanks! I put it in to my collecetion where I keep useful stuff that may be needed some day.