A few problems regarding motor configuration

pastebin is blocked by TI

please just attach / upload here on e2e

besides that, you can run 5a in torque mode so you take the speed loop tuning out of the equation. This can give you an idea if it is an issue with speed loop tuning or something in the main sensorless / torque control.

Hello Chris,

thanks for your fast reply. Definetly will give this a shot on monday.

I didn't see that I'm able to attach files, but I'll do so now.

So here is my user.h file.

Regards,

Patrick

63811.user.h

Patrick Schneider1 said:

The first problem is that if the wiring to the motor is cut and "no motor" is connected the software doesn't recognize, it still sends the motor identified flag and reasonable speeds/currents, despite the fact that the connectors are open. Is there any possibility to recognize such a case?

You would have to add this detection / logic yourself.

You can use Rs Recalibration to know if the resistance has changed, but it can also be used to see if the motor is even connected. For example, if the motor has been shorted, you would get a very low Rs. If the motor is disconnected, you get a very high Rs.

This is how you enable it:

        // enable/disable Rs recalibration during motor startup
        EST_setFlag_enableRsRecalc(obj->estHandle,true);

If this needs to be detected while the motor is running, I would consider a few ideas:

1. Look at the current measurement. Even if the motor has no load at all, measuring all zeros in the currents is a flag that the motor is not even connected.

2. Enable Rs Online feature (explained in lab 7 of motorware). If Rs goes too high, the motor was disconnected, same if it goes too low the motor has some sort of a short.

Patrick Schneider1 said:

first we are not sure whether our user.h settings match the motor to 100% so it would be kind of you if you could quickly verify that these configurations matches (both attached at the bottom).

They look reasonable, though the IQ_VOLTAGE is higher than it needs to be.

Have you used the spreadsheet mentioned on

page 33 of

C:\ti\motorware\motorware_1_01_00_13\docs\labs\instaspin_labs.pdf

C:\ti\motorware\motorware_1_01_00_13\docs\labs\motorware_selecting_user_variables.xlsx

Patrick Schneider1 said:

Second is it possible and reasonable to change Ki and Kp values while the motor is running, so perhaps we have to implement a few sets of values for different speed ranges? Would that be helpful or not?

Of course. This is called "gain staging" and is almost always required with a PI speed controller for various speeds, movements, to handle different loads, etc.  This can be tricky, which is why we offer the SpinTAC speed controller (and motion suite) in InstaSPIN-MOTION which is available on the larger F2805x and 6x solutions.  It typically only takes 1 setting to work across all motions.

Hello Chris,

first thanks for your fast and detailed reply. We did some testing and came up with a few things:

ChrisClearman said:

You can use Rs Recalibration to know if the resistance has changed, but it can also be used to see if the motor is even connected. For example, if the motor has been shorted, you would get a very low Rs. If the motor is disconnected, you get a very high Rs.

We need to detect the missing motor while running and we need a fast startup so rs recalc is not an option (unfortunately).

ChrisClearman said:

1. Look at the current measurement. Even if the motor has no load at all, measuring all zeros in the currents is a flag that the motor is not even connected.

Currents with a low motor speed (around 200) and currents with no connected motor are about the same, so no detection is possible.

ChrisClearman said:

2. Enable Rs Online feature (explained in lab 7 of motorware). If Rs goes too high, the motor was disconnected, same if it goes too low the motor has some sort of a short.

I didn't have the time to try it so far, but Rs Online is always zero when reading it. Perhaps it has to be enabled somehow. Will take a look at that.

ChrisClearman said:

Have you used the spreadsheet mentioned on

page 33 of

C:\ti\motorware\motorware_1_01_00_13\docs\labs\instaspin_labs.pdf

C:\ti\motorware\motorware_1_01_00_13\docs\labs\motorware_selecting_user_variables.xlsx

Didn't get notified about the motorware update so I didn't know this spreadsheet. But it is really helpful, motor is running slightly better with the new configurations. Thank you for that! We are using motorware 1.01.00.12, is it worth digging through the labs and update files to ...13? As I said we already modified the labs to our needs, so are there any crucial bugfixes to consider?

ChrisClearman said:

Of course. This is called "gain staging" and is almost always required with a PI speed controller for various speeds, movements, to handle different loads, etc.  This can be tricky, which is why we offer the SpinTAC speed controller (and motion suite) in InstaSPIN-MOTION which is available on the larger F2805x and 6x solutions.  It typically only takes 1 setting to work across all motions.

Unfortunately InstaSPIN-MOTION is not an option here so we have to go with gain staging. Is there - out of your experience - a better way than finding values empirically?

As I said before, thank you very much for your support so far and have a nice day!

Regards,

Patrick

Patrick Schneider1 said:

We need to detect the missing motor while running and we need a fast startup so rs recalc is not an option (unfortunately).

use RsOnline from proj_lab07

Patrick Schneider1 said:

We are using motorware 1.01.00.12, is it worth digging through the labs and update files to ...13? As I said we already modified the labs to our needs, so are there any crucial bugfixes to consider?

