[参考译文] LAUNCHXL-F280049C：RS 阻抗高 ID 电流

jiaxin sun 说：

RS 阻抗和 RoverL_rps 值是否与 BSXL_DRV83xx 芯片栅极驱动器开关特性的设计相关联？

否 如果硬件板上的电流和电压检测信号正确、则与电机有关。

zhengfeng zhang 说：

您是否打算将此示例迁移到客户的主板？

否迁移 LauchXL-F280049c 板的 MCSDK 以便通过3个 ADC 使用3个分流器。 再次添加 BXLS-DRV8320RS 到活动项目属性和许多|||(定义 BXLS-DRV8323RS ). 仅使用 DRV8320来确认定制逆变器的电机 ID、因为 SDK 实验室 IS05存在定制逆变器 RS 阻抗不准确的问题。

请回答一下、您可能哪种 SDK (user.h)#define 或电机 ID 控制器变量会导致定制逆变器中的 RS 阻抗读数非常错误？ 到目前为止的调查似乎表明估算器状态机等待时间(user.c)是主要的可疑部件！

jiaxin sun 说：

 在第一部分上升60Hz 且 USER_MOTOR_IND_EST_CURRENT_A =-0.315期间、二次相电流从 USER_MOTOR_RES_EST_CURRENT = 0.35跃升至 ADC 14安培。 [/报价]

博文上面的注释：饱和电流立即跃升0.4到14.2A、电机剧烈抖动。 为什么 IPark 导致电机 ID IS07出现电流饱和？ TI 工程师是否意识到饱和可能会通过 IPark 发生、并且饱和电流会变得不受约束？ 也许 PLL 或使用 PPB (MCSDK)可以纠正 IPark 的饱和方面、在 PDF 中没有提到？ 为什么在 IS07中用于电机 ID is05的 PARK (PHASOR)和用于电机在线的 IPARK (在 PDF 中没有提到)？

请注意、SDK is05使用 park (相量)用于电机 ID、IS07使用 Ipark 进行电机速度控制。 与 IS07中的斜升电流 PWM 占空比逐渐变大相关。 将电机 ID 代码的 is05 Park 变换代码添加到项目 is07中、控制器不会在线。 无论是谁编码 SDK4.0实验室、都没有保持一致的运行时电机 ID 算法、并且没有在 PDF 文本中披露此类算法以供开发人员知悉。 必须轻而易举地披露快速 ROM 或 LSRAM 库的电机 ID 过程和隐藏库标志状态的所有方面   

            //
            // run the estimator
            //
            EST_run(estHandle, &estInputData, &estOutputData);

            //
            // compute the sin/cos phasor
            //
            phasor.value[0] = cosf(estOutputData.angle_rad);
            phasor.value[1] = sinf(estOutputData.angle_rad);

            //
            // set motor ID phasor in the Park transform
            //
            PARK_setPhasor(parkHandle, &phasor);

            //
            // run the motor ID Park transform
            //
            PARK_run(parkHandle, &(estInputData.Iab_A),
                     (MATH_Vec2 *)&(Idq_in_A))

zhengfeng zhang 说：

否 如果硬件板上的电流和电压感测信号正确，则与电机相关。

此外、之前提到的 PARK (相量)而非 IPark 在一定程度上影响了 ID 过程中的 RampUp 电流、 良好的项目编码不会切换占空比转换、而是保持(main.c)代码构建相同的"所有构建"或"实验室"。 MCSK 中似乎存在相同的电机 ID 问题、需要检查才能在构建中使用任一变换、而不是同时使用两个变换！ 对于用于专有快速库调用的 PARK 与 INVPARK 的比较、我们无法通过 CCS 进行查看、即使在"大纲"视图中也是如此。

电机 ID 过程和运行时电机驱动需要简单的方框图、其中显示每个步进电机 ID 过程所需的变换、未显示 InstaSpin 用户指南 SPRUHJ1I–2013年1月–2021年10月修订。  

[/quote]

jiaxin sun 说：

请回答您是否可能会因为什么 SDK (user.h)#define 或电机 ID 控制器变量导致自定义逆变器中的 RS 阻抗读数非常错误？

您更改了哪些参数？ 请提供有关此问题的详细信息。

识别和运行的进程使用不同的流程。 如前所述、您可以访问通用电机控制实验、该实验可以满足您的要求并节省您的开发时间。

zhengfeng zhang 说：

您更改了哪些参数？ 请提供有关此的详细信息。

所示的 RoverL-rps 电流增益参数不正确、如 SPRUHJ1I–2013年1月–2021年10月修订。 Id 过程不能设置任何 KP/Ki_Id 电流增益的电机 Id 过程、即使在 RoverL_rps 期间也是如此。 此文本仅相对于在线电机、而不是电机 ID。 高度模糊的文本针对在线电机或较旧的 Motorware 套件、并且停留在流程图的中间、其中显示了电机 ID 过程、讨论(user.c)控制器等待时间。 下面显示的 CCS 调试所允许的唯一电机 ID 设置(KP/Ki_spd)、任何大于0.0的值(红框)都将导致 RampUp 期间出现高饱和电流。

重复一遍、 在(EST_Rs_State_RampUp)期间、任何大于0.0的 KP/Ki_ID >0.0都会导致快速饱和电流、这两个在线电机控制器值都必须清除。 ROM 估算器应清除这些值、因为任何人期望嵌入式 ROM 代码自动执行。 KP/Ki_ID 在电机 ID 期间似乎对 RoverL_rps 没有影响、因为(低于红框的 KP/Ki_ID=0.0)仍然在低电感电机中产生 RoverL_rps。 在这种 情况下、可能是由以200Hz 的频率注入的相电流引起的。 在电机电感未知的情况下、KP/K_ID 值>0.0会对峰值饱和电流产生不良影响。 这样一种看似成熟的电机 ID 方法 ROM 估算器用于查找电感的估算器为何获得如此小的关注？

6.6.3 CTRL_State_OnLine 和 EST_State_RoverL

估算器的这一状态通过除以测得的电阻和电感来测量定子电路的电子时间常量。 控制器对象使用 RoverL 时间常量来设置电流控制器 IQ 和 ID 的电流控制器增益 KP 和 KI。 如果绕过电机识别、则将使用 user.h 中提供的参数来设置电流控制器增益。   

您是使用 TI EVM 套件还是使用自己的电路板？

在支持的 TI EVM 套件上运行示例实验是否存在任何问题？

您在示例实验中进行了哪些更改？ 如果要更改示例实验、目标是什么？

zhengfeng zhang 说：

您是在使用 TI EVM 套件还是使用自己的电路板？

两者可兼得

