• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1996 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.

How to stop false trips from DesignDrive IDDK current sensors and other trip issues.

Adam Stevens53
Intellectual 600 points

Hello,  I have been going through the build steps of the IDDK systems and had several issues with the HVDMC_Protection module. 

1.  I am getting false trips from LEM and SHUNT comparators.  I am not even using the LEM current module but if I leave the LEM trip enabled it trips on BUILD2 when I increase the Vqtesting by a small amount.  I tested this by disabling all the other trip modules except the LEM.  I also have the same false trips when using only the SHUNT comparator trip.  In BUILD2 when I increase Vqtesting to .12 from .1 I get the trip.  The current in the graph window is not anywhere close to the limits set.  I increased the limits to like 6 and 4090 and still get the trips.

2.  I posted on another forum about how I thought the INPUT1SELECT from pin 40 the hardware trip should be set to input 2 of MUX1 not input 1 (i.e. EPwmXbarRegs.TRIP4MUX0TO15CFG.bit.MUX1 = 2 not 1).  However when I make this change in the code, the hardware still trips like I would expect but the trip flag is not raised.  If I clear the trip flag then the inverter is reset and begins working again even though the trip flag itself was never set.  Why is the trip flag not triggered when I change the input of MUX1 from 1 to 2 and can you verify that in fact the input to MUX1 should be input 2 not 1?

Thanks,

