What is more efficient to read the rotor position, in the kit TMDSHVMTRPFCKIT?

Hello,

What do you mean by efficient?  Efficient in terms of cost? Cycle-counts? Precision?

With your motor will you be doing position control, speed control, etc?


Thank you,
Brett

Thanks Brett,

With my engine I want to make the speed control. Efficient in terms of system accuracy and robustness and ease of implement and debug.

When performing reading position through the position sensor using the QEP. Due to noise cause errors in reading, despite filtering, these errors are hauled.

So I'm testing the operation of the system with the SMO (Sliding mode rotor angle estimator).

Regards,

Jose.

Jose,

In terms of accuracy, robustness and ease of implementation I would suggest using a sensor.  The only fault situation to be concerned with is if the encoder/sensor itself fails which should be relatively uncommon.

The QEP interface should be robust and I am surprised you are seeing issues.  I will ask another person more familiar with the kit to comment on the issue you are seeing.

An SMO estimator should be also be pretty accurate and we have many customers (across many industries and power levels) who prefer to use SMO due to various reasons (cost being one of these).  In applications which need to be extremely robust, we've even seen some customers implement an SMO estimator to check the sensor/encoder input to increase reliability!


Thank you,
Brett

Jose,

If interested in pursuing the QEP issue, could you provide some more details on the noise issue you are seeing with the QEP?  Are you seeing the issue at low-speed/high-speed/all-speeds?


Thank you,
Brett

Brett,

I use all speeds, but at high speeds PI regulator is working properly. The problem is when the speed reference is below 50% in unit 0.5.

The regulator is not working properly, seems to occur by reading encoder though not sure. In any case the engine starts giving jerks or jumps as turning and jumping the current error that protects the system.

I tried to filter the encoder error and I have adjusted the offset (simulating the system in matlab then testing it in the kit), but this error does not stop, so I want to see how it behaves over the SMO.

The system works well at high speeds, but not at low or medium.

Thank you very much,

Jose.

Jose,

This issue seems like a PID tuning issue rather than an issue relating to the QEP.  As an FYI, tuning the loop at low speed is typically more difficult than high speed.


Thank you,
Brett

Brett,

Yes but you could say what the steps for tuning the PID. I've done the steps that come with the development kit and still not working right.

Thank you,

Jose.

Joining this conversation late...

In my opinion, encoders should only be used for position control or very low speed / zero speed control*.

Today's software rotor observers/estimators - especialy TI's FAST - are as accurate as required for these applications and actually provide increased reliability by removing the wiring and mechanical coupling of an encoder. It should also be noted that most encoders are measuring a mechanical position and not an electrical one, so any offset is going to produce decreased efficiency and control capability.  You also get into issues with phase lag in counting pulses at very low and very high speed, which are more easily compensated for in a fully software based system.

* And zero speed / low speed control will soon belong to software modules as well thanks to techniques like High Frequency Injection that we are releasing.

Hi Chris,

you mentioned new software modules release (HF injection). will it be a part of FAST (so it's in the ROM) ? if so, how can we upgrade the MCUs we already have ?

thanks

Mojo,

This HFI-IPD library is for controlSUITE only at this time. 

We are finishing a version that is compatible with MotorWare and InstaSPIN-FOC and InstaSPIN-MOTION solutions. It will also be provided under separate license and will work automatically in user code when placed in the MotorWare structure (it is NOT in the ROM and there are NO planned silicon ROM updates). 

The versions for controlSUITE and MotorWare are different, though based on similar concepts, and will have slightly different capabilities.  We are testing the MotorWare version now with some lead customers and I expect we will start making it available more broadly before the end of the year.  Obviously with the MotorWare version it will be released to automatically work on multiple hardware (DRV8312, DRV8301, HVMTR, any new HW), variable frequencies, and all chips that support the InstaSPIN from ROM concept.

Hi Chris,

thanks for clarifying that out...

what about identification of motor inductance for IPMs (or other salient pole motors) ? will we see such a module ? It would have tremendous value for the high-end control systems...

Thanks for your great support !!