1
\$\begingroup\$

I have a motor that runs between 3 to 3000 RPM. The drive update time is 2.2 micro seconds. What is appropriate an encoder resolution for this work (especially for lower speeds) so the drive could update the motor at each 2.2 micro second without missing signals and instability?

Is there anyway that I demand to update data at longer time (more than 2.2 micro seconds) by same drive? here is the part of a white article written by siemens group. I did my calculation based on this.

enter image description here

and the results of my calculation are as shown below enter image description here

here is the drive specifications enter image description here

\$\endgroup\$
13
  • \$\begingroup\$ Please edit to include a link to the user manual for the drive. Usually the encoder inputs would be on some sort of interrupt so that they don't depend on the main CPU polling. Otherwise where are you stuck on the calculation? \$\endgroup\$
    – Transistor
    Commented Aug 18, 2020 at 11:54
  • \$\begingroup\$ What have you done to solve this problem already? \$\endgroup\$
    – user16324
    Commented Aug 18, 2020 at 12:19
  • 1
    \$\begingroup\$ I think you're not framing the scenario properly in you mind. What's the problem if the drive grabs the same encoder position for two consecutive updates cycles if the rotor is still virtually in the same position? I don't see how update time is relevant when picking the encoder. You're speaking almost as if you think the encoder needs to be a different value every time an update occurs. Just pick an encoder resolution where "the rotor is still virtually in the same position" if you're off by one encoder count. So probably no encoder counts less than 256 where you can see the difference \$\endgroup\$
    – DKNguyen
    Commented Aug 18, 2020 at 13:51
  • \$\begingroup\$ "without missing signals". Use interrupts to detect input signal changes. Make the interrupt handler function as fast as possible. \$\endgroup\$
    – AJN
    Commented Aug 18, 2020 at 16:18
  • \$\begingroup\$ @Transistor I update the question and add some details. I am supposed to modify a system that didn't work well at low speed. I worked on the calculation and did some research to find the causes of servo motor instability. I ended up by the 25 bit encoder for each turn but it is not in the market. I want to check if my assumptions and calculations are correct \$\endgroup\$
    – fatemeh katibeh
    Commented Aug 19, 2020 at 6:15

2 Answers 2

Reset to default
0
\$\begingroup\$

Method 1 - add additional hardware

If you want only speed control and not position, then connect a gear to the motor shaft. The output of the gear system should not be connected to the load. It should be connected to an encoder. The gear ratio should be such that the gear system output runs faster than the motor shaft, say 100 times.

When the desired RPM goes below some pre determined value, say 10 RPM, stop monitoring the main encoder connected to the shaft. start monitoring the enocoder at the output of the gear system which is spinning 100 times faster in our example. Use pulses from this faster spinning encoder to control the motor speed by compensating for the factor in software.

Beware of backlash in the gear system if the motor changes direction. I don't think it does in you example since you say 3 RPM to 3000 RPM (i.e; no 0 RPM).

Also, once you start going to very low RPMs, the static friction in the motor can also lead to instability of the control. Beware of that.

At 3000 RPM the gear and the shaft will spin at 300,000 RPM. This may damage the gear. If so, then use a clutch to disconnect the gear system from motor shaft when RPM goes above some pre determined RPM, say, 100 RPM.

Method 2 - change 2.2us

It is not clear (to me) from your question the sanctity of 2.2us. Cant you increase it when desired RPM is low ? I think you need 2.2us only for high RPMs. If you can vary the sampling frequency dynamically, then you don't need extra hardware. You will get enough pulses for 3RPM if you change 2.2us to say, 2.2ms.

\$\endgroup\$
0
\$\begingroup\$

If the problem is actually what you say it is (the VFD panics and outputs a large pulse because it reads no angular changes between successive samples), then I suppose you could feed the encoder through an FPGA or CPLD that time-interpolates between real encoder pulses and outputs a stream of arbitrarily fast quadrature encoder pulses to spoof an arbitrarily high count encoder. Of course this system kind of breaks if the angular speed varies too much between encoder pulses. Like a PLL for a quad encoders pulse train.

This might overload things at higher RPM though. Since, for example, 20,000 counts per revolution ends up being 20,000,000 counts per second at 3000RPM.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.