• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 84 subscribers
  • Views 862 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LAUNCHXL-F28379D: Delay in control loop

Danilo A.
Mastermind 28730 points
Part Number: LAUNCHXL-F28379D

Hi Team,

We would like to ask your help regarding the issue encountered by our customer while working with electric machines and switching converters using LAUNCHXL-F28379D Launchpad in Simulink. Here are the details,

Basically we are running into some issues with what we think is some sort of a delay in our control loop on our inverter running an F28379 launchpad
We have debugged everything we can think of and haven't found the source, so I thought maybe I can get in touch with someone who is specialised in this area

We are running a 3 phase motor (6 switch) with FOC with closed loop current control and an absolute position encoder (using BiSS-C communication)
When a motor is unloaded and you send a speed request (i.e. low Q axis current) you expect to see mainly Q axis voltage (from the changing PM flux)
At low speed this is the case (most of the required voltage is Vq)
however as speed increases, the D axis voltage component grows significantly implying some sort of delay in the control loop, for example position of current delay

We tried a feed forward phase compensation for encoder offset and found that the required offset rose linearly with speed which is what I would expect for a constant delay
we calculated it to be ~300us significantly longer than what the CPU profiler and other tests we have run are telling us (5us for position feedback delay, 15us for current control loop at the moment)
so maybe 20us delay if the timing of position and current is correct

We have tried both with monitor and tune, as well as with build and deploy (using external CAN comms)
Switching frequency 20kHz (but also tested 40kHz)
Have also tested gate driver delays (i.e. from PWM to VGS going high) a few microseconds
have also tested current feedback delay (i.e. through the filtering circuit in hardware
used both CPU profiler and setting GPIO pins high and low at function start and finish (with custom C code) to check delays
both were similar (12.5us GPIO) and 14us from profiler
the delay is pretty constant, a little bit of noise but that's probably more due to current ripple and it is reasonably repeatable, although I think it may drift a little bit

Regards,

Danilo

  • 0
    TI__Intellectual 2910 points

    Hello Danilo, Please refer to the below article from Dave which explains the cross coupling between axis. Feed-forward decoupling may be needed to limit the d axis voltage. 

    https://e2e.ti.com/blogs_/b/industrial_strength/posts/teaching-your-pi-controller-to-behave-part-ix

    Also will let the experts on E2E forum to further comment on this issue.

  • 0 in reply to Navaneeth Narayanasamy
    TI__Mastermind 28730 points

    Hi Navaneeth,

    Thank you for your response. Here is the feedback of our customer,

    Unfortunately this is not what is causing the issue.
    Apologies if my explanation wasn't clear enough, this issue happens in steady state - it is not a transient coupling.
    Additionally, it is happening while completely unloaded (driving the motor externally with another motor and controlling for 0 current) and the required offset to compensate for this effect is linear with speed (hence the assumption that it is a near constant delay).
    If you have a look at the equations listed in the link and set Iq = 0 and Id = 0, the only flux source still present in the equations is the (constant) permanent magnet flux, and therefore Vq should rise with speed, Vd should stay 0.
    Regards,
    Danilo
  • 0 in reply to Danilo A.
    TI__Guru* 92130 points

    Danilo,

    Is the delay in the communication link - i.e. could it be caused by the length of the cable from the encoder to the C28x?  

    -Lori

  • 0 in reply to Lori Heustess
    TI__Mastermind 28730 points

    Hi Lorie,

    According to our customer,

    We have calculated the line delay from the encoder, it is nowhere near the delay we are (effectively) seeing, which is estimated at around 300us.

    Regards,

    Danilo

  • 0 in reply to Danilo A.
    TI__Guru* 92130 points

    Thank you, Danilo

    It looks like they are doing everything I would suggest to debug the issue.  My understanding is

    • the delay is constant
    • it is not correlated to any external variables (i.e cable length, speed / loading of the motor, etc)
    • using the profiler has not pinpointed  any specific piece of code

    An thought - instead of using the profiler - use a GPIO toggle before/after a specific piece of code and see if it turns up monitoring a scope while running the system.  If it does, then where the GPIO toggles could be modified to try and narrow it down.  

    I suggest this because I'm wondering if run/stop to use the profiler is not showing the issue while a GPIO may show a different story.

    Is the time-critical code running completely from RAM?  check the .map file generated by the linker to be certain. 

    Regards

    Lori

  • 0 in reply to Lori Heustess
    TI__Mastermind 28730 points
    Hi Lori,
    Here is the response of our customer,
    Yes, the understanding is correct.
    Unfortunately we have already tested with the GPIO pins and the results are similar to the CPU profiler (12.5us vs 14us).

    We have even tested sending SPI request (to simulate encoder position) and timing that to achieve a certain PWM output change, and that was also very short (~18us or so).
    As far as I can tell, the code is not running from RAM, but I'm not too sure:
    Regards,
    Danilo
  • 0 in reply to Danilo A.
    TI__Guru* 92130 points
    Danilo A. said:
    As far as I can tell, the code is not running from RAM, but I'm not too sure:

    Yes, the addresses you have circled are in flash.  Are these functions part of the time-critical loop?  Running from flash will be slower than RAM so if they are part of the time-critical loop, I suggest moving them to run from RAM.  

    It is confusing that the profiler, and GPIO toggle is not finding the delay.  The only things I can think of is the profile/GPIO test has not included the code that is causing the delay or the delay depends on something external that does not occur when the code is profiled. 

    -Lori  

  • 0 in reply to Lori Heustess
    TI__Mastermind 28730 points

    Hi Lori,

    We have had a look at the RAM functionality and have a new build which we will test soon, however we don't think that this is responsible for what we are seeing.
    I would also like to point out again that the "delay" is just a suspected cause. The symptom is that we are seeing increasing D axis voltage as RPM / frequency increases, symptomatic of a constant delay.
    At this point we have tested almost everything, including phase delay of hardware filters etc. 
    The only thing we haven't tested is the physical delay from the encoder itself, however we've used 2 different encoders and by datasheet both should have a much smaller delay than what we are seeing. The encoders are absolute magnetic encoders - RLS RM44s utilising BiSS-C, the datasheet says they latch position when the SPI line activates (so our measured delay is about 5us).
    With the above in mind, can you think of anything else that could explain this situation?
    Would it potentially be possible to organise a short meeting to discuss this?
    Regards,
    Danilo
  • 0 in reply to Danilo A.
    TI__Guru* 92130 points

    Hi Danilo,

    Let me check with some colleagues for their input and get back to you by end of Wednesday US time.

    Regards

    Lori

  • 0 in reply to Lori Heustess
    TI__Guru* 92130 points

    Danilo,

    Here are some questions and experiments to help debug further:

    1) How did the user change the d/q-axis voltage?

    • By using the external communication link to set the reference d/q-axis current, speed, or position?
    • Or by changing these variables within CCS?

    2) Did the user try to tune the gains of the current/speed/position regulators to see if the delay time will be changed?

    3) Try to run the motor using open-loop without position sensor to verify if the delay is from the control loop and current sensing feedback.

    Generally, the delay will be from the control loop, position sensor, current sensing circuit.

    Best regards

    Lori