Controlling parameters with other parameters as inputs, MotorWare 14

is the update for pulling the gMotorVars.TorqueXXX variable in a different place in the control system in MW 14 vs. the version you last used? Do you see it updating? I know we changed the getTorque function.

You are automatically increasing the speed reference as the torque reference increases? What sort of application is this for?

>is the update for pulling the gMotorVars.TorqueXXX variable in a different place?
There are changes, so I'll look around.

>What sort of application is this for?
It is a benchtop tool that utilizes this relationship under certain conditions. Until the patent is granted, can't say much more

I thought you might comment on the 20 RPM speed. A few engineers said 20 RPM sensorless would not be doable, but the eval kit has performed well at even slower speeds. MW14 seems to do better than MW12, unless it is just wishful thinking.

probably just wishful thinking. 20 RPM doesn't tell me much, need to know the Hz. With large Bemf motors customers have gotten into the 0.2 Hz range. FAST isn't tracking as well as at higher speeds, but it's enough to produce some % of the rated torque still.

While trying out changes, I noticed the warning about lab5e (which I've customized) being compiled with compiler 6.2.3, but I'm using 6.4.4 and assuming it is fine. Does that sound OK?

yes, that's no issue to use the newer compiler

I get puzzling results. The following two lines are in my modified lab5e.c file. It appears like the torque is not getting updates (at least not in the CCS expressions window, plus the speed doesn't change). If I remove the torque_Nm from the argument (i.e. just use 0.02), then the motor spins at 20 RPM and torque values in the expressions window are updated as though in real time.

gMotorVars.SpeedRef_krpm=_IQ(0.02 + (0.01 * abs(gMotorVars.Torque_Nm)));
CTRL_setSpd_ref_krpm(ctrlHandle,gMotorVars.SpeedRef_krpm);

I don't see why this change affects the window update.

did you migrate from version 12 to 14?

in 13 we changed the way we call the flux update, including a new USER_computeTorque_Nm function. Have you added this so that your gMotorVars.Torque_Nm is actually getting updated?

as en example, look in proj_lab03a and search for "torque"

C:\ti\motorware\motorware_1_01_00_14\sw\solutions\instaspin_foc\src\proj_lab03a.c (12 hits)
Line 109: _iq gTorque_Ls_Id_Iq_pu_to_Nm_sf;
Line 111: _iq gTorque_Flux_Iq_pu_to_Nm_sf;
Line 222: // compute scaling factors for flux and torque calculations
Line 225: gTorque_Ls_Id_Iq_pu_to_Nm_sf = USER_computeTorque_Ls_Id_Iq_pu_to_Nm_sf();
Line 225: gTorque_Ls_Id_Iq_pu_to_Nm_sf = USER_computeTorque_Ls_Id_Iq_pu_to_Nm_sf();
Line 226: gTorque_Flux_Iq_pu_to_Nm_sf = USER_computeTorque_Flux_Iq_pu_to_Nm_sf();
Line 226: gTorque_Flux_Iq_pu_to_Nm_sf = USER_computeTorque_Flux_Iq_pu_to_Nm_sf();
Line 420: // get the torque estimate
Line 421: gMotorVars.Torque_Nm = USER_computeTorque_Nm(handle, gTorque_Flux_Iq_pu_to_Nm_sf, gTorque_Ls_Id_Iq_pu_to_Nm_sf);
Line 421: gMotorVars.Torque_Nm = USER_computeTorque_Nm(handle, gTorque_Flux_Iq_pu_to_Nm_sf, gTorque_Ls_Id_Iq_pu_to_Nm_sf);
Line 421: gMotorVars.Torque_Nm = USER_computeTorque_Nm(handle, gTorque_Flux_Iq_pu_to_Nm_sf, gTorque_Ls_Id_Iq_pu_to_Nm_sf);
Line 421: gMotorVars.Torque_Nm = USER_computeTorque_Nm(handle, gTorque_Flux_Iq_pu_to_Nm_sf, gTorque_Ls_Id_Iq_pu_to_Nm_sf);

Yes. I have each of those lines. I should have mentioned that I started with a MW14 lab5e.c and migrated my MW12 stuff over, keeping in mind any syntax/code updates. I also proofed the user.h file by redoing the labs. Thanks.

wont the logic you are using just keep increasing the speed command until the no load torque is saturated?
the torque increases, you increase the speed command, the torque increases...it's a loop.
until the torque stabilizes.

edited: Well, found something interesting!

For the torque/speed increase question: No, since we use this relationship only in a controlled/specific manner/setup. Torque and speed are often looked at as orthogonal parameters in motors, though they are mildly coupled as you noted. So, with a large gain, one could speed up beyond control. This algorithm worked pretty well with MW12.

What I found was when I used a small enough multiplier on torque (0.00001), then the speed was at least reasonable.

Found the torque reading would not update if a field (in this case Flag_Run_Identify) had a live edit in it (as might be expected, though not well known).

EDIT: multiplier dependency remains, but expression non-updating was edited out

A little more info: the calculated torque multiplier should be about 0.5, so the non-working values of 0.0001 or higher are way too low. I wondered if additional inertial torque at initial spinup might be causing some problem, but: 1) it worked on MW12, and 2) I have inertia in the user.h.

