• State
  • Locked Locked
  • Replies 20 replies
  • Subscribers 82 subscribers
  • Views 3383 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.

Avoiding code hang?

Bill McConnell
Intellectual 960 points
Other Parts Discussed in Thread: BOOSTXL-DRV8305EVM, LAUNCHXL-F28069M

There seems to be a way to hang the control code and I'd like to find out if my approach is causing it.

To get this hang, I first clear gMotorVars.Flag_Run_Identify while the motor is spinning. My inertia and the coast mode means the motor spins down over a few seconds. If I set gMotorVars.Flag_Run_Identify with a target speed lower than the current speed, the system usually becomes unresponsive. I have not seen this behavior when the target speed (gMotorVars.SpeedRef_krpm) is set to a value higher than the current coasting value.

In this hang, both gMotorVars.Flag_enableSys and gMotorVars.Flag_Run_Identify are still set and there is no UserErrorCode or VelCtlErrorID. This problem happens on debug and flash runs and a restart is enough to bring the system back.

Note, I set gMotorVars.Flag_enableSys = true by default and the user flips a switch that sets gMotorVars.Flag_Run_Identify to start the system. Not sure if this is relevant or the best intended customer interface.

  • 0
    Intellectual 960 points
    FYI, the reason I am setting/clearing gMotorVars.Flag_Run_Identify is that is the signal that I will expect customers to use to enable motor operation. A panel switch is tied to that signal. Thanks, Bill.
  • 0 in reply to Bill McConnell
    Intellectual 960 points
    More information: After this hang, the GPIO and potentiometers that I've setup are still updated and can be read in the CCS Expressions window. It looks like it is just an InstaSpin hang.
  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points

    what are the status of the Flags for RsRecal and OffsetCalc during this experiment?

    it looks like you are using InstaSPIN-MOTION, which lab?

  • 0 in reply to ChrisClearman
    Intellectual 960 points

    Hi Chris,

    Both Flag_enableRsRecalc and Flag_enableOffsetcalc are always zero. My program is a customized version of lab 5e.

    I noticed also that while user level GPIO, such as FWD/REV, and ADC inputs, like Speed, are reflected, i.e. can be read/updated, in the Expressions debug readback pane, none of the motor control parameters are updated.

    Edit:as an example:

    1. Flag_enableSys is set. The user sets Flag_Run_Identify via a GPIO on a switch to start the tool.

    2. He runs the motor at 1000 RPM

    3. He turns it off (clears Flag_Run_Identify) and the motor slows on coast

    4. He sets the speed lower (pot on panel) then turns it back on before motor stops coasting

    5. System is unresponsive and continuous to coast down. Must be power cycled at customer level to restart.

  • 0 in reply to Bill McConnell
    Intellectual 960 points

    Another way to illustrate this hang is to set SpeedRef_krpm to your lowest operational value, then mechanically spin the motor beyond that speed and assert Flag_Run_Identify.

    Should I be using a different signal than Flag_Run_Identify to start my product's operation?

  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    Run_Identify is fine

    I have done the same experiment with a fan and an -FOC project (lab10a) and it works fine for me. I can run at a high speed, Run_Identify = 0, set a low speed, Run_Identify = 1 and it takes over.

    technically if you were going to support this feature you would want to implement a full flying-start capability. this is to catch control of an already spinning motor.

    I wonder in your case if this has something to do with MOTION. Let me forward to Adam.

    Also are you sure the code "hangs"? During the coasting can you see the output of the speed controller / input to Iq_Ref_A? When you enable to you see a change?
  • 0 in reply to ChrisClearman
    Intellectual 960 points

    >I have done the same experiment with a fan and an -FOC project (lab10a) and it works fine for me. I can run at a high speed, Run_Identify = 0, set a low speed, Run_Identify = 1 and it takes over.

    It's intermittant. Did more testing. The only constant is that Run_Identify must be set while the motor is spinning. It seems to happen more readily on the upper speeds and when the speedref is set lower between toggles of Run_Identify.

    I haven't fully characterized the problem, but in about half the times, the control doesn't go out to lunch. A few tests showed that It doesn't take many attempts to see the problem, though.

    >technically if you were going to support this feature you would want to implement a full flying-start capability. this is to catch control of an already spinning motor.

    Thanks. It is not a feature, more like a sequence that a user might do by chance. That is how it was discovered.

    >I wonder in your case if this has something to do with MOTION. Let me forward to Adam.

    Might be. I'm wondering if there is a quick way to convert my program to InstaSPIN-FOC.

    >Also are you sure the code "hangs"? During the coasting can you see the output of the speed controller / input to Iq_Ref_A? When you enable to you see a change?

    I think the control hangs. After it occurs, I can see the speed is still being measured, as well as torque, but the motor is in coast more (undriven). It shows zero krpm when stopped and an increase in speed if I spin it with my hand.

  • 0 in reply to Bill McConnell
    Intellectual 960 points
    I verified the problem on FOC and Motion labs (5e and 3b). Just load program and get spinning, set speed at max, and via watch window, toggle Run_Identify ON/OFF/ON. Control hung first time on both labs. The motor was spinning during the toggle.
  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    I'll have to look at this when I get into the office next week, but I've never seen this happen.
  • 0 in reply to ChrisClearman
    TI__Guru** 119590 points
    I was running a drone motor today at a customer and tried to test this as best I could.
    I was using proj_lab10a.
    I had RsRecal and OffsetCal flags disabled.

    when toggling Run_Identify flag while running it would always spin back up, but if previous running at a high speed it will make a big "kick". This is because when you re-enable there is a step input at the speed controller with the previous speed.

    with this type of motor it spins down very quickly to zero speed so I wasn't able to set a new lower speed in-between toggles

    as mentioned I tried this with a fan motor - which spins down very slow - last week and couldn't duplicate. but it should give the same "kick". I haven't been able to replicate any sort of hang.

    either way, to fully overcome this you need to do some sort of flying start. at a minimum your code needs to look at the estimated speed and set that as the speed_ref to start before setting the new speed command. that will get rid of the "kick".
  • 0 in reply to ChrisClearman
    Intellectual 960 points

    I've experimented and found how to best replicate.

    The bug occurs most when the speed is at maximum and Flag_Run_Identify is toggled OFF then ON (while motor spins).

    I couldn't get a hang when starting at a speed of 66% of max speed. However, at 80% of maximum speed, or higher, the hang frequently happens.

    I also replicated it with a new 28069 ISO card. I never got the kick you saw, it either continued working or hung. By hung, I mean it started coasting and would not go the speed set by speedref.

    Thanks, Bill.

  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    I'm using proj_lab05b (speed control, modulation max 0.5)
    boostxl-drv8305evm + LAUNCHXL-F28069M

    with 18V supply the max speed with Anaheim motor is just under 4 KRPM

    Once running I disable RsRecal, OffsetCalc, and ForceAngle

    I have the acceleration set to 4 KRPM/s and I tried different accelerations as low as 20 RPM/s

    When I toggle Run_Identify the motor slows down to essentially zero before I can toggle it on again, but then accelerates to ~4 KRPM. I never see any issue.


    I would need to find a motor with a larger inertia that coasts to test this fully...but again, I tried with a Fan at a customer 2 weeks ago and I never saw the issue.
  • 0 in reply to ChrisClearman
    Intellectual 960 points
    Thanks, Chris. The acceleration shouldn't matter since toggling Run_Identify is effectively stopping control, then restarting. I tested/replicated a few more times today using a set speed (my nameplate maximum: 1.5 krpm), OFF, then ON. The slower the time between toggles, the less likely. However, when the motor is spinning quickly, then a quick toggle (my RPM probably only went down to above 1400), reliably knocks power control out.

    Also, the slower the constant speed, the less likely. I only got reliable hangs at 90% rated and above (1350+ for this 5 pole-par motor).

    I am not trying to make a feature out of this. It is an operational bug that some customers might see. All it takes is for them to shut down, then quickly remember they had more sanding to do. That is how it was discovered. Today, I tried gating the Run_Identify, only allowing it to be asserted if the speed is below about 10%, but, of course, I need it to be on before the speed measurement. I am considering a timer lockout, so if Run_Identify was recently cleared, then it cannot be active for some period, this might look like a negative customer feature, though.

    I cannot see what I might be doing to cause this behavior. I'll bet you, or someone, can replicate with minimal effort, especially if their system runs at a fast speed with some inertia.
  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    Bill,
    I think what you are seeing is a torque pulse from your speed controller. You turn it back on, the speed is lower than the target, and the speed output (Iq_Ref_A input) quickly saturates. This is where you could use a "flying start". Where you take over in torque mode, commanding the same Iq_Ref_A as you currently have Iq_Fdbk_A. And setting the output of the speed controller to match this Iq_Ref_A before enabling the speed control.
  • 0 in reply to ChrisClearman
    Intellectual 960 points

    I don't think so, because the original, and maybe most reliable, manner to recreate this problem involves running at high speed, clearing Run_Identify, quickly lowering target speed, then re-asserting Run_Identify. I just re-verified this by running at my max 1500 RPM, clearing Run_Identify, lowering target to 20 RPM, then re-asserting Run_Identify. The system hung -- it simply coasted down, no longer responding to speed commands.

    This bug happens whether the target speed is higher or lower. It most likely occurs when at high speed, clear Run_Identify, and while the inertia keeps the system running above 90% max speed, set Run_Identify. Thanks!

    edit: fixed max speed

  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    with my motor I don't have time to set a new target speed before it's already at 0 speed.

    let me see if I can find a motor with larger inertia...it may be some days.

    regardless, I still don't think this is a "bug". I believe it is more of something that needs to be handled in your control system with something like flying start logic
  • 0 in reply to Bill McConnell
    TI__Guru** 119590 points
    Bill,
    I found a good motor to test this....but now need to order a different EVM. This will probably have to wait til next week, but I will get to it.
  • 0 in reply to ChrisClearman
    TI__Guru** 119590 points
    Bill,
    I ordered the HVKIT I needed and received confirmation, but haven't seen it ship yet. I'm checking on where it is in transit...
  • 0 in reply to ChrisClearman
    TI__Guru** 119590 points
    Bill,
    I tested this.
    I don't get the same type of failure as you. When I reenable while the motor is still at a relatively high speed I do get a current control "squawk". This is because the initial speed command (coming from the trajectory generator) when you restart is near 0 (or a ramp from zero) so the current controller nearly maxes out. Luckily the motor I'm using is pretty low current, so they system doesn't lose control. However, I could see how it would in a larger current motor operating closer to the HW limit.

    As I said above, the issue is one that we solve by implementing "flying start".
    This means reading the speed estimate and setting the speed controller with a reference equal to the estimate, and preferably an output equal to the required IqRef_A. Then enable the controller.

    once you take over like this you can then set a new speed with acceleration.
  • 0 in reply to ChrisClearman
    Intellectual 960 points

    Thanks, Chris. I just returned and will need a few days before getting to this. Bill.