Adam

  • 0
    Intellectual 600 points

    Can anybody give a response on this?  Thanks

  • 0 in reply to Adam Stevens53
    Intellectual 600 points
    Well, I realized that the code is probably correct. However, I get false trips even when I use a dc power supply. If I test the Shunt Adc with the low threshold set to 401 I get a trip when the adc is still reading in the 500s. Then with the actual motor the trips occur only with a very slight change in current. The false trips are occurring with the compare module.
  • 0 in reply to Adam Stevens53
    TI__Mastermind 27240 points

    Hi Adam,

    Apologies for the lo...ng delay and appreciate your patience. We worked on this problem and figured out a solution.

    1. To start with the easy answer, your query on MUX select for EpwmXbar, 

    EPwmXbarRegs.TRIP4MUX0TO15CFG.bit.MUX1 = 2.

    If you look at the table, it does say 2, but to select that you should enter 1. The values are 0,1,2 and 3, not 1,2,3 and 4.

    2. Your main query on current tripping for even very small current change, and even at low currents:

    The problem is because the digital filter is not properly initialized for the low comparator output. Hence the TRIP is responding to glitches from this comparator. This can be fixed by adding the following lines of code to CmpssConfig()

    // Configure Digital Filter

    //Maximum CLKPRESCALE value provides the most time between samples

    v->CTRIPLFILCLKCTL.bit.CLKPRESCALE = clkPrescale;

    //Maximum SAMPWIN value provides largest number of samples

    v->CTRIPLFILCTL.bit.SAMPWIN = sampwin;

    //Maximum THRESH value requires static value for entire window

    // THRESH should be GREATER than half of SAMPWIN

    v->CTRIPLFILCTL.bit.THRESH = thresh;

    //Reset filter logic & start filtering

     v->CTRIPLFILCTL.bit.FILINIT = 1;

    // Configure CTRIPOUT path

     //Digital filter output feeds CTRIPL and CTRIPOUTL

    v->COMPCTL.bit.CTRIPLSEL = CTRIP_FILTER;

    v->COMPCTL.bit.CTRIPOUTLSEL = CTRIP_FILTER;

    You can insert this code right after the CTRIPHxxxx initialisations.

    We will fix this in our next release. Thanks for your patience once again.

    Regards,

    ramesh

  • 0 in reply to Ramesh Ramamoorthy
    TI__Mastermind 27240 points
    Adam,

    Forgot to mention - add the following code in the CMP_DIG_FILTER() module

    v->CTRIPHFILCLKCTL.bit.CLKPRESCALE = clkPrescale; /* Max count of 1023 */
    v->CTRIPHFILCTL.bit.SAMPWIN = sampwin; /*/0x1F; */
    v->CTRIPHFILCTL.bit.THRESH = thresh; /*/0x1F; */

    This is needed to change the values during debug.

    rgds,
    Ramesh
  • 0 in reply to Ramesh Ramamoorthy
    Intellectual 600 points

    Thank you so much Ramesh.  This is a big help.  I look forward to trying it as soon as possible.

    There is one other small problem with the code that I have been able to work around but could not pinpoint the source of the issue.  In build4, the motor spins in the wrong direction thus giving positive feedback and being unstable.  In build2 I checked the direction of the position feedback to make sure it was ramping with the generated ramp signal.  In build4 the positive speed reference spins the motor in the negative direction.  I fix this by putting a negative in front of the speed feedback term and it seems to work fine.  If I put the generated ramp signal in as the position feedback build4 spins the motor in the expected direction and the speed control is stable.  

    Can you give me suggestions as to why the positive speed reference in build 4 is spinning the motor in the negative direction?

    If it would be better for me just to start a new thread about this issue please let me know.

    Best,

    Adam 

  • 0 in reply to Adam Stevens53
    TI__Mastermind 27240 points
    If the sense of position feedback is same as position reference in level 2, then it should be fine in level 4. I tested now and is fine.

    I am reproducing the position sense code snippet below

    // Reverse the sense of position if needed - comment / uncomment accordingly
    // Position Sense as is
    //posEncElecTheta[QEP_POS_ENCODER] = qep1.ElecTheta;
    //posEncMechTheta[QEP_POS_ENCODER] = qep1.MechTheta;

    // Position Sense Reversal
    posEncElecTheta[QEP_POS_ENCODER] = 1.0 - qep1.ElecTheta;
    posEncMechTheta[QEP_POS_ENCODER] = 1.0 - qep1.MechTheta;

    If you did comment the right code out, then it should work fine.

    rgds,
    ramesh
  • 0 in reply to Ramesh Ramamoorthy
    Intellectual 600 points

    Ramesh,

    I looked at the changes to the code you suggested but there are no changes.  This code is already found in the original code and this is the code that generates the false trips.  Can you please double check the difference between the code downloaded from control suite and the suggested changes?

    Also, as far as the motor spinning in the wrong direction in build 4.  I have tried this on two different kits with the same result.  I find it strange in the currentSensorSuite that you pass the current sense for phase leg V back to current_sensor[SHUNT_CURRENT_SENSE-1].As.  One would expect phase U to go back to A.  and likewise you have current feedback for W going back to the current sense for B.  One would expect V to go back to B.  

    Another point of confusion is that from your space vector generator you send the Tc duty cycle percentage to PWM1 which and the Ta duty cycle percentage to PWM2 and Tb duty to EPWM3.  I believe EPWM 1, 2,3 should be referring to phases A, B and C respectively.  I think this in combination with the current sensor feedbacks going to the wrong phases is causing the motor to spin in the wrong direction.  

    In build 2 I had to comment out the:

    posEncElecTheta[QEP_POS_ENCODER] = 1.0 - qep1.ElecTheta;
    posEncMechTheta[QEP_POS_ENCODER] = 1.0 - qep1.MechTheta;

    and uncomment: 

    posEncElecTheta[QEP_POS_ENCODER] = qep1.ElecTheta;
    posEncMechTheta[QEP_POS_ENCODER] = qep1.MechTheta;

    In order for the position feedback to match the generated ramp. 

    Did you also make this change?  So after this change in build2 the ramp and the feedback match.  But then when I go to build4 the motor spins in the opposite direction.  This is the motor that comes with the kit and I have made no other changes.  I have seen this on two kits so I am surprised that this is not also the result you are seeing. 

    I appreciate any help you can provide.

  • 0 in reply to Adam Stevens53
    TI__Mastermind 27240 points
    Adam,

    I meant to send the low comparator trip settings for current limiting, but I had sent the high comp settings which was already in the original code.

    Here is what I wanted to send:

    // digital filter settings - LOW side
    v->CTRIPLFILCLKCTL.bit.CLKPRESCALE = clkPrescale; // Max count of 1023 */
    v->CTRIPLFILCTL.bit.SAMPWIN = sampwin; // # of samples in window, max : 31
    v->CTRIPLFILCTL.bit.THRESH = thresh; // recommended : thresh > sampwin/2

    When included in CMP_DIG_FILTER() , it will help tune negative comparator filter from the debug window.

    As far as relating V and W to A and B, so long as it is consistent, it doesn't matter. We followed the following during current sensing:
    V relates to A
    W relates to B
    U relates to C

    When we compute duty cycles and generate PWMs, we follow the same logic in backward sense C --> U, A --> V, B-->W. Due to some code legacy and pcb layout constraints, we chose to follow this convoluted approach but it is not difficult to get over.

    We did not see any issue in level 4. Suspect some logic reversal during your experiments.

    Let me know.

    Best regards,
    Ramesh
  • 0 in reply to Ramesh Ramamoorthy
    Intellectual 600 points

    Ramesh,

    I tried the digital filter settings you suggested and everything works well.  Thanks for your help.  This is a great addition to my code.

    -Adam

  • 0 in reply to Adam Stevens53
    TI__Mastermind 27240 points

    Glad that you can move forward now. 

    rgds,

    ramesh