Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Velocity vs. Torque Mode
#1
I have run across a scenario that seems to come up rather regularly and I would appreciate any thoughts on what I might be missing.

I have been in situations where I have a servo drive/motor pairing that I could configure in Velocity or Torque mode. 9 times out of 10 I use Torque mode because I am trying to position a servo on a ball screw axis or something similar. This makes total sense and I understand that the motion controller is handling speed and position in this case and the drive is only closing the current loop.

I do, from time to time, have cases where i don't care to position an axis and simply need to run at a given velocity, a spindle motor axis for example, and it is here that I wonder which mode is best. Perhaps the better way to put it is:

Are there any reasons NOT to be in Torque mode when running the axis at a constant velocity?

The only disadvantage I have seen so far is that if my tuning is off I could have ever-increasing following error that eventually leads to a fatal following error situation. Tuning in general seems more sensitive in this application, as loads vary much more in a cutting application than a fixed inertial load with known accelerations might.
Reply
#2
Your question really comes down to: Where is it best to close the velocity loop?

A velocity loop must be closed for stable operation. If the controller is in torque mode, the velocity loop must be closed in the control (using the velocity feedback gains). If the controller is in velocity mode, the velocity loop must be closed in the drive.

The velocity loop, like the position loop, must be tuned with the load attached, because its performance is affected by factors such as load inertia, coupling compliance, and friction. If you close the loop in the drive, you must deal with both the actual performance of the loop and the setup tools to tune the loop for the drive. In my experience, these tools range from excellent to awful.

In applications that close the position loop, almost everyone puts the controller in torque mode, because few people want to first tune the drive's velocity loop, then the controller's position loop in completely separate steps. Very seldom is there a countervailing advantage that makes this worth it.

For axes where you care about velocity control, but not position control, there are a few things to consider. When I discuss this issue with users, I ask them what response they want after a heavier load torque temporarily slows the axis below commanded velocity. If you want the axis to catch up in position, which requires temporarily going faster than commanded, then you want full position control. If you only want the axis to catch up in velocity, then you want velocity control.

I think in your spindle motor case, you want the second case. In this case, what we advise is to initially tune the motor as if it were a full position control axis, but without integral gain. Use velocity feedforward to minimize the following error.

To convert the motor to velocity control, set Motor[x].MaxPosErr to 0 to disable the position loop. The velocity feedforward term will provide the main command to move the motor now. Also set Motor[x].FatalFeLimit to 0 to disable trips on fatal following error.

Note that these settings are appropriate whether you are commanding the drive in torque or velocity mode. So the answer to your question: "Are there any reasons NOT to be in Torque mode when running the axis at a constant velocity?" is no -- or at least no NEW reasons for this compared to full position control.
Reply
#3
Personally, always putting the drive in torque mode so that you can control all the loop gains directly from PMAC is greatly preferable and generally much more convenient and flexible than plugging into 3rd party drives and using their tuning tools.
Reply
#4
(10-18-2017, 08:55 PM)Clopedandle Wrote: Personally, always putting the drive in torque mode so that you can control all the loop gains directly from PMAC is greatly preferable and generally much more convenient and flexible than plugging into 3rd party drives and using their tuning tools.

I agree in principle, assuming you are referring to an e-Cat interface.
I do have concern with closing the torque loop at 'only' 4k + transport delays.
1) Have you been able to close faster than 4k (8k)?
2) Can you offer further comments on your experience?
Thank You
Reply
#5
Running an EtherCAT drive in torque mode at 4 kHz, given the transport delays, gives approximately equivalent performance to running a "local" analog-input torque-mode drive at 2 kHz -- good solid performance for most applications, but not for super-precision applications.

Few EtherCAT drives can use new torque commands at 8 kHz. Some will accept the commands at 8 kHz, but only use every second command. You need to check with the drive supplier.
Reply
#6
(10-20-2017, 04:12 PM)curtwilson Wrote: Running an EtherCAT drive in torque mode at 4 kHz, given the transport delays, gives approximately equivalent performance to running a "local" analog-input torque-mode drive at 2 kHz -- good solid performance for most applications, but not for super-precision applications.

Few EtherCAT drives can use new torque commands at 8 kHz. Some will accept the commands at 8 kHz, but only use every second command. You need to check with the drive supplier.

