Instaspin-FOC stability after torque overload

Dhar,

Looks like you have had good success so far!

< I command a speed of 0 rpm (under no load the shaft doesn't move and there is some resistance if I try to turn it)

Yes, this is expected. You can play with the Speed Kp and Ki here at 0 speed.  Kp increasing will make it stiffer. Too much and it will oscillate/shake.  Ki is the "springiness".  With some larger Bemf motors you can actually tune this so you can "wind the motor up" and it will return like a spring.

< I can turn the shaft by hand past a point where the motor controller becomes unstable and no longer maintains 0 rpm when I release the shaft. It sometimes turns backwards, sometimes forwards, and more concerning sometimes vibrates and jerks through different shaft positions.

First, did you disable ForceAngle? When evaluating at zero speed you must turn this off. ForceAngle is only for initial starting from 0 speed and for when you want to generate torque from zero speed (think of a power tool application).  If you leave it enabled at 0 speed it will certainly be more jerky (and when enabled under the zero speed limit setting - which in the GUI is set at 1.6 Hz - FAST feedback will NOT be active).   So please disable if commanding 0 speed and trying to observer FAST behavior.  Recall that FAST is not a zero speed observer. It relies on Bemf, and at 0 speed with no load you have none.  But the larger the Bemf of the motor the better FAST will quickly lock on.  With the DRV8301 and a larger Bemf 24V motor last week we were able to run 3 RPM.  With the DRV8312 and the included motor you can run about 20 RPM.  This is also with VERY poor resolution on voltage for these kits - meaning they are scaled to over 66V and we are only using 24V supply.  Reworking the HW and SW scaling specifically for your motor will improve low speed operation even further.

< This is an 8 pole (4 pole pairs) , 30A motor with a 3200 Max RPM (motor max freq set at 250).
What is the identified flux of this machine?  I think it will be rather high and should perform well at low speeds.

<Kp is automatically set at 3.75 and Ki set at 0.0375 (speed loop tuning)"

Recall that the Speed gains are NOT tuned. It's impossible to tune a speed controller with no idea of the mechanical inertia. The speed Kp is calculated simply based on the MAX_CURRENT user setting, and Ki is scaled off of that. It's a "rule of thumb" which usually is reasonably stable for mid range operation.  Also recall that speed KpKi must be tuned across speeds and loads.  You will have multiple sets of gains and will have to switch them in at different operating points. This is called "gain staging".  It's the managing of this switching that is actually one of the biggest challenges.  To solve this I recommend looking at InstaSPIN-MOTION, which adds Inertia Identification and replaces the KpKi with the SpinTAC Controller.  Typically a single tuning variable (or only 2-3) works across speed/load, even into field weakening (where things get very challenging with a speed PI). It's pretty amazing and makes things SO much easier.

Was there a different expectation for you on what InstaSPIN-FOC and FAST would do for you?

Hi Chris

Thank you for the quick response.

I have the force angle turned off in my test.

Flux shown as 0.0950239 after motor ID.

I did a few screen captures which might help you to see what is happening.

The interesting part is when I ran the test this time I didn't touch the motor shaft, it was unloaded at all times.

I understand the Speed gains are not tuned, but I am expecting the default values to be adequate for this test (please correct me if that statement is wrong).

After running at 30rpm for some time the whole system is stable and smooth.

I then commanded a speed of 0, and as you can see from the screen capture the current ramped up to max (30A) and the speed never got to 0 before I shut it down to stop the vibrations. 

Overall the motor controller does everything I need and expect, except for case of 0 RPM.

If the speed gains are dependent on the mechanical load on the motor to fix this issue then I can't see how it would work. In my intended application the load on the motor may independently and suddenly change while a speed of 0 is required. 

Dhar

Now that is interesting. It's a very pronounced effect that I don't typically see.  I'd like to know if it's real though or just a graphing issue. I don't trus the graphs in the GUI. They are based on a series of buffers and sometimes it seems like they just lock up and hold their value.

Can you try working through the MotorWare labs?  Once you store your offsets and motor params in user.h you can skip to lab9. Once you run lab9 you can look at gMotorVars.gMotorVars.Iq_A through the Expressions View.

Duplicating the issue on the GUI with the DRV8312 and small motor that is included:

At 30 RPM the speed controller is not stiff enough.  Upping the speed Kp would make it stable, but I want to try what you are doing so I'll leave them alone.

At 0 RPM my Iq current goes to 0.5A and just stays there. And actually, if I apply a force CW/CCW the Iq moves +/-.  If I wait long enough it goes away. This Iq I'm seeing is based on the Kp of the speed controller. If I increase Kp this "baseline" current increases as well.

The time it takes to settle back down (the memory) is based on Ki.

If you  increase Kp or Ki too much you will go unstable and everythign will oscillate or hunt.

When I try this in a MotorWare project I am seeing slightly different results. But it can seem to drift into an area where current goes from say 0.01A to 0.4A.  This seems to be the natural effect of the estimator losing it's true bearings w/o any feedback.

I can't duplicate your example of the Iq rising and holding to the max. That is very strange.  Does your motor have a lot of inertia? Or does it have a huge cogging torque?  Trying to hold zero speed, if it actually requires 30A to force rotation I could see it behaving this way.

But to discuss your other points:

"If the speed gains are dependent on the mechanical load on the motor to fix this issue then I can't see how it would work. In my intended application the load on the motor may independently and suddenly change while a speed of 0 is required. "

The speed gains are dependent on the INERTIA of the system and the DESIRED RESPONSE you want to produce to your torque controller for your application.  And yes, these gains MUST be different at certain speed/load points if you want different DESIRED response.

For example, a set of gains that give you a very stiff speed control at low speed will be too aggressive at high speeds, sending you into oscillation.

If you tune your system for high speed performance your low speed performance will be too soft with the same gains.

If you really do need to operate very stiff across a wide range you should 1) use InstaSPIN-MOTION with SpinTAC or at least 2) find out the inertia of your system and take a more mathematical approach to calculating your speed Kp/Ki (see write-up lab5b at back of UG).