it is quite easy to move to a new revision of MotorWare and then just transfer your own files to the new revision. I would suggest doing a diff on the hal.c/.h files you are using vs. in _13 to see where you need to combine.

you will move over your user.h proj_lab##.c (or if you have renamed something else by now, whatever your main project is) and perhaps if you have added additional variables to main.h

But there wasn't any large changes in _13. You can review the Revsiion History through MotorWare.exe --> Resources.

Patrick Schneider1 said:

Didn't get notified about the motorware update

did you sign up for "Alert Me" on MotorWare webpage?

Patrick Schneider1 said:

a better way than finding values empirically?

For gain staging you will need to do empiracal testing or simulation (assuming you have a good plant model, which is rare).  In MotorWare _13 instaspin_labs.pdf there is a new write-up on finding initial Speed PI tuning in proj_lab05b that will help get a good first starting point.

Hello Chris,

I tried to copy all changes from motorware 13 into my project and add rs online features from lab 7.

After doing so compiling threw an error because some code wouldn't fit into load regions. So I checked if something with the command file also had changed. Well it did and after also changing my old *.cmd file to the new in motorware 13 I get the following error when trying to load my program:

C28xx: Flash Programmer: Error encountered when writing to flash memory
C28xx: GEL: File: C:\Users\Patrick\Documents\BHTronikRepository\sw_emb_canbldc\app_io\project\Flash\canbldc_io.out: Load failed.

Obviously s.th. with the flash loading/programming configuration, but as I am relatively new to these controllers could you point me into the right direction?

I don't really have an idea. First thought maybe your overall code overflowed the memory map, but I think that should have been caught by the compiler.

I use _13 with the 27F and haven't had any issues with flashing the device with any labs.  The overall code of all the projects fits in much less than half the flash. 

Hello Chris,

this is starting to get to a serious problem because we can't work with the code any more. I'm out of any ideas, I erased every Cache of CCS, even did a reinstall. Project files between my project and lab10a are exactly the same, Command file, library files and target config are also just 1:1 copies.

I still get the load error. When I diff the map files I see that the c_init is on a different starting address which is odd. Shouldn*t that be always the same?

******************************************************************************
TMS320C2000 Linker PC v6.2.5
******************************************************************************
>> Linked Mon Jul 14 12:09:38 2014

OUTPUT FILE NAME: <canbldc_io.out>
ENTRY POINT SYMBOL: "_c_int00" address: 003f7ef7

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
PAGE 0:
OTP 003d7800 00000400 00000000 00000400 RWIX
CSM_RSVD 003f7f80 00000076 00000000 00000076 RWIX
BEGIN 003f7ff6 00000002 00000002 00000000 RWIX
CSM_PWL_P0 003f7ff8 00000008 00000000 00000008 RWIX
IQTABLES 003fe000 00000b50 00000000 00000b50 RWIX
IQTABLES2 003feb50 0000008c 00000000 0000008c RWIX
IQTABLES3 003febdc 000000aa 00000000 000000aa RWIX
ROM 003ff27c 00000d44 00000000 00000d44 RWIX
RESET 003fffc0 00000002 00000000 00000002 RWIX
VECTORS 003fffc2 0000003e 00000000 0000003e RWIX

PAGE 1:
RAMM0_M1 00000000 00000800 0000061f 000001e1 RWIX
P_DRAML0 00008000 00001000 000007b0 00000850 RWIX
FLASHA_D 003f4000 00007f80 00004336 00003c4a RWIX

SECTION ALLOCATION MAP

output attributes/
section page origin length input sections
-------- ---- ---------- ---------- ----------------
.pinit 1 003f4000 00000000 UNINITIALIZED

codestart
* 0 003f7ff6 00000002
003f7ff6 00000002 CodeStartBranch.obj (codestart)

.reset 0 003fffc0 00000002 DSECT
003fffc0 00000002 rts2800_ml.lib : boot.obj (.reset)

vectors 0 003fffc2 00000000 DSECT

.ebss 1 00000000 0000041f UNINITIALIZED
00000000 000002b6 canbldc_io.obj (.ebss)
000002b6 00000004 rts2800_ml.lib : _lock.obj (.ebss)
000002ba 00000004 : exit.obj (.ebss)
000002be 00000002 drv8301.obj (.ebss)
000002c0 0000015e hal.obj (.ebss)
0000041e 00000001 cpu.obj (.ebss)

.stack 1 00000420 00000200 UNINITIALIZED
00000420 00000200 --HOLE--

ramfuncs 1 003f4000 000007b0 RUN ADDR = 00008000
003f4000 00000515 ctrl.obj (ramfuncs)
003f4515 0000023b canbldc_io.obj (ramfuncs:retain)
003f4750 0000003e flash.obj (ramfuncs)
003f478e 0000001e hal.obj (ramfuncs)
003f47ac 00000004 usDelay.obj (ramfuncs)

