-
Having mostly mastered CAN Open (well fix one problem and now your see the next problem more clearly
) I have been looking at how to refine my motor control.
I have two motors that are couple to the load with some elasticity - literally. Lets just approximate the system as two motors that drive a common shaft via belts and the are mounted such that for the shaft to rotate the motors rotate in opposite directions.
So I immediately discarded the idea of using the motors in speed controlled mode. A short experiment proved my theory right, One motor will take over all of the load delivery while the other will be left lazy. I want them to share.
So I went with Torque control. I send a sync message to the network, get the speed of the motors back, average that speed and decide on how to change the torque, then I send the new torque setting. It works OK, I am still debating with myself as to whether I should update often with small values or less often with larger values. At his point I started looking around for information on how to consider setting up a DS402 motor driver to run in torque mode with my external controller (CAN Open master) doing the speed control.
I came across an example of a non CAN Open motor system for a conveyor belt where one motor is run in speed control mode with additional "helper" motors running in torque mode. EUREKA!
But that makes my wonderings about precise settings even more relevant as now the two motors will have different behaviors while achieving the same thing together. The idea is that I no longer need to send a sync message to get the speed from each motor, process that and issue new torque commands. Instead I would send the speed required to one motor and send the sync message. The speed controlled motor will respond with it's target torque as well as actual torque. The torque controlled motor will be set up to receive this target torque as it's torque demand and so setting both motors to the same torque. In this way there is no race between the two motors with one taking over but I get to use the much faster and certainly better designed speed control loop in the motor driver than my own machination that is just keeping up.
Obviously that the motors are mounted opposite ways round is a problem as whatever the torque of one motor is the other needs the negative of the number. I currently do this in my program before sending the numbers out to the two motors. There is a setting somewhere for the encoder that basically reverses it's interpretation, need to look more into this one to see if there is a way to overall reverse the motor direction.
What I do wonder about though is the tuning of the two motors works. I guess that as the helper motor is just that it's torque does not need to be identical but I also do not want to confuse the speed control loop in the speed controlled motor. I suspect that the torque controlled motor needs to react faster than the speed controlled one so that it adds or subtracts it's torque in time for when the speed controlled motor is expected to achieve it's speed and so not confuse the system.
Has anyone ever done this? -
For the torque/current controlled motor it will be important to keep the torque command below what is needed otherwise it will tend to run away, speed wise, and yes the torque needs a faster loop because it needs to react to load variations. How dynamic is your load ? It also depends on how fast your control loop is compared to the dynamics of the system, lag is a killer for stability.
-
Well if the motors are to sync up and do their thing then all that I can do is have the slave motor provide the same torque as the master speed controlling motor.
So if I send a speed demand in the PDO message and then send a sync message the master will take the new speed demand and respond with a torque target. Now as it stands I don't know if that torque target will be what it was doing or what it is planning to do now that it has the go ahead for the new speed. The sync message basically trigger action on previous commands received (RX PDO) and prompts the sending of up to date information (TX PDO).
So the slave motor will then see the masters torque target as it's torque demand, but it will not act on the demand until it gets another sync message. So at best the slave will be one cycle behind the master unless I can change the settings in the slave so that it reacts immediately to the RX PDO that contains the torque demand.
If the sync message is sent at a much faster rate than the master speed controlling motor can to keep up with any load changes that affect speed then the slave motor will see new torque demands faster than the master is settling at so the action of the slave motor that must be much faster than the master will become part of the masters own control of the speed.
At the moment in dual torque control I am sending sync messages every 3ms but I make a change on every 3rd message to give the motors time to settle before I act on the data and I do that alternately so each motor only makes a change every 18ms. So with this new method that would be the equivalent of sending 6 updates between full control cycles. So I slow down the reaction of the speed controller motor and speed up the reaction of the torque control motor and now that I am doing less processing in my CAN Open master controller I can send the sync message even faster. -
Just to summarise, to see if I understand correctly, the slave motor is following the torque profile of the master(speed motor) but one sync behind, which is about 3ms, so you should be sharing the load roughly equally and the demand torque to the slave should reduce as the master motor approaches its set speed and its demand torque reduces. It sounds reasonable, what you could do to confirm it is log the current of each motor at the same time and check that they are load sharing during dynamic and static situations. What about when static, no speed change, does the master still provide a demand torque for the slave to follow?
-
Yes that is about it. If I were to get this to work I would be able to sync more often as I my CAN Open master controller is no longer doing the speed regulation so it does not have to do anything with the data coming out at speed.
The Target_torque is the internal set point of the master speed controller motor. it will transmit on any sync message whatever the motor is doing.
The slave torque helper will basically use this as it's Torque_Demand (which will internally produce a torque_target that I assume will be the same) and so follow along.
The crux will be getting the torque motor to react quickly enough to fool the speed controlled motor into thinking that it has twice the torque or rather that the load is half of what it is as it will not be aware of the second motor. So the speed controlled motor will need to have a slower torque ramp rate than the torque control motor so that whatever torque it uses is quickly matched by the Torque controlled motor so that it does not see the full load. And hopefully this all happens without the two falling ass about face or oscillating. -
The crux will be getting the torque motor to react quickly enough to fool the speed controlled motor into thinking that it has twice the torque or rather that the load is half of what it is as it will not be aware of the second motor. So the speed controlled motor will need to have a slower torque ramp rate than the torque control motor so that whatever torque it uses is quickly matched by the Torque controlled motor so that it does not see the full load. And hopefully this all happens without the two falling ass about face or oscillating.
I was thinking the same thing, two torques rather than one, but I assume since it is a semi intelligent controller there must be something like PID parameters that it uses and if so then you can adjust these to reflect the new reality and hopefully prevent overshoot oscillations. Can you get a regular report back from the controllers on motor current? That would provide a good insight into what is happening torque wise. -
Couple of critical questions:
1) is the "perfect" situation that both motors equally share the load at all times and respond identically?
2) How Dynamic is the system. Ie if you applied full torque or full load, what is the maximum rate of change of rotational speed
The answers will dominate what the best control architecture is!
If we assume the answer to 1) is YES (50:50 share is ideal) and the answer to 2) is say 1 second to reach max speed from zero speed
then it's clearly going to be best and easiest to do external speed control, ie to calculate a total torque value, then just split this 50:50 and send out that half torque command to each motor, and you'll need to be able to do this at between 10 and 20 times a second in order to maintain sufficient control bandwidth
There are other options which could be possible but which very much depend on the system dynamics, for example putting both in local speed control mode, but calibrating the PIDs differently to avoid detructive interference (you can have one motor doing all the P and one doing all the I for example)
The other question is what is fundamental oscialtion frequency of the system, ie you say the drives are "elastic", what is the natural frequency of this and will you control system operate above or below it (it really can't operate IN this zone!) Now if the load is varriable, then that no-go control bandwidth zone can be quite wide, so care will be required. For most mechanical systems, it's generally preffered to be above the natural frequency as normally things get "less stiff with time / condition / load" etc
The final question is
"How critical is the speed control accuracy and convergence" Ie, At what point does it actually matter that the speed is "wrong"? If you're making a machine to stir custard, then clearly, you've probably got a lot of tollerance to varriable speed, but a system to drive an elevator full of people, less tollerance. As you know the application, you can make some qualified estimation of the errorband/deadband that your system can tollerate, and this will drive the mechanical and software/controls architecture as appropriate...
-
A pleasure to hear from you
Couple of critical questions:
1) is the "perfect" situation that both motors equally share the load at all times and respond identically?
The motors should share the load but this does not need to be exactly matched. They are not now with my current control method.Quote
2) How Dynamic is the system. Ie if you applied full torque or full load, what is the maximum rate of change of rotational speed
Well the motors themselves will accelerate fast. So fast that they can trip out due to the shock to the system that generates some fault that the drive reacts to. The torque slope starts out at default of 10'000 which is 0-max in 0.1s, it can be increased 2'000'000'000, if anything I go down from 10'000 . obviously once loaded the acceleration will depend on the load.Quote
The answers will dominate what the best control architecture is!
If we assume the answer to 1) is YES (50:50 share is ideal) and the answer to 2) is say 1 second to reach max speed from zero speed
then it's clearly going to be best and easiest to do external speed control, ie to calculate a total torque value, then just split this 50:50 and send out that half torque command to each motor, and you'll need to be able to do this at between 10 and 20 times a second in order to maintain sufficient control bandwidth
This is what I currently do and well it sounds OK when running but updating every 18ms it's you can hear it wobble. The test rig is inherently very wobbly and certainly a worse case scenario (by accident haha). If I increase the update speed it does not necessarily make it better. I can err on the rapid updates with fast change rates, but this can just get silly as really I'm at the point of updating a system that does not have the finesse so fast that a human can't hear it not working right. Alternatively I update less frequently so that the sound of it changing speed is maybe accepted as it deals with a load change at a slower rate. if the load was to be changing as it gets to the new settling torque then maybe that would combine to a smooth ride but the load will be totally unknown and believe it or not 1000 steps of torque are not enough and my simulated 2000 steps still not enough.Quote
There are other options which could be possible but which very much depend on the system dynamics, for example putting both in local speed control mode, but calibrating the PIDs differently to avoid detructive interference (you can have one motor doing all the P and one doing all the I for example)
The other question is what is fundamental oscialtion frequency of the system, ie you say the drives are "elastic", what is the natural frequency of this and will you control system operate above or below it (it really can't operate IN this zone!) Now if the load is varriable, then that no-go control bandwidth zone can be quite wide, so care will be required. For most mechanical systems, it's generally preffered to be above the natural frequency as normally things get "less stiff with time / condition / load" etc
The final question is
"How critical is the speed control accuracy and convergence" Ie, At what point does it actually matter that the speed is "wrong"? If you're making a machine to stir custard, then clearly, you've probably got a lot of tollerance to varriable speed, but a system to drive an elevator full of people, less tollerance. As you know the application, you can make some qualified estimation of the errorband/deadband that your system can tollerate, and this will drive the mechanical and software/controls architecture as appropriate...
Ideally each motors torque should be matched although there is plenty of acceptable tolerance. Basically as they act on from the two sides of the load via a rubber interface there is give but I don't want all the power coming from one side. Speed changes do not need to be rapid, 0-full speed can take several seconds and the speed input would be left constant once the machine is going so a torque controlled motor that updates fast enough can, I think, easily keep up and I suspect that the motor drivers speed control will be much less lumpy than mine as it has access to 65536 PWM steps for current/torque control rather than the puny 1000 steps that I have from the outside plus it's had way more development put into it than I ever could.
Speed controlled the machine runs nicely, it's just that the load will never share.
-
If you cope with the motors not sharing torque ALL the time, then this (not sharing) may be ok as long as you calibrate the control systems not to fight each other!
Persumably at high loads on the machine, you need both motors to supply enough torque/power to keep the load moving, but you could cal the aggressiveness of the PID so really the second motor only joins in when the load exceeds (or gets close too) the limit of the first motor. If you use a primarily Proportional control, there has to be a speed error at all times (because the Poutut term = error x Pgain), So the level of speed "sag" is going to massively increase after the first motor controller hits it's torque limit (which you could artificially limit to below it's max rating if you were worried about motor thermals).
So if the absolute speed of the system is not that important, you could effectively calibrate the PIDs to not share, and make one motor do most of the general speed keeping and the other motor add torque when required. Again this comes back to one in local speed control, one in local Torque control mode in effect.
Given that you get a feedback of motor torque, you could calibrate the second PID as a much more relaxed (perhaps no I term at all) controller, and then you external controller could actually send it an increasing speed setpoint which would have the effect of increasing it's torque output as it's speed error grows. That speed target could then be calculated by your external master controller based on a long term average motor torque, ie
Say your set point is 1,000rpm (for example)
Send 1,000 rpm target to motor 1, which has I term set to drive machine to 1,000 rpm
Send 1,000rpm target to motor 2, see what amount of torque is is adding as a ratio of the torque being generated by motor 1, and send a higher or lower value to add a relatively slow "balancing" offset. In all cases, both motors are in speed control and so the high speed velocity control is local and in the primary control loop. You will need to low pass filter and average the two feedback torques from motor 1 and motor 2, and have some form of "Gain table" to calculate a suitable adder to the speed target for motor 2
Of course, if you find it enough to have a single drive in speed control, then that long term average "balancing" value can be calulated and applied in the torque domain, ie you take the feedback torque from motor 1, and send it to motor 2, but have a trim value that lets you balance things out as necessary at a slower rate. -
Ok, i'm gonna ask another "stupid" question: Does the system actually NEED two seperate motors? It's going to be cheaper, simpler, and more robust to just fit one motor to do the work if you can!
Ie, rather than have to invent some complex control archecture to suit some dynamic load you may never get a chance to properly validate, just simplify the system to one drive node!! -
Ok, i'm gonna ask another "stupid" question: Does the system actually NEED two seperate motors? It's going to be cheaper, simpler, and more robust to just fit one motor to do the work if you can!
Ie, rather than have to invent some complex control archecture to suit some dynamic load you may never get a chance to properly validate, just simplify the system to one drive node!!
hahahahahahahahaha, you know me, if I could have, I would have. Various factors drove the 2 motor solution. It was mechanically simpler (yes I still have that problem where the electronics fixes the mechanics problem but I get some thanks now) and we struggled to get powerful enough motors, both single and dual have been used in the past, with hydraulic motors they are plumbed in series and yes I considered that electrically as well.
The drives have many settings and bits of information available. and looking around the internet I have seen some examples of how these sorts of drives are used to construct complicated machinery with the control being offloaded to the motor drives. For example conveyor belts is where I first heard of this speed control one motor and have one or more torque controlled helper motors. Our application is similar. another was a paper mill with one roll being unwound onto another with a motor winding and another holding back the unwinding roll with a torque that it calculates from the output of a pressure sensor on the paper connected directly to it rather than through a main controller.
So I realized that I have been missing a trick with these motors worrying about if my little 48MHz M0+ micro can keep up with all of the messages on the bus that I need to do really fast control, I should simply let the motors work for me and just send the sync message as fast as I like as I don't have to process much data coming back. The motor drivers have a 120MHz ARM M4 each.
At first I wondered why on earth I would want to know the motors target_torque, all I care about is that I sent it a torque_demand and that it gives me what was demanded of it, if anything I would only use the actual_torque value to see what is happening. Now that I start to see how these drives can be used it makes sense.
If I can have the speed controlled motor change speed at a rate of 0-max in 5s that is well slow enough I think for a motor that is taking the target_torque of that motor to keep up would be easy enough. With sync messages sent every few ms long before the speed controlled motor has finished making an adjustment if it is transmitting it's target_torque the helper motor matches that. This should mean the speed motor now sees less load so adjusts to suit. I don't know how far into the future the tarqet_torque is but after a few cycles I would expect the two motors to work together quite well as the speed motor quickly gets used to the reduced load. It would really be about that first cycle where the torque motor has to come in and the speed motor gets a bit of a surprise. once both have a similar torque value I would hope that the speed motor would start to see half the load as the required change in load would be quit slow. -
I forgot to explain that 2 driving outputs are required. So a single motor would mean complicated gear boxes/chains whereas the dual motor means that it's a simple gear box so less space taken up and minimal mechanical complexity to go wrong. The positions of the motor/output transfer moves to accommodate different situations so a single motor solution would bring a lot of extra complexity in joining two drive outputs together but not rigidly.