Also, one more point as I'm not sure you understand the limitation.  InstaSPIN-FOC should not be used to hold zero speed for an extended time. It just won't work, eventually FAST will lose the angle. If your application needs to stop and apply torque at zero speed you need to either 1) brake the inverter (turn on all high or all low FETs) or 2) use a sensor.  The sensorless estimator - even FAST - is not reliable enough all the time at 0 speed.  You will always get some movement (even if it's just slight).

Hi Chris

I initially found this effect while running lab_05b with my motor and user.h settings for my motor (with tuned KpKi).

I went back to this application with the default settings with the hope that you would be able to reproduce it.

The motor vibration effect is real, the total current I can't be sure about. 

The motor does not have very high inertia. Below is a capture of what happens when I startup

As you can see it takes very little current to get going.

Most of the time it will also go back to 0 and hold 0 without any problems, this unwanted behavior doesn't happen all the time.

Here's a capture of a normal slowdown to 0

Using an encoder is perfect in terms of control, unfortunately due to mechanical restrictions I need the minimum number of wires possible. Eliminating the wires from an encoder or resolver is the reason for testing this solution.

I'm not too concerned about slight movement around 0RPM (it's highly geared so slight movements won't have much overall effect). I am very worried about it turning at 20RPM when I asked for 0 or drawing maximum current for an extended period of time. Also the vibrations are a bit scary, that would probably shake everything to bits.

Dhar

I tried Instaspin-MOTION

The results at 0 RPM seems promising.

Inertia shown as 0.074319

Friction 0.936538

Dhar,

I can't see any reason that the speed controller at 0 speed would command max current (unless you applied a very fast accelerating maximum torque). But to command and then hold like that just doesnt' make any sense from a control standpoint.  The only other item would be if the inputs into FAST (and hence the outputs) just became garbage. This could destroy the angle and speed feedback but I still don't understand why the control system would go into this state with full torque.  I would expect (and have seen) oscillation and instability, but nothing like this with Id still near 0 and full Iq.  I would want to see it reproduced using MotorWare lab before I really bought in that this is what is happening on the signals.

Regardless, I think for your system application you should seriously consider a braking function. When the speed and speedest near 0 just go into a full brake (all low-side on for example) and hold that until a new valid speed command is issued. This is the safest way to hold 0 speed.

Hi Chris

I can reproduce this very easily as follows:

Startup the system with the motor running at some speed above 30rpm.

Set the speedref to 0

Grab the motor shaft and turn it in the forward direction (the direction it would turn when I applied a positive speedref value)

wait a couple of seconds, if it seems fine, repeat. sometimes it takes a few turns before it becomes unstable.

From the demos I've seen it appears your motor is very small compared to mine, this might have something to do with it.

I can get it to happen with the MotorWare lab as well, I just don't know how I would record and upload the values for Iq.

Dhar

Chris

Here's what happens when I run SpinTac

In this case I identified the motor, ran through the inertia test and then on the tuning screen I changed the Bandwidth to 40 and then back to 20 a few seconds later.

In this case Iq will keep climbing until it hits MAX.

The motor itself is not visibly turning.

I can get the same behavior as described in the earlier post if I set the bandwidth to 60 and crank the shaft by hand a few times, then the current will ramp to max very quickly and stay there.

Dhar

Sounds like Rs is overestimated (excessive series resistance?)...

I was able to reproduce this using DRV8312, the GUI, and a different motor (Teknic that ships with Hercules DRV8301 kits. It has very similar parameters to the small Anaheim/Telco motor but it does have a higher inertia which I think has something to do with the results).

I haven't had a chance yet to try this with a MotorWare project, but I believe it will reproduce.

I think reducing the Rs is an interesting idea that is easy to test.  If you don't mind try updating your user.h with an Rs 20% less and see if you can still reproduce.

We have this on our list to look at further, I'm sure we'll solve.

Hi Chris

I tried reducing the value of Rs with RsRecalc disabled.

The system appears to be stable so far.

I expect you would be able to run a similar test with your setup as well to see the results.

Please let me know when you have an idea of what the problem might be so I can decide on how to proceed.

Thanks

Dhar

Dhar,

That's good that it looks promising. I'm setting up a Teknic motor with DRV8301 and will experiment also.

Assuming the Rs is off, then the results kind of make sense. Rs is off, the estimator drifts, the speed estimation drifts, the controller starts generating a torque response but the speed estimated isn't changing. so the torque controller saturates. But because the estimations from FAST aren't accurate you just get rotor lock.  I am a bit surprised that a 20% difference could make this big of a difference, but recall that at 0 speed you have very little reliable feedback into FAST (Especially with the default HW/SW scaling on the DRV8301 kit vs. the motor you are likely using).

The question then becomes

1. why is Rs off?

2. what do you do about it?

on #1, this could be because you estimated with too large of  an RES_EST_CURRENT during Motor ID.  I'm going to experiment with this today to see if I get different results that stop this 0 speed issue from happening.  Another possibility could be that the HW/SW scaling/resolution is off enough in your system that you are getting a value that is off.

on #2 first you want to insure you are getting an accurate value. second - although I dont feel this is a solution in this case - you could run Rs On-line to continuously track resistance changes. I think in a real application you would need to do this as you won't know what has just occured in your system that could have affected your Rs before you got near zero speed.  I still think the better solution is to use a braking feature. When you approach zero speed just brake the inverter (high sides or low sides on). For best start-up on the next event you can also GET the angle from FAST and use that to SET the starting angle on the next start-up.  Even if you leave FAST on while braking I think you may need to seed / SET this angle. Your feedback while braked will likely corrupt FAST.

I'll let you know what I find.

Dhar,

I'm doing some testing. I notice that I can reproduce with the Teknic motor (I'm using DRV8312 kit right now) with default settings.  This sets the Speed Kp = 8 and Ki = 0.08