Also, I am using a 5 pole pair motor for the moment, so the slowest consistent speed we've seen is about 0.8 Hz, which is quite nice.

I don't see how the value of a constant would enable/disable the updating of the torque variable.

can you try to debug by changing to:
gMotorVars.SpeedRef_krpm_calc =_IQ(0.02 + (0.01 * abs(gMotorVars.Torque_Nm)));

and just updating the SpeedRef (if required) manually?
and then watch the Torque_Nm value to see if just that variable is changing appropriately?
and then if the _calc version is the correct calculation based on that value?

The failure to update the torque variable was due to my filling a field in the expressions window (my previous comment was edited to reflect this).

I tried the suggested line in my .c file (without the _calc ending), the motor just spun very fast, despite the torque values hovering about 0.03 Nm.

I cannot understand my speed ref values being so far out, given they come from the simple equation.

Thanks, Bill

To add to my previous answer, I did try the _calc version, but the debugger could not find it. I searched my entire C-drive for .SpeedRef_krpm_calc, but no hits arose.

you need to define the variable before you compile. That was just an example, you could name it anything.
I was thinking it would be useful to disconnect the effect of the Torque calculation from the logic loop, just to verify the torque portion and then subsequent calculations are correct.

I found a solution, but can only speculate the reasons and have two questions:

This line worked, mostly. It has a gain (multiplier) that is 50 million times smaller than expected (and as compared to the MW12 equation):

gMotorVars.SpeedRef_krpm=_IQ(0.025+0.00000001*gMotorVars.Torque_Nm);

I'm guessing there is a numeric format issue (different Q values?), since the read back torque values (Torque_Nm) should have a 0.5 multiplier to add correctly to the 0.025 kprm constant. If that isn't the issue, than the equation representation of Torque_Nm here differs from that displayed in the expressions window.

1) Any advice on numeric formats for this equation, or do you think the problem lies elsewhere?

2) Related to the above, I wish to not throw away precision in the calculation, is that happening?

Thanks! Bill

Torque_Nm is a global IQ variable.
have you tried using IQmpy()?

Yes, _IQmpy gave puzzling results. Below are two (of many) attempts, but with _IQmpy in general, if my multiplier is below 1.0, then SpeedRef doesn't appear to update at all (doesn't go yellow in the window, just stays at the value of idle); however, once the multiplier goes over 1.0, then the motor spins at max negative speed. Note: I've tried preceding _IQ( at various places. Also, the gain difference between the two below is 4x, but results are well beyond that.

1) No speed update:
gMotorVars.SpeedRef_krpm=_IQ(0.035+_IQmpy(0.5,_IQ(gMotorVars.Torque_Nm)));
2) Speed at max:
gMotorVars.SpeedRef_krpm=_IQ(0.035+_IQmpy(2,_IQ(gMotorVars.Torque_Nm)));

This worked. Tweaking the values in this line to match performance in the other method (straight multiply example a few posts above), required a gain difference. The _IQmpy multiplier was close to the expected value and was 16e6 times higher, or 24 bits. It isn't clear if one performs better than the other. Thanks. I still have a MW12 vs. MW14 question in the next post.

Compared to MW12, it seems like MW14: 1) keeps a constant speed under differing load conditions better (smoother) and 2) is more jumpy when speed is tied to torque; meaning that the idle is rough as is acceleration and speed under load and 3) MW14 seems to have a much quicker response -- as soon as I add/subtract a load, the motor quickly spins up/down and tracks (though with obvious jitter).

This may all be in my mind due to false memories, but any suggestions for the jitter beyond filtering the torque input is much appreciated.

EDIT: fixed last sentence

that's surprising. there was a huge update, lots of minor fixes in version 13. I wouldn't expect any of them to give such different performance that you are seeing though. some did relate to the torque signal/variable though so there could be something there if you are using the torque value in your control loop.

nothing changed in the default controller gains, so there should be no difference between 12 and 13 in regards to controller tuning (which is what it sounds like from your description)

I forgot you were using SpinTAC. They did change the BW variable during this time. It is now fixed, there isn't a multiplier in user.h

There is a parameter: USER_SYSTEM_BANDWIDTH (not USER_SYSTEM_BANDWIDTH_SCALE as mentioned in the current lab guide). It is set in user.h in lab5e. That was the one that differed between my MW 12/14 implementations.