Useful comparison, Thank You.
- Do you see this as something that will continue to develop/improve over time?
- Have read a paper you published that cautions the e-Cat standard only provides for a +-1000 count cyclical torque command. Is this limitation strictly observed, or do manuf's generally acommodate higher resolution?
- In the case of a drive that could handle cyclical torque at 8k, is there an axis count where PPMAC/e-Cat becomes the limiting factor as the e-Cat Master?
Reply
#7
To be honest, in recent history (i.e. in the last two or so years), I have not needed such a fast servo rate as our applications are generally simple pick and place. However, just doing a quick check of the OMRON 1S product site, I see that they support a 125 us distributed clock, which would correspond to an 8 kHz transmission rate of EtherCAT packets, but like Curt said, that would translate to 4 kHz "actual" servo. I am not aware of another drive that can go faster, but perhaps one exists.

To comment further on my experiences, basically the frustration emerges in having to learn so many different servo loop tuning tools if you are using drives from different manufacturers (e.g. Yaskawa, OMRON, Copley, Teknic, Panasonic, etc.), the quality of which varies greatly (OMRON/Copley are quite easy to use, however), as Curt said. These pieces of software usually drag you through a multistep process of selecting your mechanism, asking you what kind of application you have, and then doing potentially 1+ hours of auto-tuning moves before you can even start using the drive. This may be handy for a beginner, but once you understand how to tune each gain manually, it's basically a waste of time, in my opinion. Not only that, to change even a single gain from that point forward requires you to open the cabinet again, connect to the product again (usually through USB), load the drive's software, navigate through the menus until you reach the list of parameters, try to identify what a parameter is based on some parameter name that varies between manufacturers, adjust it, disconnect, possibly power cycle to retain the change, and then you can (probably) move forward. It's so much simpler to do all of the tuning right from PMAC if you know how. You can govern the velocity loop entirely through the velocity loop gains in PMAC's servo loop.

Curt's really the expert on all of these kinds of topics, but I am happy to answer any other question from personal experiences.
Reply
#8
(10-24-2017, 12:39 PM)Clopedandle Wrote: To be honest, in recent history (i.e. in the last two or so years), I have not needed such a fast servo rate as our applications are generally simple pick and place. However, just doing a quick check of the OMRON 1S product site, I see that they support a 125 us distributed clock, which would correspond to an 8 kHz transmission rate of EtherCAT packets, but like Curt said, that would translate to 4 kHz "actual" servo. I am not aware of another drive that can go faster, but perhaps one exists.

To comment further on my experiences, basically the frustration emerges in having to learn so many different servo loop tuning tools if you are using drives from different manufacturers (e.g. Yaskawa, OMRON, Copley, Teknic, Panasonic, etc.), the quality of which varies greatly (OMRON/Copley are quite easy to use, however), as Curt said. These pieces of software usually drag you through a multistep process of selecting your mechanism, asking you what kind of application you have, and then doing potentially 1+ hours of auto-tuning moves before you can even start using the drive. This may be handy for a beginner, but once you understand how to tune each gain manually, it's basically a waste of time, in my opinion. Not only that, to change even a single gain from that point forward requires you to open the cabinet again, connect to the product again (usually through USB), load the drive's software, navigate through the menus until you reach the list of parameters, try to identify what a parameter is based on some parameter name that varies between manufacturers, adjust it, disconnect, possibly power cycle to retain the change, and then you can (probably) move forward. It's so much simpler to do all of the tuning right from PMAC if you know how. You can govern the velocity loop entirely through the velocity loop gains in PMAC's servo loop.

Curt's really the expert on all of these kinds of topics, but I am happy to answer any other question from personal experiences.

I agree on the issue of tuning the various drives, some of them are really a pain compared to doing it at the DT level. Quick & precise. Much prefer to operate the drive in current mode.
I'm tempted to fall back to a +-10v analog. (I can hear the "but it's not digital" chorus already)
Reply
#9
mbalentine:

From what I can divine, few EtherCAT drive manufacturers are making higher update rates a priority. I do expect a few to push this functionality, if only to differentiate themselves from the others.

Some, but not all, EtherCAT drives provide a work-around to extend the +/-1000 (~11-bit) standard resolution to 16 bits. Unfortunately, each work-around is different.

Delta Tau provides two different EtherCAT "stacks". The Etherlab stack is very efficient in operation, but not feature-rich and with limited setup tools. The Acontis stack is full-featured and has pretty comprehensive setup tools, but the additional overhead of the extended functionality limits its operational efficiency.

You should not expect to operate faster than 4 kHz with the Acontis stack on "hardware PMACs", even for a limited number of axes. The Omron IPC, with its multi-core i7 processor, can do 6 - 8 axes at 8 kHz.

With the streamlined Etherlab stack, you can do 8 kHz update on many axes on our "hardware PMACs". This stack is not available on the uPowerPMAC (CK3E) or IPC.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)