I notice that I can stop this behavior just by reducing the Ki to 0.04.

I tried this with the MotorWare projects and get the same result.

With the standard MotorWare project (I use proj_lab09 for everything) the default Ki = 0.053 (because the ctrl frequency is 15 KHz vs. the GUI at 10 KHz) but it has the same behavior.  When I reduce this by a factor of 2 I can't reproduce.

So I think the first thing is to tune your speed controller for results at 0 speed if that's required.

I'm going to play around a bit more with this and SpinTAC. 

BTW - enabling Force Angle, you can still load and lock the rotor, but it will break the lock and FAST will find the angle and the control system will continue.

What's interesting is I tried reducing the Rs by about 25% (from 0.46 ID'd to 0.36) and it is much harder to get the rotor to lock (I can't make it happen at 0 RPM even with a large Ki), and when it does (I can make stall it at low speed), it does break the lock itself even w/o Forced Angle.  Not sure what to make of this yet, need to think about it and have some discussions with others.

Ok, some more findings on the 25% reduction in Rs.  This really doesn't fix the issue, and the 25% reduction is not correct.

In my case with the Rs reduced by 25%, at low speed with Force Angle disabled (say 100 RPM) the Torque produced when trying to stall the motor is about half of what can be produced when Rs is at 100%.  This means that the motor is not getting into a place where it can lock up, but it also isn't operating correctly.

And when I speed up the motor with this wrong Rs (say 1K RPM) and try to stall, it can produce enough Torque to lock the rotor.

So all you have done with a lowered Rs is reduce's FAST estimation accuracy and reduced the Torque produced at any speed.

I came into work this morning and it turns out the Teknic motor I was using yesterday was suspected to be damaged (it was marked, I ignored it) once it seemed to perform "ok" across speeds).