.text 1 003f47b0 000039c8
003f47b0 00000ed8 fast_public.lib : ctrl_priv.obj (.text)
003f5688 0000093f hal.obj (.text)
003f5fc7 0000053f canbldc_io.obj (.text)
003f6506 0000045e user.obj (.text)
003f6964 0000043b bhtbus.obj (.text)
003f6d9f 0000039f ctrl.obj (.text)
003f713e 000002f0 pwm.obj (.text)
003f742e 000002b7 drv8301.obj (.text)
003f76e5 000001f5 adc.obj (.text)
003f78da 0000012f clk.obj (.text)
003f7a09 00000125 gpio.obj (.text)
003f7b2e 00000104 pie.obj (.text)
003f7c32 000000ef sci.obj (.text)
003f7d21 000000a9 spi.obj (.text)
003f7dca 0000005b pll.obj (.text)
003f7e25 00000047 pwr.obj (.text)
003f7e6c 00000046 wdog.obj (.text)
003f7eb2 00000045 offset.obj (.text)
003f7ef7 00000044 rts2800_ml.lib : boot.obj (.text)
003f7f3b 0000003d timer.obj (.text)
003f7f78 00000038 fem.obj (.text)
003f7fb0 00000035 canbldc_io.obj (.text:retain)
003f7fe5 0000002a rts2800_ml.lib : l_div.obj (.text)
003f800f 00000027 cpu.obj (.text)
003f8036 00000024 osc.obj (.text)
003f805a 00000021 filter_fo.obj (.text)
003f807b 00000021 rts2800_ml.lib : fs_toul.obj (.text)
003f809c 00000021 : memcpy_ff.obj (.text)
003f80bd 00000020 flash.obj (.text)
003f80dd 0000001d rts2800_ml.lib : fs_tou.obj (.text)
003f80fa 0000001c cpu_usage.obj (.text)
003f8116 00000019 rts2800_ml.lib : args_main.obj (.text)
003f812f 00000019 : exit.obj (.text)
003f8148 00000010 memCopy.obj (.text)
003f8158 0000000a svgen_current.obj (.text)
003f8162 00000009 rts2800_ml.lib : _lock.obj (.text)
003f816b 00000008 CodeStartBranch.obj (.text)
003f8173 00000005 pie.obj (.text:retain)

.cinit 1 003f8178 000000a8
003f8178 0000008e canbldc_io.obj (.cinit)
003f8206 0000000a rts2800_ml.lib : _lock.obj (.cinit)
003f8210 0000000a : exit.obj (.cinit)
003f821a 00000004 drv8301.obj (.cinit)
003f821e 00000002 --HOLE-- [fill = 0]

.econst 1 003f8220 0000008c
003f8220 0000005c fast_public.lib : ctrl_priv.obj (.econst)
003f827c 0000001c ctrl.obj (.econst)
003f8298 00000008 user.obj (.econst)
003f82a0 00000004 bhtbus.obj (.econst)
003f82a4 00000004 canbldc_io.obj (.econst)
003f82a8 00000004 hal.obj (.econst)

.switch 1 003f82ac 0000008a
003f82ac 0000008a bhtbus.obj (.switch:_BHTBUS_handleSciARx)

And after erasing the flash it stops with an error at this window:

I really hope you're able to help here!

Hello Chris,

so I spend the day working on this issue. I rebuild the whole project from scratch, slowly adding my code until the point everything crashes.

It seems that not the code itself, but the size is the problem. When the image exceeds a certain amount of space (seems to be past 3F8000) the load fails. I attached  some map files which are working and not working. I generated them by commenting some lines of code to influence the code size.

So it seems that the code is getting too big, in spite of the fact that it should only cover half of the available space at the moment.

Is this a known bug and is there any fix to it?

and here the files5224.mapfiles.zip

Hello Trey,

thanks for your answer.

Well the problem is the old linker file (the original one from _12) is not working any more for me with the _13 updates. It produces this error:

"C:/Users/Patrick/Documents/BHTronikRepository/sw_emb_canbldc/app_io/sw/ide/ccs/cmd/f2802x/F28027F.cmd", line 139: error #10099-D:
program will not fit into available memory. run placement with
alignment/blocking fails for section ".stack" size 0x200 page 1. Available
memory ranges:
RAMM0_M1 size: 0x600 unused: 0x1e1 max hole: 0x1e1
error #10010: errors encountered during linking; "canbldc_io.out" not built

>> Compilation failure
gmake: *** [canbldc_io.out] Error 1
gmake: Target `all' not remade because of errors.

**** Build Finished ****

I attached the linker file I am using, it's the original one from _13.

BR,

0724.linkerfiles.zip

It - in my opinion - has to do something with the codesize because the original labs from _12 and _13 are all working and running with the corresponding linker files.

As I said earlier it doesn't matter which code I am adding, but over a certain edge it starts to fail, but technically it should fit into the memory, so I really don't know.

let us check this, but I suspect you're correct.

Did you make this change and it worked?

Thanks Trey for your answer!

Unfortunately it was a development version while testing because of the linker file, so it's not reconstructable. R.I.P. to the 4 brave controllers then.

Well the linker file itself looks not so bad, just the starting address of pages A_D is wrong. Or did you find any other prolems? It works so far for us with the change I mentioned.

BR,

Yeah, boards are fine, replacing the controllers is a bit of a work though.

Thanks for the tip with splitting, perhaps I'm gonna try that!

BR,