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.

BOOSTXL-DRV8320RS: FOC GUI

Guru 54087 points
Part Number: BOOSTXL-DRV8320RS

Why is there no RUN, STOP or ClearFault/s buttons in the InstaSpin FOC GUI? I have reviewed the SDK lab 1(hal.c) and lab 5 motor identification but dislike the new GUI without certain motor controls. How can the GUI values be set and get my motor running in few seconds from CCS debug Resume? That in my mind seems off putting even dangerous with custom high voltage motor inverters via XDS110 JTAG speed.

The GUI seems difficult to assemble ones own ideal motor controls around existing SW structures of modified labs in order to accelerate production. That is the key concept behind launch pads and composed driverlib SW so most engineers can easily thrust variable control into an HID.  

Also checked new BoostXL SDK for any PDF describing newer FOC spin GUI procedures only to find F280069 PDF control suite SW. Have installed the newer motor SDK to C:ti\ and imported the first few labs and even that took over an hour to accomplish.

Our older control GUI (below) worked via ICDI, clicking Stop button twice is emergency stop panic. We later updated to Nextion 3.5" LCD and that works great with PMSM to migrate newer LCD into SDK HID.

 

  • Gl,

    This GUI is written and supported by the C2000 team, I will forward your post to their attention.

    Please note that the post will stay in this location.

    Regards,

    -Adam

  • The onboard debug probe on all C2000 controlCardsor LauchPads is an isolated interface, the XDS110 uses isolated USB as the link http://www.ti.com/tool/LAUNCHXL-F280049C. The GUI is an open-source software based on GUI composer, that enables the designer easily to add themself functionality according to the applications. And the designer can design their own GUI using other interfaces like UART, USB.. across an isolation barrier as you want to recommend.

    You might take a look at the following link if you want to understand about GUI composer.

    https://dev.ti.com/gc/designer/help/GC_UserGuide_v2/overview.html

  • The onboard debug probe on all C2000 controlCardsor LauchPads is an isolated interface, the XDS110 uses isolated USB as the link http://www.ti.com/tool/LAUNCHXL-F280049C. The GUI is an open-source software based on GUI composer, that enables the designer easily to add themself functionality according to the applications. And the designer can design their own GUI using other interfaces like UART, USB.. across an isolation barrier as you want to recommend.

    You might take a look at the following link if you want to understand more about GUI composer.

    https://dev.ti.com/gc/designer/help/GC_UserGuide_v2/overview.html

  • Yanming Luo said:
    You might take a look at the following link if you want to understand about GUI composer.

    Did you not see the GUI posted above?

    Yanming Luo said:
    The GUI is an open-source software based on GUI composer, that enables the designer easily to add themself functionality according to the applications

    Point was about user confidence to run costly HW from InstSpin GUI limited controls and CCS debug to start or stop motors run state. CCS IDE is bound by the host computer bus speed and many other complicated systems, easily disconnects USB or DAP at times. We might like to remove BoosXL and jumper to our HVDC inverter to test particle application is possible well before writing complicated code and new control GUI. If large motor don't produce good lab results it ain't going to after!

    I like the new DRV hardware but find the method to control the labs motor run / stop troubling.  User need to keep focus on GUI and CCS debug seems a bit taxing and expect host computers are robust or abundant in all global work places!

     

    Yanming Luo said:
    You might take a look at the following link if you want to understand about GUI composer.

    Obviously ignoring GUI posted above and make excuses to put proper run stop emergency controls into GUI of SDK. Please remove the overhead of CCS debug from having full control of the very costly BoostXL RDK and only allow JTAG STOP update debug register view. That will remove the smoke factor when CCS debug looses USB or JTAG connection but the GUI composer run time remains connected!

  • Yanming Luo said:
    The onboard debug probe on all C2000 controlCardsor LauchPads is an isolated interface, the XDS110 uses isolated USB

     Guaranteed to work up to what DC bus voltage without BoosXLDRV-8320RS and CCS debug as is? That is part of the issue to use CCS debug as start and run time motor transients have been known to cause USB 2.0 connection issues on the host side not just the target.

  • >> Also checked new BoostXL SDK for any PDF describing newer FOC spin GUI procedures only to find F280069 PDF

    Can not locate the updated PDF for the labs procedures was not in the BoostXL SDK documents folder as expected - that is a must have. I checked in F280049c documents folder too but that is just a launch pad quick start PDF.

  • Finally found the labs user guide buried inside HTML lookup and linked to folder way down in the SDK tree common\\\\\. Sort of expected to find guide it in Docs folder but rarely click on html files avoid adware Trojans virus.

  • The point is after the labs are run there is no bench mark page, besides labs after 1 & 5 take long time after reading overview PDF. The better solution is to use the powerful features of GUI composer v1.1 built into earlier versions of CCS and bounce that junk cloud composer. Each lab can be a separate tab in the GUI invoked from boxes of flow chart with a run and stop button. How quick can you click on GUI stop button with mouse pointer? Good as CCS debug has become (v9.1) it still has random USB issues with host computers OS. 

    GUI invoked save function automatically update user.h upon success of lab 5. The labs java.script watch window can output variables to another tab, get rid of CCS debug control. CCS debug should be the last resort when things go wrong after the labs have run well and or fail. Customers may likely move away from launch pad for custom PCB design migration older hardware. Make it easier to migrate other MCU class over to C2000 in this way. The JTAG launch pad direct run time GUI control is a much safer way to approach SDK labs with expensive BoostXL-DRV8320RS motor driver. Perhaps several labs can be flashed onto launch pad and accessed via individual GUI tabs become active or remain read only if not loaded.