So I tested a couple others and confirmed it was. So all of above tests are invalid.

I am testing again now with a good motor (Rs = 0.34 ohm, Ls = 200uH, 0.04 V/Hz)

At 0 speed even with defautl settings I cannot duplicate the issue. It just won't lock up. Same goes for nominal speeds, it also won't lock up.

The only other difference in my test set-up today is I have a newer wall power supply with a ground loop in the wiring. We have seen where noise from the power supply can impact low speed performance (an old analog supply I was using was REALLY bad). 

Do you have another motor to try?  A different power supply?

Hi

I am supplying power with 4 x 12V deep cycle batteries (48V)

The motor parameters are (Rs = 0.15 Ohm, Ls = 503uH)

I don't have a different motor at the moment that I can use. 

Would you be able to go back to the "bad" motor with the new power supply setup and let me know the results.

That way I can either order a new motor or look at my power supply setup.

Thanks

Dhar

Using the bad motor, it certainly functions very poorly with the ID of Rs = 0.45. The lock up isn't AS BAD as yesterday. It will draw max current and then fight through it a bit, I can't get it to just completely freeze like before.

Using the bad motor with normal Rs of 0.35 it actually peforms well and does not lock up at 0 or 100 RPM.

Using the good motor with proper Rs, everything is great.

Using the good motor with Rs of the bad motor (0.45 vs. 0.35), I can reproduce the lock-up situation at zero speed.

So there may some minor dependence on quality of feedback, but the dominant dependence is on the Rs calculation.

The tricky thing for you is, how do you know? If your motor seems to operate well at all other speeds why would you even think that the motor is damaged? 

Hi Chris

I've tried 3 additional motors and they all seem to function properly. The only difference I can see between the "bad" motor and the "good" motors is a higher Rs on the "bad" motor. For now I will use that as an indicator of possible motor fault.

I have another motor which is 24V that I would like to run using the same setup with a 48V supply.

On the GUI I can't see anywhere where it allows me to specify max motor voltage.

1. Is this possible with the GUI?

2. Is it possible with the labs, and if so, what would I need to change?

Thanks

Dhar,

first, why are you going to run a 24V motor at 48V? That will damage the motor over time.