zhengfeng zhang 说：

在支持的 TI EVM 套件上运行示例实验是否存在任何问题？

是的、代码需要 CCS 调试并且不能在项目实验室之间移植、也不能保持一致的语法架构！ 实验 is05未遵循 PDF 大纲 SPRUHJ1I–2013年1月–2021年10月修订 RoverL_rps、RSOhms 未正确分割、未显示 Ki/KP_SPD、Ki/Kp_id 也偏离了电机 ID 过程的 PDF 文本披露。 IS05如何旋转电机、开环或闭环？ 看到 IS07 ISR 使闭合电流控制环路生效、可能是为什么在电机 ID 期间 CCS 调试中显示 Ki/KP_SPD Ki/KP_ID 参数并导致不受约束的饱和电流的原因？ 看似为 is05是开 环的、这或许可以解释为什么电机在 RS RampUp 中具有较难的时间。

zhengfeng zhang 说：

如果要更改示例实验，目标是什么？

在 Booster 接头 J5-J8上使用 BXLS_DRB8320RS_revA 的 LauchXL_F280049c 将是添加 MCSDK 更新的良好开端。 将 DAC 板放在 J1-J4上 、那里也有6个 PWM 通道。

显然、 电机 ID 实验 IS05不通过(Ki_spd 或 KP_spd)设置轨迹、尽管清除了 Ki/KP_ID 值0.0 (is07)且 Rs RampUp 电流不再饱和。 然而、转子完全不旋转、并且具有极小的保持扭矩、因为饱和电流仅为400毫安。 实验 IS05使用 IA 电流来确定估算器状态变化的方法非常主观、似乎不是正确电机 ID 的方法。 当 Park 变换不用于控制 PWM 占空比 IS07时、速度控制器的未记录行为会导致极高的饱和电流、这可以通过这一行为来证明。 而 Park 已经被内联估算器调用 is07取代、至少可以说这是一个巨大的差异！   

 EST_getIdq_a (estHandle、(MATH_Vec2 *)(&(idq_in_a))；

电机 ID 设置 userParams.flagMotorIdentified = true 后添加到 is07的这些 is05速度调用不会在电机 ID 状态中断后设置 ki/KP_SPD 或 ki/KP/id、并设置 motorVars.trajState = EST_TRAJ_State_idle 以结束 ID 过程。 CCS 调试表达式不会使用代码片段中设置的新值进行更新。

float32_t speed_min_Hz = -USER_MOTOR_FREQ_MAX_HZ;
float32_t speed_max_Hz = USER_MOTOR_FREQ_MAX_HZ;
float32_t speed_maxDelta_Hz = motorVars.speedRef_Hz / userParams.trajFreq_Hz;
// setup the spd trajectory
EST_setMinValue_spd_Hz(estHandle, speed_min_Hz);
EST_setMaxValue_spd_Hz(estHandle, speed_max_Hz);
EST_setMaxDelta_spd_Hz(estHandle, speed_maxDelta_Hz);

编辑04/07/23：低于 速度电流控制调用 do's (est.h)似乎不会返回 bool 标志、它们将在控制器设置中设置 bool 标志(true)。 因此、IS05从不会在调试电机 ID 标志中显示 KP/Ki_id/IQ 值为真。 请注意，从 is05 mainISR()复制的控制器设置在 is07 ISR 中放置时会立即导致控制器错误，当然还有条件标志。 开关用例 ISR 电机 ID 方法在 ISR 时间上下文中更改估算器状态的精度要高于 while 环路。 但需要在 IS07中清除 KI/KP_SPD KI/KP_IQ (0.0)、或电机在 ID 期间剧烈抖动。 控制器设置不是任何人可能会在 SDK 编码拓扑中遇到的奇数问题。 控制器设置函数内两个(DO)的内联 est.h 返回 bool 标志不会在 CCS 调试表达式窗口中设置 KI/KP_ID/LQ、在 is05中保持为0.0。

EST_doCurrentCtrl (estHandle)、 EST_doSpeedCtrl (estHandle)是 bool 标志：为什么不为 is05电机 ID 设置 Ki/Kp_ld_lq 值、或者它们是否出现在调试表达式窗口中？ 很显然、我正在尝试使 is05项目正常工作、而不会出现通过 is07存在于 HID 电机 ID 过程中的调试问题。 我们似乎应该 能够在 IS07的闭合双控制电流环路中执行电机 ID。 主要是减少与 is05 KI/KP_LD/LQ 类似的 KI/KP_LD/LQ、但未显示在调试表达式中。 请注意、以下代码片段将启用电流控制器 is05。 为什么在电机 ID RoverL_rps、RS Rampup 期间为 KP/Ki_ld_l/Lq 值(0.0)？ Perahps 需要添加脚注以说明电机 ID 偏离流程图和所示文本的 FAST 估算器 bool 标志 InstaSpin 用户指南 SPRUHJ1I–2013年1月–2021年10月修订？

//Seemingly enables (do) estimator functions in the inline setup function below.
// Do they actully retunr a bool state or set the bool state for the controllers actions?
           
//! \brief     Determines if current control should be performed during motor identification
//! \param[in] handle  The estimator (EST) handle
//! \return    A boolean value denoting whether (true) or not (false) to perform current control
extern bool     EST_doCurrentCtrl(EST_Handle handle);
extern bool cla_EST_doCurrentCtrl(EST_Handle handle);


//! \brief     Determines if speed control should be performed during motor identification
//! \param[in] handle  The estimator (EST) handle
//! \return    A boolean value denoting whether (true) or not (false) to perform speed control
extern bool     EST_doSpeedCtrl(EST_Handle handle);
extern bool cla_EST_doSpeedCtrl(EST_Handle handle);
           
           
            //
            // setup the controller
            //
            CTRL_setup(ctrlHandle,
                       estInputData.speed_ref_Hz,
                       estOutputData.fm_lp_rps * MATH_ONE_OVER_TWO_PI,
                       (MATH_Vec2 *)&(Idq_in_A),
                       (MATH_Vec2 *)&(Idq_ref_A),
                       &null,
                       EST_doSpeedCtrl(estHandle),
                       EST_doCurrentCtrl(estHandle),
                       false);

注意：MCSDK 代码目前与 LaunchXL-F280049c 或 BXLS_DRV8320RS_revA 不兼容、需要进行重大更改、才能使其在靠近 SDK 4.01的任何位置工作。 MCSDK 电机 ID 仍需要基本的复制粘贴、未通过针对多个电机和用户参数的 HID 更新实现。 使用#define 来表示电机参数并非生产最终构建级别的谨慎方法、因为所有电机即使是同一型号也会改变电感和电阻。 MCSDK 包含 CAN 连接、但远程站能否通过调用从用户友好型菜单中选择电机 ID 更新来更改(userParams.LS_HD/HQ)参数？ 这似乎是 AI 连接的未来、让人工智能的天才能在毫秒内完成艰巨的工作。  

jiaxin sun 说：

电机 ID 设置 userParams.flagMotorIdentified = true 后这些 i05速度调用添加到 is07不会在电机 ID 状态中断后设置 ki/kp_spd 或 ki/kp/id、并设置 motorVars.trajState = EST_TRAJ_State_idle 以结束 ID 过程。 CCS 调试表达式未更新为代码 snip 中设置的新值。

答案：需要设置启用控制器状态标志在线电机 ID、is07或 is05之后的下一个电机运行。 似乎控制器状态从未从空闲切换到在线。 尽管选中了在线状态标志(labs.h) updateController()。 因此、  while 环路中从未调用 KP/Ki_ID/IQ 电流控制器。 注意、控制器 状态机代码有时会触发枚举状态表达式窗口视图，但通常完全不执行任何操作。 控制器状态框省略了 is05.asp、没有人知道控制器在后台执行什么操作、除非他们加载 is07.asp 并运行 is05固件。  

尽管很有意义、07速度模式不仅简单地启用控制器、还会设置枚举状态标志。 然而、电机将以控制器状态 CCS 调试运行、显示 CTRL_State_Idle、因为用户 KP/Ki_ID/IQ 是在进入 main.c  时启动的、而不是在循环 is05的无限期间启动。 出现此问题的原因是  在轨迹的大多数状态更改中也缺少枚举状态标志、并且估算器检查为 is05和 is07。 建议所有工程师在缺少的地方添加这些枚举标志。 检查 MCSDK 是否缺少枚举状态标志可能是个好主意。 验证在调试表达式窗口中显示的电机 ID RoverL_rps、RS Rampup 的 Ki/Kp_ld_l/Lq 值、符合 InstaSpin 用户指南 SPRUHJ1I–2013年1月–2021年10月修订。

//启用控制器
CTRL_enable (ctrlHandle)；
//
motorVars.ctrlState = CTRL_State_OnLine；

 实验 IS05似乎没有遵循图41路径、或者快速块模型 PI IQ/ID 源块是虚构的。 以下添加到 is05 Forever 循环的代码 snip 应在电机 ID 过程中更新 motorVars.KP/Ki_ID/Iq 调试表达式视图。 奇怪的是、我们不知道 PI 块 is05如何通过 ROM Park 使用 FAST 来设置电流斜率以通过 is07与电机 ID 进行比较。

当代码未 按预期工作时、我们如何解决电机 ID 问题？ 将 is05 PI 控制添加到 is07中 、省略 ROM 帕克、并真正希望具有调试可视化 PI 块在执行什么操作、以设置电机 ID 电流斜率。 这个主题并不是由 PDF 文本详细阐述的、因此 SDK 是有问题的、因为它被开发成一个基础来构建一个功能性系统。 然后、x25附带 MCSDK、更好的做法是不具有与 SDK 无法在电机 ID 闭环中设置电流斜率相同的习语行为。 也许是时候与所有的小人一起拥有令人惊叹的电机 ID 代码在 MCSDK 上层构建级别和上部项目实验室中工作的时间为6到 is13。 否则、随着天气变化太快、即时更新用处不大。 等我的家伙,我的 EV 计算机必须做电机 ID 和需要固件上载,然后我可以来加入党 .

        /* Configure controller current gains */
        if((userParams.flag_bypassMotorId == false) &&
                (motorVars.flagEnableOffsetCalc == false) &&
                (motorVars.flagRunIdentAndOnLine == true))
        {
            if(motorVars.flagSetupController == true)
            {
                //
                // update the controller fromn RoverL_rps check
                // set custom current and speed controllers gains
                //updateControllers();
                
                // update the Id controller
                PI_setGains(piHandle_Id, motorVars.Kp_Id, motorVars.Ki_Id);
                // update the Iq controller
                PI_setGains(piHandle_Iq, motorVars.Kp_Iq, motorVars.Ki_Iq);
                // update the speed controller
                PI_setGains(piHandle_spd, motorVars.Kp_spd, motorVars.Ki_spd);

            }
            else
            {
                //motorVars.flagMotorIdentified = true;
                motorVars.flagSetupController = true;

                // set up estimator conrollers
                setupControllers();

            }
        }
        /* Update Kp/Ki_id/iq current gains
         * derived via RoverL_rps motor ID */
        getControllers();

InstaSpin 的工程和实验室用户指南 SDK 实验室 IS07陈述：  

谨此提醒、随这些(Ki/Kp_spd)计算生成的 PI 分析基于串联 PI 环路。 InstaSPIN 对电流控制器使用串联 PI 环路、对速度控制器使用并行 PI 环路。 速度 PI 增益必须从串联形式转换为并联形式。 公式12和13显示了转换过程。  

当 is07是速度控制器(PI)项目时、为什么全部3个计算均使用串联 PI 环路？ is06转矩控制使用串联 PI 看起来不是 is07速度控制是合理的。 也就是说、提醒声明的措辞正确。

无论如何、使用来自 is05的 Park 变换代码修补 is07只会切换 idq_ref_A。value[1]几次、motorVars.Ki/KP_ID/Iq 在电机 ID 期间保持0.0。 更复杂的是 idq_ref_A。值[0]始终保持0.0，即使在 IS07速度控制中，仅运行一个电机的 idq_ref_A。值[1]具有饱和电流。 然而、代码 在所有与 idq_ref 相关的调用中引用了 idq_ref_A.值[0]

您可以对所需的电流和速度使用任何稳压器、例如不依赖于 FAST 估算器的串行或并行 PI 控制器。

Lab05使用 FAST 估算器中的 ctrl 控制器和 park。 lab07可以使用 lab05或使用外部 Park 作为现有示例。

使用这些示例时遇到了什么问题？ 是的、您可以根据需要更改控制流程、这些示例实验仅展示了如何使用 FAST 估算器。

zhengfeng zhang 说：

Lab05使用来自 Ctrl 的 PI 控制器和来自 FAST 估算器的 Park。 lab07可以使用 lab05或使用外部帕克作为现有示例。

(图55)或任何 TI 文献的 SDK 实验室中未显示该方框图。 因此，由于"内部公园"是一个模糊的术语，我们无法使用视觉表示法，因此出现了上述问题。 电机 ID 方法连接到 INVPARK、那么内部 Park 如何连接到 INVPARK、在何处连接呢？  

zhengfeng zhang 说：

lab07可以将一个用作 lab05或使用外部 Park 作为现有示例。

然而、当从 is07 main.c 内执行 is05 ISR 函数时、它会立即导致控制器错误 我将向您介绍新的混合 ISR 模块、或许您可以找到外部帕克导致控制器错误的原因。 可从 main.c 中调用该函数来设置 bool 标志以反映电机 ID 而不是速度控制、如 main.c 的顶部选项所示

这不是问题、请参阅示例实验。 如果您希望使用单个项目进行识别和运行、请参阅并使用前面提到的通用电机控制实验。

zhengfeng zhang 说：

这不是问题，请参阅示例实验。 如果您希望使用单个项目进行识别和运行、请参阅并使用前面提到的通用电机控制实验。

请尝试专注于线程问题、文档对于使用内部 ROM 停止的 SDK 速度控制 IS07至关重要。 在哪里、内部公园被描述为与 INVPARK 任何 TI 文档有任何连接？？？

More Over PI 控制块未在 IS05中设置、您应该知道！ PI 控制设置 is07 min/max 似乎引起了 Id 问题、并且是反向的、不符合图41的要求。 因此、下面的代码片段证明了这一点非常重要、因为我们想要使用 is05和 is07中的 PI 控制块、同时显示了 SPRUHJ1I–2013年1月–2021年10月修订。 这说明、我们需要通过在线生成 RoverL_rps 和 RS 来使用 Ki/Kp_ld_l/LQ 值作为针对 ROM 嵌入式电机 ID 函数的 F280049c MCU 类的正确方法。 书中并不严格介绍 SDK 示例代码！ 下面的注释说明了快速 RTS 函数、但它是查找平方根的简单 C 库调用。

但它设置了标称总线电压的最小值/最大值24V 是(9.3nnn 鼠标悬停)、但我不知道 Vdq 与  任何电机 ID 中的 USER_MOTOR_RES_EST_CURRENT_A 或 USER_MOTOR_IND_EST_CURRENT_A 有何关系。 电机 ID 过程的 MCSDK 基准绝不是无缝的、需要构建级别。 上面的图55显示、在任何测试实验室中添加极少参数后、我们只需翻转 bool 开关。 您是说已修复的 MCSDK 没有特定级别、ID 也没有、或者在同一构建中运行电机、但仍需要复制粘贴4个电机参数吗？

请解释为什么 PI 控制块不在 is05电机 ID 过程中、可能也是 MCSDK 中？ MCSDK 旨在支持非嵌入式 FAST 估算器 LSRAM 库、似乎适用于 x25 MCU 类。

您可能会说 TI 也尝试通过 x49c 使 SDK 使用 fast_full_lib.lib、并在编译期间生成数百个缺少符号和未定义的错误、甚至对 x49c MCU 类也尝试这样做是徒劳的！

//计算 IQ 控制器限制，并使用快速 RTS 运行 IQ 控制器
//函数，可调用的汇编
//使用标称总线电压
outMax_V = sqrt ((userParams.maxVsMag_V * userParams.maxVsMag_V)-
(Vdq_out_V.value[0]* Vdq_out_V.value[0])；

pi_setMinMax (piHandle_iq、-outMax_V、outMax_V)；

zhengfeng zhang 说：

请参阅并使用前面提到的通用电机控制实验室。

支持如此多 MCU 类的 MCSDK 代码 凸显了每个 C 模块中的代码覆盖率这令人难以置信。 您能否保证不会出现与 SDK 相同的电机 ID 问题。 我已经向您展示过、MCSDK 存在相同的受限 userParams ls_ld/lq、并且需要构建级别用户复制粘贴、因此甚至可以正常运行。 MCSDK 有何出色之处呢？更新电机参数也存在同样的问题、答案很简单。要构建工业电机控制 系统、无论如何都不可靠、而且不会完全拆除、这需要开公司承担或不想花费的成本达到数百万美元。

似乎 TI 在新冠疫情充分迎合了学习社区的需求、失去了销售超过数百个 C2000 MCU 的欲望。 这在所有论坛上都是非常值得注意的、TI 在过去两年里损失了巨大的资金投入。 这似乎与所有空间矢量控制问题有关、并且代码示例在产品中实际使用时不可靠。 我已经尝试展示有更好的方法来改进电机 ID 过程、因此无需复制粘贴或 CCS 调试即可更加无缝地运行。

卓越的 MCSDK 项目旨在增加更多安全电机警报和更好的 eSMO 增强型低速观测器、并对 ADC 样本进行 PPB 控制、  

如果您希望通过 F28004x 上的 InstaSPIN 实验运行电机识别、则必须使用 lab05、因为识别需要"Ctrl"对象和相关函数。 您可以使用 lab05运行电机、作为 lab07。

 motorWare 和电机控制 SDK 中的所有 InstaSPIN 实验都对电流和速度使用相同的 PI 控制器、您可以参阅《InstaSPIN 用户指南》中的说明。

这就是为什么我们向您推荐通用实验、此实验可以满足您需要的大多数要求、您可以看一下它。

软件 FAST 库可以支持 FPU 包含用于 InstaSPIN 的 F28004x 的所有 C2000器件。 您可以参考电机控制 SDK 中更新的 C2000器件的实验。 当前 MCSDK 中提供了通用电机控制实验室、该实验室可以支持一组用于 BLDC/PMSM 驱动器的硬件套件和控制算法。 这些套件包括 LAUNCHXL-F280025C、 LAUNCHXL-F280039C、  带 BOOSTXL-DRV8323RS 的 LAUNCHXL-F2800137、 BOOSTXL-DRV8323RH、DRV8353Rx-EVM   用于低压电机的 BOOSTXL-3PHGANINV、DRV8316REVM 或 DRV8329AEVM 逆变器板(最大值：100Vdc)。   带 TMDSHVMTRINSPIN 逆变器板的 TMDSCNCD280025C、TMDSCNCD2800137或 TMDSCNCD280039C 和 用于高压电机的 TMDSADAP180TO100 (最大350Vdc)。 控制算法包括采用 FAST 的无传感器 InstaSPIN-FOC、采用 eSMO 的无传感器 FOC、采用增量编码器的含传感器 FOC、采用霍尔传感器的含传感器 FOC。

C2000WARE-MOTORCONTROL-SDK： https://www.ti.com/tool/C2000WARE-MOTORCONTROL-SDK

通用项目和实验室用户指南： https://www.ti.com/lit/spruj26

文件夹下的示例实验项目：C：\ti\c2000\c2000Ware_MotorControl_SDK_ \solutions\universal_motorcontrol_lab\f28002x

或                                                        C：\ti\cc2000\c2000Ware_MotorControl_SDK_ \solutions\universal_motorcontrol_lab\f28003x

或                                                        C：\ti\cc2000\c2000Ware_MotorControl_SDK_ \solutions\universal_motorcontrol_lab\f280013x

zhengfeng zhang 说：

如果您要在 F28004x 上使用 InstaSPIN 实验室运行电机识别、则必须使用 lab05、因为识别需要"Ctrl"对象和相关函数。 然后、您可以使用 lab05将电机运行为 lab07。

Umm lab is07使用控制对象(ctrl.c/labs.c/h)调节 PI 速度控制(ki/kp_id/iq 或 ki/kp_spd)。 当 IS05 ISR 代码被添加到 IS07 ISR 并在不同时间生效时、控制器不应进入错误状态。 Instaspin 故障排除文本并不涵盖 我报告的错误情况。 奇怪的是、RS 阻抗闭环电机 ID 通过 IS07 ISR 代码产生准确的 结果、但 rampUp 推送扭矩模式 A_IQ 最小值/最大值、无论我们是否设置 pi_setMinMax (piHandle_iq、-outMax_V、outMax_V)以使用 USER_MOTOR_RES_EST_CURRENT_A 与标称 BusVoltage AKA (userParams.maxVsMag_V)。

SDK 项目实验用户指南说明了 is05电机 ID 开环的第一部分、但未能详细说明 它究竟意味着什么、为什么必须是开环？

在 RoverL_rps 期间、在实验 IS07 ISR 断言 is05 ISR 函数时、控制器错误会迅速发生。 PM 代码剪贴应该证明 TI 设计单独示例的方法存在根本问题、对现实世界的机器毫无用处。 也许一个双核 MCU 可以有两个 main.c、使 is05和 is07共存于内存中的同一个代码空间中、但这只是坚挺的处理器理念。 请让 TI 为在 ROM 代码和新的 FAST 库中调用和断言电机 ID 所需的模块创建正确的流程图。 即当前控制器所做的与电机 ID 过程(ctrl.c/labs.c/h)中的 FAST 估算器和状态机等待时间相关的工作，目前尚未记录。

除了作为单独的对象代码巧妙构建 SDK 电机 ID 的 TI 工程师之外、没有任何人可以无缝地与任何其他实验配合使用。 这根本不是一个合乎逻辑的方法,因此我在这里多次问同一个问题,不同的方式没有得到合乎逻辑的答案。  

请尝试使 PM 代码使用 is07 main.c 和 is05电机 ID 处理 ISR 代码、而不会导致控制器错误。 也许我们可以在论坛上共享该代码、只要它正常工作、就不会在 RoverL_rps 期间导致电流控制器错误。

抱歉、通用实验室由于支持多控制算法而变得如此复杂。 您可以尝试搜索"flagEnableMotorIdentify"进行识别。

尝试遵循 SDK/MCSDK 示例时遇到的更大问题是上面图55 (FAST 估算器)中显示的命名约定并未始终按照 PI 控制和电流控制器块的逐字执行。 整个 SVM 项目模型的另一个问题是 ROM/FAST 库没有轨迹发生器的支持方框图。 因此、est.h 调用内部 FAST 块并不会使代码配置变得更加容易、尤其是在电机 ID 过程方面。 到目前为止、我看到 MCSDK 存在类似的问题、需要提高透明度、使用 C 代码中置位的所有 SVM 控制块的命名标签(输入/输出)。

SDK 控制器错误为07、由于内联调用返回 bool 标志、强制状态时、电机 ID 控制器通过 IS07运行无错误。 奇数部分是轨迹发生器状态相对于(ID_TARGET_A)电流 is05 (不处于 IS07中)的变化、并且电机在斜升期间不会旋转。 下面的调用没有记录电机 ID 过程需要哪些两个内联(执行转速/电流)调用。 根据注释、在 RsOnline 中使用 ID_TARGET_A、但不提供任何有关电流变化如何指示窗口以更新轨迹发生器的详细信息。

ID_TARGET_A 在帧(LS_DH/LS_QH)内°60 μ s、作为控制块输入的 PI 块 KP/Ki_ID/IQ 周期？ 或者我们能否改用 FAST Irated theta 来替换 ID_ref 输入数据并检测用于更新轨迹发生器的窗口？  

为什么两个内联 FAST 估算器在以下调用中执行作用、以及为什么需要它们来断言电机 ID 过程？ MCSDK 中的疯狂行为是否改变了？

//
//设置控制器
//
CTRL_setup (ctrlHandle、
estInputData.speed_ref_Hz、
estOutputData.fm_lp_rps * MATH_ONE_OVER_FWO_PI、
(MATH_Vec2 *)&(idq_in_a)、
(MATH_Vec2 *)&(idq_ref_a)、
null (&N)、
est_doSpeedCtrl (estHandle)、//true
EST_doCurrentCtrl (estHandle)、//false
错误)；

zhengfeng zhang 说：

flagEnableMotorIdentify

CCS 搜索工具在 motor1_drive.c/h、motor_common.c/h、sys_main.c/h userParams.h、user_mtr1.h 文件中找不到此标志。 电机 ID 代码位于何处？ 不是在 Expressions 窗口中设置 bool 标志、而是执行电机 ID 的 C 模块？

此外、driverlib、h 还缺少 MCSDK src_driver 文件夹、并且缺少驱动程序 include。 CCS 项目安装程序在 SDK4.0安装程序下生成了 MCSDK 链接/文件夹、driverlib 文件位于 MCSDK 上方、似乎已经在 SDK4.0以上安装了导入的项目。

燕明、

MCSDK 未改进电机 ID 过程、而不是动态快速控制功能。  也许 Safera GUI 可以帮助复制电机参数而无需重新构建项目？ 我的代码方案 SDK IS07包含 IS05、用于将4 user.h 作为变量而不是#define 生成动态电机 ID 更新。 因此、电机 ID 运行后不需要编译、因为参数将存储到 LSRAM 中、如果用户需要、随后存储到闪存扇区中。 通过 ARM Cortex MCU 类解决方案有多么容易实现这一目标、而对于 C2000来说又这么困难呢？ 重新编译 C 代码似乎是多么的少  

6.在 Expressions 窗口中将变量 motorVars_M1.flagEnableRunAndIdentify 设置为' 1、如图2-41所示、电机识别将执行、整个过程大约需要150个0。 motorVars_M1.flagEnableRunAndIdentify 等于0并且电机停止后、电机参数即被识别。 复制观察窗口中的变量值以替换 user_mtr1.h 中定义的电机参数、如下所示：
•USER_MOTOR1_Rs_Ohm = motorSetVars_M1.Rs_Ohm 的值
•USER_MOTOR1_Ls_d_H = motorSetVars_M1.Ls_d_H 的值
•USER_MOTOR1_Ls_q_H = motorSetVars_M1.Ls_q_H 的值
•USER_MOTOR1_RATED_FLUX_VpHz = motorSetVars_M1.flux_VpHz 的值
7.将 userParams_M1.flag_bypassMotorId 值设置为"true"以在成功识别电机参数后禁用识别、重新编译工程并将代码加载到控制器中。

zhengfeng zhang 说：

通用实验室中有两种电机识别方法。 只需更改"flagEnableMotorIdentify"即可对电机进行固定操作并保存已识别的电机参数而无需重新构建项目

它能否运行已识别的电机而不复制粘贴 CCS 调试4值、而看起来似乎没有。 在这种情况下、电机 ID 结构会出现故障、因为必须有人在场。操控代码 模拟在线电机 ID 热过程。

is05电机 ID 的问题是 mainISR 代码不是 ID 过程的一部分。 由于控制器状态未设置为在线、因此主函数代码不会在电机 ID 期间执行、并且 est.h 两个 bool DO 标志(在 snip 上方)毫无意义。 is05 ID D 轴注入电流在 Forever 环路中生效、mainISR 代码主要用于所有3个状态均上线时的运行时测试、并(motorVars.flagMotorIdentified=true)将4个调试值复制粘贴到 user.h 这并未解释用户指南流程图上面的 Misleads 显示了全局更新、其中没有所描述的 mainISR 主运行时函数的旁路块。

实验 IS05显示了控制器状态(在线)、但它实际上在 SPM 电机的电机 ID 永久循环期间(空闲)。 图41显示了 ACIM 锁定转子和 mainISR 逻辑流程在线直通、SPM 保持在永久循环状态、直到识别完成、但用于全局更新置位。 因此、mainISR 仍会使 SOC 中断有效、但直到控制器联机后才会执行主函数。 这是 is05 mainISR 代码中最重要的部分。 没有人知道 is05_debug.asp 会忽略枚举控制器状态。

看似是为什么电流控制器在将 is05 mainISR 代码复制到 is07速度控制时发布错误异常、但在电机 ID 过程扭矩累积期间将 KI/KP_ID/IQ 值设置为最大值时、电机不会针对 RampUp 旋转。 代码更改可标记速度 PI 公式区域并插入 user.h 电机 ID 最小值/最大值。 下面的 snip 显示了 Forever 环路何时错误地设置电机 ID 的轨迹 ID 饱和电流、Forever 环路中应使用 user.h 电机 ID EST/IND 值。 "识别"运行后、可更新饱和电流。  

我似乎在 MCSDK 中找不到看似嵌入由单个状态标志触发的 fast.lib 中的隐藏电机 ID 函数。   

//
//配置 fwc 参考轨迹
//
TRAJ_setTargetValue (trajHandle_fwc、0.0)；
TRAJ_setIntValue (trajHandle_fwc、0.0)；
TRAJ_setMinValue (trajHandle_fwc、-user_motor_MAX_CURRENT_A)；
TRAJ_setMaxValue (trajHandle_fwc、USER_MOTOR_MAX_CURRENT_A)；
TRAJ_setMaxDelta (trajHandle_fwc、
(USER_MOTOR_RES_EST_CURRENT_A / USER_ISR_FREQ_Hz)；   

zhengfeng zhang 说：

是的，如果您使用的是通用电机控制实验室，则无需复制和粘贴值

尽管措辞有点模糊、但在用户指南中似乎这么说。

8.该示例可以支持在线识别电机而无需按照以下步骤重新加载代码。

9.完成电机参数识别或在 user_mtr1.h 文件中设置正确的电机参数。

zhengfeng zhang 说：

许多人为您节省了几个时间来集成 lab05和 lab07。

我放弃了 从 IS05积分至 IS07。 奇怪的是、is05似乎是 ROM 估算器在电机 ID 上升期间不会生成 motorVars.speed_Hz 的解决方法。 将 IS07 PI 控制与 KI/KP_ID/IQ 值结合使用并且 D 轴注入电流斜降时、电机突然停止旋转、进入 Ls 状态。 因此、idq_a[1]= DC_BusVolts / 3的最小值/最大值、这将减少斜坡电流和进入 D 轴的 PI 注入电流。

为什么  motorVars.speed_Hz =  EST_getFm_LP_Hz (estHandle)在电机 ID 期间返回0赫兹？ 可能未记录的 ROM 错误？ 但 在斜升期间、电机以50Hz 的速率旋转、由 USER_MOTOR_FLUX_EXC_FREQ_Hz = 50设置。

默认斜降时间/3很短、行为类似于 OL_FLUX 具有锁定转子、即使绕过锁定转子标志设置为真。 同样、这些是非常低的电流、在250mA 至320mA 范围内具有最小/最大 PI 值。 此电机非常接近额定功率1.3A - 18W、SVM 消耗的电流与看似与 BLDC 梯形电流额定值相同。

6.6.6.1电流斜降
识别磁通时、首先由电机识别状态机内部启用闭环。 该闭环不是由用户启用。 启用该闭环时、电流消耗降至机械负载在相同频率下保持旋转所需的最小电流值。 电流降低时的斜率是一个固定值、即每秒的 Rs 估算值除以3。 除数3是在电机识别过程的设计阶段选择的、旨在提供一个更慢的斜率。

燕明、

实验 IS05 LS 状态通过定制直流逆变器产生非常低的电机电感值。 更奇怪的是、在枚举控制状态之后、使用 ISR 开关案例通过 IS07执行电机 ID。 值得注意的实验 IS05通过相同的 KP/Ki_ID/Iq 使用 Vdq_out_V 至 RampUp PI 速度、不是由轨迹发生器作为 IS07速度控制饱和电流(Iq)进行控制。 为什么在电机识别期间不通过实验 IS05控制饱和电流(Iq)？ 看起来、这就是小型电机可以轻松烧毁绕组的原因。 此问题是否已在 MCSDK 中得到纠正？

实验 IS05控制器状态似乎是通过未记录的地址矢量(CTRL_run / CTRL_setup)更新 ROM。 由于图41流程图省略了一个块以通过 MAIN_ISR 中断显示速度和电流地址矢量、因此工程师似乎永远无法理解其操作过程。

奇怪的是、实验 IS05通过 idq_ref_A 注入到 D 轴的电流。value[0]监控的调试。 然而、IS07 MAIN_ISR 使用 idq_ref_A.值[1]来更新 PI 速度控制轨迹状态。 这是一个没有在任何文本中解释的双重标准。 同样无法回答为什么在将以下调用置位为 MAIN_ISR 时、未在表达式窗口中更新 IS05 KI/KP_ID/IQ。 因此、电机 ID 过程中通过内联 bool 标志(DO)存在另一个令人困惑的标准、用于控制在将 is05代码导入 is07 MAIN_ISR 后导致控制器错误的速度和电流。 关于 PM 代码-为什么 IS07的 FOREVER 循环会导致 I05导入的代码轨迹通过 FOREVER LOOP 更改而看似以切换 EST 状态的意外控制器错误？ MCSDK 是否更改了电机 ID 的方法、使其远离下面显示的矢量地址？  

与 IS05所产生的电压相比、通过自定义逆变器可实现 IS07永久循环和 PI 控制(KI/KP_ID/IQ)状态变化以及 LS_ID_H/IQ_H 更准确。 电机 ID 标志 true 通过以下调用在 is07中运行以降低(idq)电流、似乎处于错误的 PI 块中、应该是高 PI？ 同样、上面的图55使用了与未描述的 is07代码奇数变量名称不同的命名法。 似乎有人剪切和粘贴现有图片、但从未更新过以反映代码变化。  

添加到调试表达式 is05以查看 Vdq_out_V、并注意 idq_ref_A.值[1]包含(idq)数据、而不是值[0]。

//最大电压输出
userParams.maxVsMag_V = userParams.maxVsMag_pu * adcData.DCBus_V；

/*电机 ID 最小/最大 PI 输出*/
if (motorVars.flagMotorIdentified == false)
｛
  userParams.maxVsMag_V = userParams.maxVsMag_pu *(adcData.DCBus_V / 3)；
}
pi_setMinMax (piHandle_ID、(-userParams.maxVsMag_V)、userParams.maxVsMag_V)；

//运行 ID 控制器
// Low Pi 块 Vdq_out-0向 InvPark 返回-5Vq
pi_run_series (piHandle_ID、
idq_ref_A。值[0]+ idq_offset_A。值[0]，
IDQ_IN_A。值[0]，
0.0、
&(Vdq_out_V.value[0])；

MCSDK 可能会进行动态电机 ID 库调用、也可能会通过 SCI ISR 函数遇到监控开关情况枚举的电机 ID 等待时间步长(mtr1_user.c)相同的问题。 MCSDK 是否在调试表达式窗口中的电机 ID 期间更新 KI/KP_ID/IQ？

//! 运行控制器
//! \param[in]处理控制器(CTRL)句柄
//! \param[out] pVdq_V 直流/正交电压矢量 V 的指针
静态内联 void CTRL_run (CTRL_Handle handle、MATH_Vec2 * pVdq_V)
｛
CTRL_Obj * obj =(CTRL_Obj *)句柄；

//适当时，运行 PI 速度控制器
if (CTRL_getFlag_enableSpeedCtrl (handle))
｛

//适当时，运行 PI Id 和 Iq 控制器
if (CTRL_getFlag_enableCurrentCtrl (handle))
｛

//运行 Id PI 控制器
pi_run_series(obj->piHandle_ID、refValue_a、fbackValue_A、ffwdValue_V、&(pVdq_V->value[0])；

lab05使用"CTRL"对象和功能、其中包括电流和速度控制器。 lab07不使用"CTRL"对象、所以它使用附加 PI 控制器。 两个实验中的 FOC 流程是相似的、但只有 lab05可以支持电机识别、因为识别需要 CTRL 对象中的一些功能。

zhengfeng zhang 说：

lab05使用包含当前控制器和速度控制器的"CTRL"对象和函数。

实验 is05和 is07都使用 PI 控制块，MCSDK 电机 ID 将 pi_Run ()置为 用于速度/电流控制，而 is07置为 pi_run_series ()。 当我们仔细研究 MCSDK 时、电机 ID 函数会执行电机 ID 和运行电机闭环。 相同的 EST bool (DO)测试设置速度和电流 PI KI/KP_ID/IQ 似乎通过 idq 输入将两个 PI 块设置为 idq_in_a_[0/1]？ 差异可以忽略不计、描述这些 EST bool (DO)控制函数的图在哪里？ 下面的 MCSDK 代码(隐藏在亮点中)与我尝试使用 SDK IS07执行的操作更加内联。

下面的代码几乎是我在实验 IS07中测试的用于执行电机 ID 的相同 PI 结构、但电机将停止以 LS 格式旋转、并且轨迹不会提高、其为目标速度或为零。 请注意、下面的代码 idq/ Vdq 在图55的上方没有详细记录、但对于 Vdq 输出到 INVPARK 的何处、这仍然非常模糊。 图55仅显示 INPARK 中的 VQ/Vd、其中 Iq/id 来自 MCSDK 中的 PARK？ 我们可以在下面的电机 ID 代码中看到 clare_run ()、但没有帕克。

#else     // !SFRA_ENABLE
            PI_run(obj->piHandle_Id, obj->IdqRef_A.value[0],
                   obj->Idq_in_A.value[0], (float32_t*)&obj->Vdq_out_V.value[0]);
#endif  // !SFRA_ENABLE

        // calculate Iq controller limits
        float32_t outMax_V = __sqrt((objUser->maxVsMag_V * objUser->maxVsMag_V) -
                          (obj->Vdq_out_V.value[0] * obj->Vdq_out_V.value[0]));

        PI_setMinMax(obj->piHandle_Iq, -outMax_V, outMax_V);

        // run the Iq controller
#if defined(SFRA_ENABLE)
        PI_run(obj->piHandle_Iq, (obj->IdqRef_A.value[1] + sfraNoiseIq),
               obj->Idq_in_A.value[1], (float32_t*)&obj->Vdq_out_V.value[1]);
#else     // !SFRA_ENABLE
        PI_run(obj->piHandle_Iq, obj->IdqRef_A.value[1],
               obj->Idq_in_A.value[1], (float32_t*)&obj->Vdq_out_V.value[1]);

如下所示、MCSDK HAL 对 SDK 符号和宏未保持一致的命名约定。 添加了 BSXL-8320RS_REVA 以便与 F280049c MCU 类一起使用时出现200多个错误、不包括 SFRA 代码。 x25 TRM 甚至没有列出 SFRA、这有点令人费解。 MCSDK 至少应在 x49c MCU 类别下向后兼容。 布尔值#if /#endif 的广泛使用打开了编译器混乱的大门。 对我来说、MSCDK 对 C 语言对象结构的 SDK 设置优先级与经过很好测试并建立为 HAL 对象代码的 C 语言对象的结构有偏差。 TI 程序员从未开过会讨论代码结构、谁决定对 HAL 进行如此巨大的更改甚至是非常谨慎的。 我不这么说是说,虽然 REX 安装的代码远低于 SDK4.0和超过450错误(类型.h )( device.h )必须添加项目包含路径,仍然没有修复许多简单的错误 float32_t 和 unit32_t*与 unit32_t*不兼容, 超过50条警告、更不用说在调试这场巨兽几小时后出现95条错误了。

您使用的是哪个示例实验？ 如果要在 F28004x 上实现通用实验、则需要按照通用实验指南进行操作、以相应地更改 hal.c 和 hal.h。

zhengfeng zhang 说：

如果您要在 F28004x 上实施通用实验，则需要按照通用实验室指南相应地更改 hal.c 和 hal.h。

不是很容易、因为现在的编译有5个编译错误。 在哪里或者什么是 BSXL8323_REVA vars 处理代码定义？ 因此、可以添加代码以使 DRV8320RS_REVA 进行相同的编译？ 我转换了所有其他定义、但下面显示的8320变量句柄似乎与 SPIVAR_t 定义重复？ 许多错误来自 filterfo.c/h 和 filterso.c/h、当索引器发现高于 is15的 is07工程中的 FAPI Types.h 时、会出现数百个 float32 type.h 错误。  

请注意、DRV8320Vars_handle 实际上是通过 drv8320.h 定义的 motor1.drive.h 中甚至有#include 到 motor_common.h 为什么为 BSXDRV8323RS_REVA 定义多个驱动器对象句柄？ 该 obj 句柄似乎是一个冗余定义 SDK4.0 drv8320.h 从来没有两个驱动器句柄。

#include "motor_common.h"
#include "motor1_drive.h"

//! \brief Defines the DRV8320 object
//!
typedef struct _DRV8320_Obj_
{
uint32_t spiHandle; //!< handle for the serial peripheral interface
uint32_t gpioNumber_CS; //!< GPIO connected to the DRV8320 CS pin
uint32_t gpioNumber_EN; //!< GPIO connected to the DRV8320 enable pin
bool rxTimeOut; //!< timeout flag for the RX FIFO
bool enableTimeOut; //!< timeout flag for DRV8320 enable
} DRV8320_Obj;

//! \brief Defines the DRV8320 handle
//!
typedef struct _DRV8320_Obj_ *DRV8320_Handle;

/* Expressions watch window variables */
typedef struct DRV8320_SPIVars_t_ *DRV8320Vars_Handle;

#if defined(BSXL8320RS_REVA)
#define DRVIC_Obj               DRV8320_Obj
#define DRVIC_VARS_t            DRV8320_SPIVars_t
#define DRVIC_Handle            DRV8320_Handle
#define DRVICVARS_Handle        DRV8320Vars_Handle

#define DRVIC_init              DRV8320_init
#define DRVIC_enable            DRV8320_enable
#define DRVIC_writeData         DRV8320_writeData
#define DRVIC_readData          DRV8320_readData

#define DRVIC_setupSPI          DRV8320_setupSPI

#define DRVIC_setSPIHandle      DRV8320_setSPIHandle
#define DRVIC_setGPIOCSNumber   DRV8320_setGPIOCSNumber
#define DRVIC_setGPIOENNumber   DRV8320_setGPIOENNumber
#endif  // BSXL8320RS_REVA

您可能需要参考 DRV8323文件以定义 DRV8320RS 的控制/状态寄存器、并也定义 DRV8320RS 的句柄和对象。 在通用电机控制实验中无法直接使用电机控制 SDK 中的原始 DRV8320RS 驱动器。

zhengfeng zhang 说：

您可能需要参考 DRV8323文件以定义 DRV8320RS 的控制/状态寄存器，并同时定义 DRV8320RS 的句柄和对象

根据 C2000编译器警告、定义的 drv8323句柄无效。 对于 drv8320rs，上述 handle 的代码剪切与 drv823rs 的结构完全相同。 版本 UMCSDK 似乎存在这个问题、并且通过 SDK 4.0 HAL 重新定义了太多的宏。 奇怪的是、当鼠标 CTRL 跟踪这些针对监视窗口 motor1_drive.h 和 MOTOR_COMMON.h 定义的符号时、有循环 只需按 CTRL 键、任一函数中的名称、它们便会循环进入相反的*。h 文件中、且在代码路径中的任何位置都未定义监视窗口终点。

DRVIC_VARS_t drvicVars_M1；循环到 DRVICVARS_Handle drvVarsHandle；  

外部 DRVIC_VARS_t drvicVars_M1；

至于未来的电机控制代码、任一 MCU 的 HAL 应该适合于具有任何特定驱动程序 PCB 的项目编译、以避免代码混乱。 UMCSDK 可能是一个静态和独立的管理模块、在合理情况下可与较旧或较新的 MCU 类 HAL 运行。 SDK4.0具有单独的电机 IC 控制 PCB、并使编译代码保持简洁且易于遵循。  

从用户构建文件夹中删除了复制的 drv8320.c/h 文件、并替换为 c：\ti 下 UMCSDK 文件夹的导入链接、因此会产生无法调试到任何原因和影响的警告！ 必须为 PGA 和 DAC 的功能添加全局外部函数、这令人兴奋。 即使将 PGA/DAC driverlib 函数链接添加到(src_driver)文件夹之后、CCS 仍然编译了上面的两条警告。 调用 DRVIC_setGPIOENNumber 是如何隐式声明的？？？？？ 请注意、我还尝试让它以旧的方式工作、这导致了上面的帖子中显示的错误。

zhengfeng zhang 说：

请查看 hal_obj.h 中的定义 t

你难道不认为我在寻求帮助之前就这么做了吗？ motor1_drive.h 指针对象中存在冗余循环错误。 这也会导致上述 hal.c"隐式"编译警告。 在另一个更新监视窗口 SPI 参数的模块中似乎是全局外部。  

  //obj->drvVarsHandle =&drvicVars_m1；

您好、Yanming：

我的确使用了 MCSDK 来编译与 x49c 一起工作、但是添加 HID 成为一个停止点、est.h 没有 extern、所以很容易修复。 但是、motor1_drive.h 导出会导致使用 HID 命令模块编译工程时重新定义第一个定义的符号错误。

因此、返回到 is05在 PM 代码剪贴的 is07中运行、但它首先导致立即控制器错误、从而在 is07永久循环中运行电机 ID。 此修复在 main.c 底部附近添加了50µs μ s 延迟、其中控制器现在会从 MCSDK 更新并添加一些 user_mtr1.c 的部分。 仍希望在某个时候通过 HID 编译 UMCSDK。

感谢您的建议