CCS/TMS320F28379S: C2000™ Position Manager SinCos Library

Stefan,

The speed is determined from the QEP. If the speed is constant the mode change should not happen. When the sincos software switches from mode 1 to mode 2, position information comes from the QEP, not the sine and cosine inputs. My suspicion is you have noise coming in on the QEP inputs causing an count error so the QEP thinks the speed is faster than it is. This would also explain the jumps between modes when measurements change to/from the QEP. Could you begin by checking for the presence of spikes or glitches on the sin/cos inputs, as well as at the comparator outputs?

Regards,

Richard

Hi Richard,

we have had spikes in the analog sin/cos inputs, but we could already eleminate them with a good ground to the shielding. But we have still the two problems.

The mode change only happens if the mySincos.qepcnt changes from mySincos.qmaxpos to 0, could there be a error in speed calculation when this jump in qep count occurs?

Regards,
Stefan

Hi Stefan,

Coarse angle is derived from the software in modes 0 & 1 (low & medium speed respectively), and from the QEP in mode 2 (high speed).  A difference between the two implies the software method of measuring coarse angle is missing cycles.  As the speed mode transitions from 1 to 2, a difference between the two would result in an apparent 'jump' in measurement, I think. 

Missing cycles might happen if there are insufficient samples per sine wave period.  Sample rate is fixed, so as the shaft speed increases you get fewer and fewer samples per period, and eventually you reach a point where the software method cannot reliably detect which quadrant it is in.  I suggest making "mchg12" smaller to reduce the shaft speed at which the switch from software to QEP measurement takes place.  You probably should also reduce "mcgh01" at the same time (it must always be the smaller of the two).

Please let me know how you get on.

Regards,

Richard

Hello Richard,

if found my error for the difference of the analoge and qep counter error!
As discribed in the readme.txt:

The two structure elements which should be loaded manual after init function with this value:
mySincos.qmaxpos = 511; -->WRONGmust be IQ15!!!
mySincos.qep->QPOSMAX = 511;
I had a mistake in the datatypes mySincos.qmaxpos is IQ15! If i load it with IQ15 datatype the both counter are running with same values.

So the error of the two different qep counts is resolved, but i still have the problem with the change of mode when qep set to 0 occures from QPOSMAX -> 0. The mode change only happens if the mySincos.qepcnt changes from mySincos.qmaxpos to 0. The mode changes from 0 to 1 to 2 and back 2 to 1 to 0, it will stay in mode 0 until the qep count changes again from mySincso.qmaxpos to 0. This happens every time the limit from qep is reached and is set to 0. Do you have an possible answere for this behavior?

Regads
Stefan

Hello Stefan,

Thank you for pointing this out. Mode selection is based on the difference of two consecutive QEP positions, so the wrap-around is causing the mode to change. For some reason it looks like this was not noticed before.

I can't think of a simple work-around which doesn't require a library code change. The special condition of wrap-around needs to be detected and allowed for in the lib code. I'll try to get to it this week and update this post when I have more information.

Regards,

Richard

Hi Richard,

this sounds good to me, we are looking forward to your update, of the mode change during the wrap-around of counter.

I have attached a signal graph with the steps during the mode change.

green line: elecrtical theta

blue line: mySincos.fTheta

violet line: mySincos.qepcnt

As you can see we have sometimes 1 Step difference between qep-counter and the mySincos.fTheta, after the mode change wrap-around. This will be corrected at the next wrap-around. This is only very seldom, not with every wrap-around. Do you have a possible answere for this?

Regards,

Stefan

Hello Stefan,

I did not see the count error in testing, but it may be related to the behaviour on wrap-around you pointed out previously.  If so, I doubt there is a clean solution which does not require modification of the library code.  I have coded the change and will test it shortly but it is unlikely we'll just release a sincos library update in it's current form.  Instead, I expect the library source will be released in controlSUITE soon.  I have coded this change so it will be in that release.  Like everything else, there is a process to go through, so it may be a few weeks before the update finds its' way onto the web, but once it does you'll have full visibility of what's happening inside the library.

In the meantime, it is possible that you might be able to improve matters by enabling the PCO (i.e. overflow) interrupt from the QEP and forcing the mode to zero inside an ISR, but I have not tried it and am by no means certain it will completely cure the problem.  Sorry not to have a definite quick fix for this.

Regards,

Richard

Hello Richard,

i can also offer you the possibility to test the changes in the SinCos software as a beta tester. So I can give you a direct feedback as to whether your changes fix my two problems.

Regards,
Stefan

Stefan,

Thank you for your offer.  I have sent you a private e2e message so we can discuss this further.

An open source version will be in the next controlSUITE release, either in December or January.

Regards,

Richard