1. The GUI doesn't care about the motor voltage, so yes, if you provide 48V to a DRV board it should work fine.

There is some scaling based off the max voltage that is very critical (there is a very long series of posts on this board that gets into this topic at the end) so it is preferred that you move to the MotorWare based projects as soon as you are able so that you can customize this scaling for your motor, and even better move to custom hardware for ideal scaling for your motor.

2. as long as your HW support the voltage/current range the only changes you would need to make are in the user.h file.  I suggest following the labs, starting at Lab1 to get familiar with the concepts. The write-ups for the labs are at the very back of the UG.

Hi Chris

My Application requires 2 motors to be driven from the same board with a 48V supply.

Only problem is one motor is 48V and the other is 24V

Dhar

Why can't you create a voltage divider for your 24V bus? You shouldn't run a 24V motor at 48V constantly.

Hi Chris

Going back to the faulty motor.

It turns out the added Stator Resistance for the faulty motor was due to additional length of wire between the motor and and controller.

When the 2 motors have the same length of wiring the resistance is the same.

So as far as I can see there is no difference in the parameters, yet one motor doesn't work properly and the other one does.

Do you know what was wrong with your faulty motor to cause this problem?

Thanks

Dhar

No, I'm not sure what was wrong with the damaged motor that was reading too high of Rs. The cable lengths used are identical. Notice that when using the "correct" Rs even the "damaged" motor performed well....so I question if the motor is actually damaged or perhaps there is an issue with the wiring or the connector I'm using.

Hi Chris

We returned the "bad" motor to the manufacturer for diagnostics. 

Now using different motors.

I am still having a number of troubling issues.

1. Using the recently released MotorWare 1.1.0.9 (Aug20th 2013). I have a motor with the following specs.

Rs = 4.49 Ohms

Ls = 0.573 mH

Max Speed = 15000 rpm

Nominal Speed = 8130 rpm

Starting current = 10.7A

Max Cont current = 1.4A

Pole Pairs 1

I attempt to motor identification with the following parameters

Est Current -1

Est Freq 40 (tried different values between 20 and 100 with same results)

Motor Pole Pairs 1

Motor Max Current 12A

Motor Max Freq 250

When the Identify process is complete the Ls_D and Ls_Q are displayed as 5E-10 (some minimum limit?)

The motor does not startup for any speed selected (no load).

2. Using a similar motor to the one described earlier in this thread yields similar result as before, with a speed setting of 0, turn the shaft a few times and it enters some unstable mode, vibrates, jerks, never settles back to zero rpm.

In this case I am using Instaspin Motion, tuning the bandwidth to 30 (no instability, fairly soft, I can turn the shaft about half a turn by hand). I then switch to pi control, using the default gain values. set a speed of 0, twist the shaft a few times.

Any suggestions would be appreciated

Thanks

Dhar,

Let's start with the first issue. It is obvious that your motor is not ID'ing correctly if you are getting 5E-10. That's essentially 0. The lowest inductance I've seen is about 4uH.

So let's solve this issue first.  I notice you are only using 1A for your estimation current. This doesn't seem adequate to get your motor to start-up.  Please comment on if your motor starts spinning during the Ramp Up state and continues for the entiretly of the ID process.  My feeling is that you aren't starting up to spin during ID.

For ID you may also want to try lab 2c in MotorWare version _09. While your motor doesn't have particularly low inductance, this project may help, and it shoudln't hurt.

In the second issue, this could be an issue of the speed controller being overly aggressive (or overly springy if using the PI controller), however I think you should also realize that FAST is not a 0 speed estimator.  In a real application you should not put it in a scenario where it should try to hold 0 speed and have dynamics. The FAST estimator output will certainly eventually get corrupted in this scenario as there isn't enough feedback.  For continous 0 speed sensorless control you will need to use a different technique for the estimation feedback. We recently released a high frequency injection method that works with our controlSUITE eSMO projects and we are in process of doing something similar for MotorWare InstaSPIN-FOC.

