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.

RTOS/TMS320F28069M: Spintac Run time shutdown?

Part Number: TMS320F28069M

Tool/software: TI-RTOS

Hi. I have a working application that I'm adapting to control a sensorless BLDC driving a scroll saw. This program has worked well on a similar motor with a "better-behaved" tool (i.e. the scroll saw probably has more noise on the motor lines). Sometimes, the system just shuts down -- it won't follow the speedref. However, internal variables, the input switches and pots, plus the DCBus reading all show as working. I think the speed control just gave up. None of the gmotorvars errors show problems.

Any suggestions? Thanks.

  • Hi Bill,

    Is the over current to shut down the motor, or other faults? Did you snapshot some current waveform for analysis? Which project lab is your reference? And what work condition will maybe cause the shut down?
  • I'm not clear that it was overcurrent that led to the shut down. Or is overcurrent the only way it would shut down? I modified lab 5e for my application. I did not see any errors detected by SpinTAC, such as UserErrorCode or VelCtlErrorID, and the status variables look OK. I am driving a scroll saw, there is mechanical drive lash and a cyclic variation in load. The shut down has happened about 6 times now and it sometimes (or, always?) coincides with a loss of control of the motor, sometimes the motor seemed to oscillate quickly forward/reverse. Unfortunately, I cannot readily repeat the problem.

    If you have suggestions, or know of an error that I should monitor, I'm all ears!
  • Also, the scroll saw is a standard "decent quality" saw that we placed a BLDC motor in for testing. Using this setup, I could not do the lab 5c inertia test. I think the Fwd/Rev lash and scroll saw mechanics are too coarse for SpinTAC. I guesstimated inertia and friction by hand comparison with other known tools. I've been able to successfully run the saw today, but the previous code shutdowns are concerning.
  • Since you was using lab5e before, you had to set correct Inertia, Friction, Bandwidth and Encoder Lines for SpinTAC function. So you have to use lab05c to identify the Inertia and Friction first, and set other parameters based on your system.
  • Yanming said:
    you had to set correct Inertia, Friction, Bandwidth and Encoder Lines for SpinTAC function. So you have to use lab05c to identify the Inertia and Friction first, and set other parameters based on your system.

    Yes. As mentioned, I estimated these parameters, using another setup as a comparison.

    Do you know what makes SpinTAC simply "give up?" Is it just overcurrent?

  • Bill McConnell said:
    Is it just overcurrent?

    In my experience this is occurs when you trigger a tripzone.  The motor suddenly stops and there is no feedback about what happened.

    You can determine that the issue isn't with SpinTAC by checking the value of st_obj.vel.ctl.Out (IQ24) when you are in this condition.  If it is saturated (equal to st_obj.vel.ctl.cfg.OutMax or st_obj.vel.ctl.cfg.OutMin) than the controller is operating correctly and it is trying to push as much current as possible to get the motor to spin.