1. The motor does spin but not as smooth as I would expect. The problem is the motor has a nominal current of 1.4A and a starting current of 12A. If I set the est current to 12A the motor will overheat.

Raising it from -1A to -2A does change the calculated values of Ls from 0 to 100uH.

2. Fair enough, I have mechanical brakes, was just hoping to use those for long term stops and having the motor provide electrical brakes in the order of 2 seconds or less.

3. When I compare the output torque at low speed against the torque for the same motor using encoder feedback control it seems very low. I tuned the speed gains at what I believe are optimum values, but I can still stop the shaft spinning with my hands. The motor is running at 50rpm, max current set at 30A (which I never see happening, gets up to about 5A) Kp 12, Ki 0.12. This is 4 Pole pairs motor. Something doesn't seem right there.

What is the max current of the motor? You've posted 12, 30, and 40 in varioud posts.

Set your USER_MAX_CURRENT to the actual maximum Iq level of current you want to provide.

1. Once it's spinning it should spin smooth over some speed. For example with a very low inductance hobby motor it will initially spin up and appear jerky at say <50 Hz speeds, but then it will smooth out. We usually ID very low inductance motors in the 80-200 Hz range (10% of rated). Your motor is not high speed though so your 25 Hz ID speed should work just fine and be very smooth.  You should still use 10% of rated current for the RES and IND_EST_CURRENT though.  For your motor is rated current 40A?  Use 4A and -4A.  Does it really take 12A to start the motor unloaded? That seems like a very high % of maximum current.  Regardless, keep increasing RES_CURRENT until you get a stable start-up.

2. In a normal application with a load FAST will hold zero speed for several seconds. I've held static weights for several hours with minimal movement.  Not sure how you are testing the zero speed performance, and what performance you need.  If you need to brake you can also just set all high side or all low side PWMs on. This will make the motor act as a break. You can try it just with an unpowered motor as well, hold all three phases together and you have yourself a brake.

3. First, at 50 RPM your 2 pole motor is running at 0.83 Hz.  This is certainly near the boundry of where FAST can operate.  It's dependent on the Bemf of the motor and the resolution of the hardware/software scaling. Also, do you have ForceAngle enablded or disabled?  It needs to be disabled if you are trying to review FAST performance.  If Enabled FAST feedback willl not be used at speeds <= (USER_IQ_FULL_SCALE_FREQ_Hz  * USER_ZEROSPEEDLIMIT ) from user.h

However, now you are saying this is a 4 pole pair motor, which is completely different....are you trying different motors? This is getting very confusing.

Do you have a power supply that can even source 30-40A?

Low speed FAST performance will also be dependent on the Rs value. If your real Rs value is changing quite a bit the FAST obeserver is going to give faulty feedback.  It would be changing if you are heavily loading the motor and especially if you have a high short circuit current motor where the switching can heat the stator.  In this case you would need to use the RsOnline feature to continuously update the resistance.

Hi

Sorry for the confusion

I am talking about 2 motors.

1. This is a small motor, the specifications are listed above, nominal current 1.4A, starting current 12A, 1 Pole pair.

3. This is the original motor we were discussing, 4 pole pairs, 30A peak. I tried with both Force Angle enabled and disabled and didn't see any difference.

Are you using only the GUI or also a MotorWare project (if so which one)?  Can you attach the user.h files you are using for each of these motors?

The problems I described are all with using the GUI.

We recommend doing performance testing with the MotorWare projects.  The GUI just has so many things in it (plus support for three kits so the scaling can get strange, etc.).  You should take those potentially issues off the table.

You will see better results now using MotorWare version _09 and walking through the labs (launch MotorWare.exe and under resources select the InstaSPIN Project and Labs User's Guide).

You'll want to work through lab 2a/b, 3a/b, and 5b to get to a point where you can play wih the speed control (labs 5c/d/e/f to use the SpinTAC MOTION control).

can you confirm you have a power supply that can source the continuous and instantaneous current demands?

I am running off batteries and cables capable of handling 70A

I will try the labs from _09 and see if there's any difference

Hi 

I test with labs included with _09

Definitely better than the GUI and appears to be better than the labs I was using from _05 for the 30A 4 Pole pair motor.

However, for the single pole pair motor I still have the same problem.

1Pole pair, nominal current 1.4A, Starting current 10.7A, Max rmp 15,000

Using lab_2a to identify this motor

#define USER_MOTOR_TYPE MOTOR_Type_Pm
#define USER_MOTOR_NUM_POLE_PAIRS (1)
#define USER_MOTOR_Rr (NULL)
#define USER_MOTOR_Rs (NULL)
#define USER_MOTOR_Ls_d (NULL)
#define USER_MOTOR_Ls_q (NULL)
#define USER_MOTOR_RATED_FLUX (NULL)
#define USER_MOTOR_MAGNETIZING_CURRENT (NULL)
#define USER_MOTOR_RES_EST_CURRENT (1.0)
#define USER_MOTOR_IND_EST_CURRENT (-1.0)
#define USER_MOTOR_MAX_CURRENT (12.0)
#define USER_MOTOR_FLUX_EST_FREQ_Hz (150.0)

Tried different values for EST_FREQ. Motor parameters not detected correctly, Rs double the number in the data sheet, Ls_D and Ls_Q a factor of a 1000 lower than they should be.

Specifying the correct values and using 5b, the motor starts turning but very jerky and bad speed control.

For Rs recall that our measurement is phase to neutral, most datasheets are usually phase to phase (double). Is it possible the Rs is close?

The Ls is certainly the bigger concer. Very strange that it is struggling so badly as the expected Ls is not what I would consider low at all. It's expected in the 500uH range, correct?

Can you confirm again that the motor starts spinning during EST_RampUp and doesn't stop until RampDown?

Did you try lab 2c to ID the motor?  This is a special lab for low inductance motors, perhaps it will help.

When you try the "correct values" try using the ID'd Rs but your expected Ls.  Set 0 speed, DISABLE forceAngle and let me know how it behaves.

Enable force angle and set 0.5 KRPM.  If unstable try doubling the Speed Kp.  Try Halving the Speed Kp. Let me know how it behaves.

Any chance you want to send me this motor?

Hi Chris

I believe this small motor is damaged.

The Rs reported by the software is twice the data sheet as I mentioned (4x what it should be as you mentioned).

Possibly damaged when I was using the GUI and setting the EST current to 2A, motor got very hot during that phase.

I am waiting for a new sample of this motor to be delivered before I continue.

Hi Chris

One of the problems I still have is starting torque and low speed torque output.

It appears my board is loaded with the 28069M variant instead of the 28069F.

What would be the difference in these two variants when running lab 3c?

Thanks

Dhar

There is no difference running an InstaSPIN-FOC project on 6xM vs. 6xF devices.

For starting torque questions you should review chapter 15 of f SPRUHJ1

Hi Chris

I believe my problems are associated with an incorrect Rs calculation.

Here are the steps and results:

I start the motor under no load with RsRecalc enabled.

Rs Offline returns a value of 0.135 (motor data sheet shows 0.14 for this motor)

Motor starts turning at 30RPM and Rs Online calculation starts up and drifts towards 0.36 (within 10 seconds) and stays there for a while (~30 seconds) before drifting between 0.36 and 0.075.

During that time the motor is not loaded, temperature not changing, motor Iq reporting 0.18. If the motor is loaded it will stop spinning and not restart after the load is removed.

Motor Max current set to 10A (Data sheet states 20A max).

RsOnlineCurrent set to 1A.

I see a similar problem reported on a different thread (slightly different scenario, with 0 speed).

Thanks

Dhar

Dhar,

Any chance you can try this with a known motor, like the Anaheim 24V that comes with our DRV8312 kits?  I think it's worth checking out if you have working hardware and software. It is really strange to see the Rs change that quickly that drastically.

Also, please look at yoru adcBias values and make sure they are consistent from the first time you do a motor ID and that they remain the same in the controller.  Especially the voltage values, I've seen some instances where they are accidently changed in SW and those new incorrect offsets will completely change the functionality of course.

Chris

Unfortunately all the motors I have are 48V.

For this test I always start with a motor ID, I update the watch window with the bias values every 100 control cycles and they never change. My current offsets are around 0.81 and voltage offsets are around 0.14

If I turn off RsOnline and program the Rs value at 0.16 instead of the 0.135 the output torque is much better, but still not perfect.

Have you ever tested with a 48V motor or are they all 24V and below?

Thanks

Dhar

Dhar,

We use RsOnline with 24V motors up to 350V motors typically.  Not suggesting it is a 48V issue at all, I was just hoping you could "reset" and test something that we know works.

I take it this is a very high speed, low Ls motor, correct?  What PWM rate are you running?  When you are running how are your Is, Iq, and Id values looking? Does Id stay near zero? Is your Is staying steady (depending on load) or moving around quite a bit? I'm wondering if your current control is very poor and causing your Rs to vary widely.

Chris

This is a 6 Pole (3 pole pairs), Delta wound motor.

Max RPM 3200

Ls = 0.000538

Flux = 0.097

Pwm rate 15K (CTRL rate same, no decimation)

Running in speed mode (not torque mode)

While running with no load the Iq and Id values fluctuate a bit, not steady, but very close to zero.

Sometimes when a load is applied Iq ramps up to max and stays there even when the load is removed, most of the time Iq will drop back down. This behaviour is dependent on the Rs value at the time the load is applied. When the Rs is at the the high end (0.4 instead of the 0.14) it is more likely to get stuck at full current.

When running this test I do not change any of the Kp and Ki value from the values calculated by the software.

Dhar

Dhar,

It should not be possible that the Rs is changing that much, especially at no load. That makes me very concerned that Rs Online is working incorrectly or that there is a hardware issue with your system.

Regarding the Iq remaining after load removed, this probably has to do with the FAST feedback being incorrect, especially if Rsonline is feeding incorrect Rs values.  It's also possible that your Speed controller is still commanding Iq, that the integrator is saturated.  You can look at the inputs and outputs of the PI controllers to see what is actually being commanded and if that can be tuned with a higher Ki to stiffen the response to react quicker.

Hi Chris

I have the same result running on an eval board as well as a number of our custom boards.

I've also tried with 3 different motors, 2 that have the same specs, all gave the same results (i.e. changing RsOnline over a wide range).

When RsOnline is turned off the Iq does not remain after the load is removed, so I agree that it may be linked to an incorrect Rs value.

I recall another thread with someone having similar RsOnline values fluctuating widely, I don't know if they ever resolved the problem.

Thanks

Dhar

I don't recall another post about RsOnline giving incorrect values.

We use this quite a bit in some very intensive projects so I believe there must be a problem with your set-up for Rs online.  Can you go back through the steps again?

I don't have time to do today, but may try next week on a couple motors with the DRV8301 kit (which I don't think we have used for Rs online quite as much as the DRV8312 or HVKIT).

Hi Chris

I am using the code from Lab 7a for RsOnline Setup

I have the same result using a number of different motors (fluctuating rsOnline between 1/2 and 2x of the offline value) and my own boards.

I noticed changes in the return type of the EST functions in the latest motorware version.

Did anything change in the latest version that might affect this?

Thanks

Dhar

Hi Chris

The other thread I mentioned where someone else appears to the having a similar problem is

http://e2e.ti.com/support/microcontrollers/c2000/f/902/t/293796.aspx

around the last 3 posts on that thread you said you would look into it and get back to them and then the thread went dead.

Thanks

Dhar

Hi Dhar,

Could you please confirm what speed you are running Rs Online? This feature does not work on a motor at 0 speed. For 0 speed recalibration we have Rs Offline, which is done before running the motor, and then, once the motor is spinning, Rs Online can be enabled.

-Jorge