[参考译文] LAUNCHXL-F280049C：轨迹过冲&放大器；SVPWM

INA240传感器输出是不连续(CH2)第二次捕捉、与 ePWM 调制驱动的 alpha/beta Vsense 输入不同步。 即使相电流通过电流钳位(第一次捕捉)看起来是连续的、但这并不表示扇区旋转通过 (MAIN_ISR) 328µs Instaspin ePWM 抽取计时与 CMPA 负载事件保持同步。

为什么 INA240具有与 ePWM 占空比同步的1/2波脉冲。 也许单个未绑定的 Clarke 变换会在快速估算器输入中导致 ADC 输入信号顺序冲突？

Lab7 90Hz VSI 2ms PWM 调制器与 LAB5 BoostXL-drv84320rs 150Hz PWM 调制：

在之前编译的32位 typedef 字位置上、输入数据结构中似乎存在格式争用。 症状(DCBus_V)存在于先前定义的结构位置、如下所示。 似乎是 C++代码分析工具遗漏的编码违反。 BusVoltage 数据存在于第一个 Globals typedef 格式化的数据位置中、当 Globals 格式化的数据字符串的 R/W 时、会出现32位字间隙。

填充或忽略进程中的轨迹数据、但会影响到目标的旋转计算速度中的轨迹。 也许我们不应该在现有的32位字上使用 typedef 部分(刻意选取)标记格式字符串、而不使用格式化 R/W 字符串中的符号名称/名称、并引用 typedef Globals 格式。  

看似 Clarke 会提取或甚至忽略某些数据、并将其发送给 FAST 估算器、随意选择。

我的投票代码2 Clarke 函数可保持电感电流(alpha/beta)和电压(alpha/beta)数据完全独立的 ADC 输入格式。

顶部的 LAB5和 Lab7全局名称使用相同的符号名称以两个 typedef 结构对未在全局名称/s 中进行格式化的变量进行排布   

HAL_ADCData_t adcData = {{0.0, 0.0, 0.0}, {0.0, 0.0, 0.0}, 0.0};

//! \brief Defines the estimator (EST) input data
//!
typedef struct _HAL_ADCData_t_
{
    MATH_Vec3 I_A;         //!< the current values
    MATH_Vec3 V_V;         //!< the voltage values
    float32_t dcBus_V;       //!< the dcBus value
    float32_t throttle;      //!< the throttle input
} HAL_ADCData_t;


EST_InputData_t estInputData = {0, {0.0, 0.0}, {0.0, 0.0}, 0.0, 0.0};

//! \brief Defines the estimator (EST) input data
//!
typedef struct _EST_InputData_
{
  int32_t    timeStamp;        //!< a time stamp for the input data buffer

  MATH_Vec2        Iab_A;            //!< the alpha/beta current values, A
  MATH_Vec2        Vab_V;            //!< the alpha/beta current values, V
  float32_t          dcBus_V;          //!< the DC bus voltage value, V
  float32_t          speed_ref_Hz;     //!< the speed reference value, Hz
  float32_t          speed_int_Hz;     //!< the speed int value, Hz
} EST_InputData_t;


//What data do you need ??
        //
        // store the input data into a buffer
        //
        estInputData.dcBus_V = adcData.dcBus_V;
        estInputData.speed_ref_Hz = motorVars.speedTraj_Hz;
        estInputData.speed_int_Hz = motorVars.speedTraj_Hz;

尽管 DCBus_V 是 Clarke 块下方的快速输入、但 EST_inputDATA_t estInputData ting 布局中未包含上述代码 DCBus_V 中的点。 typedef 代码对于如何将 adcData.dcBusV 临时保存到 estInputData 格式的非现有位置存在疑问。 还询问在使用 ADC PGA_of 输入并通过模拟子模块省略 PGA 输出时、如何交叉连接 Clarke 的 Vsense 输入(A、C、B)。  

        //
        // store the input data into a buffer
        //
        estInputData.dcBus_V = adcData.dcBus_V;

很难跟进您的问题。 如果您有与主题标题不同的问题、请创建新主题吗？

但这是同一个主题、我注意到今天 A 相 电流具有纯粹的角度特征、完全不是通过电流钳位实现的正弦波形状。 将格式字符串中的某项内容输入 Clarke 是不正确的、并且 BoostXL 已将输入(J7) VsenseB、VsenseC 交叉输入 Clarke。 因此、LAB5电机 ID 会在重转子负载60Hz 跳变 DAC 过电流时通过 BoostXL-drv8320rs 停止。  

lab05-07顶部的两个格式字符串似乎具有重叠的 ADC 数据、对两个 Clarke 调用使用相同的函数调用、即数据发送到 FAST 估算器。  格式化的数据不容易跟随或通过 ADC 模拟输入确定输入数据串的顺序一致。  

Clarke 需要如图所示将单独的输入块集成到 FAST 估算器中、而不使用相同的函数。 特别是由于没有关于 Clarke 块主题的文档、因此无法通过混淆多种类型的 def 结构共享 ADC 通道数据。 在这部分 Clarke alpha/beta 代码中、似乎有一些内容交叉链接、并降低了整个电路板的性能。 请注意、上面捕获的是正弦电流(VSI)与(BoostXL)、证明了 Clarke 的 ADC 输入比 SDK 通过 Vsense B 反转 Vsense C 生成的更好 这是如何难以理解的？

上述捕获结果将 BoostXL 与针对 Clarke Vsense 和 Isense 通道使用适当 ADC 输入顺序的典型 VSI/VSC 进行比较。 PWM 调制不能与 Clarke 输入保持一致、并且在两个示例中、同步都很糟糕角度倾斜。 为什么 ADC 输入的顺序在格式数据串中不一致？   

Clarke.h 变换(感应矢量)具有较小的 GPIO 位置输入问题。 Clarke 变换也不使用典型的╥角度来计算转子位置 alpha/beta、原因是什么？ 随着 Vsense 速度增加到 Pi 块转子崩溃、相电流不会与落在后面的磁通量(滑动)保持同步。

同样、切换 Vsense B、Vsense C GPIO 输入位置(J7)是 BoostXL LAB5电机 Id 额定磁通会立即跳变 ePWM DAC 故障的一部分。 很显然、我们无法更改硬件、但 GPIO 输入需要(A、C、B)顺序才能使 BoostXL 产生正确的 PWM 调制。 上述布置的左侧(VSI)示波器捕获显示(右侧)正弦电流的形状不正确。 BoostXL-drv8320rs 相电流不应具有 Vsense 特征值。 许多人已经发布了类似的电流捕获 SDK 2.01出现在定制 PCB 中、即使放弃整个项目、也会出现最热门的速度问题。

这一点我曾多次强调、对于 Clarke 输入 Vsense Order 被反转 SDK 的原因、冷反转。 typedef alpha/beta 格式字符串输入 FAST 估算器的数据重叠，输入字符串数据位置(Isense / Vsense)在 Clarke_Run ()变换内部收敛。

能否将 Clarke 变换典型数学(以下)与 α β 的 FAST 估算器角度发生器进行比较？ 计算是否误掉了？ 随着 Vsense 频率的增加、Isense 开始振荡并使转子磁通崩溃、所报告的 Clarke 数据收敛问题会在轨迹数据中产生过冲。

    /* Calculate pIalpha using the equation, pIalpha = Ia */
    *pIalpha = Ia;

    /* Calculate pIbeta using the equation,
     * 	pIbeta = (1/sqrt(3)) * Ia + (2/sqrt(3)) * Ib + (3/sqrt(3)) * Ic  */
    *pIbeta = (((((float32_t) 0.57735026919) * Ia) +
    		     ((float32_t) 1.15470053838) * Ib) +
			     ((float32_t) 1.73205080757) * Ic);

为什么没有文档披露(IA/IB、VA/Vb)输入的快速 FOC 输入、Clarke 变换要求？  VSI 启动和运行频率高达95Hz (如下所示)所需的 Clarke 变换感应输入顺序。 反转等式阶数不会改变 A 相三角波形。 通过电流钳位实现的 B 相和 C 相看起来很正弦。

与 DSPWM1/2、最小值/最大值和钳制一个高直流或低直流桥臂相比、任何人都可能认为 Clarke alpha/beta 输入符合旧版 CSSVM 旋转算法的行业标准。

上面的 INA240捕获(右上角) CH2 显示确实发生了170ms 的不连续帧。 我不认为170ms 的无效值是 CH2上的示波器混叠、而是强调了不连续算法、CMPA 占空比变化。 另请注意、当 VSI 上的 Vsense 阶数(A、C、B)捕获(左侧)时、PWM 驱动 CH1在相同的2ms 水平扫描时间内的不连续性更少。  

// hal.c
#ifdef INA240A1
    // ISENB - PGA4_OF ADCC8->RC0 INA240(J5-46)/RC-filter
    ADC_setupSOC(obj->adcHandle[1], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);

    // ISENC - PGA6_OF ADCA8->RA0  J3-24(B0)INA240(J5-45)/RC-filter
    ADC_setupSOC(obj->adcHandle[0], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);

    // ISENA - PGA2_OF ADCB8->RB0 INA240(J5-48)/RC-filter
    ADC_setupSOC(obj->adcHandle[2], ADC_SOC_NUMBER0, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN8, HAL_ADC_PGAxABC_SAMPLE_WINDOW);
#endif
    // VSENA - A6->RA1    J7-63
    ADC_setupSOC(obj->adcHandle[0], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN6, HAL_ADC_SAMPLE_WINDOW);

    // VSENC - B6/A2->RB1 J7-64
    ADC_setupSOC(obj->adcHandle[1], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN6, HAL_ADC_SAMPLE_WINDOW);

    // VSENB - C14->RC1   J7-65
    ADC_setupSOC(obj->adcHandle[2], ADC_SOC_NUMBER1, ADC_TRIGGER_EPWM1_SOCA,
                 ADC_CH_ADCIN14, HAL_ADC_SAMPLE_WINDOW);
            
                 
// hal.h

#if (BOOST_to_LPD == BOOSTX_to_J5_J6)
    // convert phase B current       PGA4_OF->ADCC8->RC0
    value = (float32_t)ADC_readResult(obj->adcResult[1], ADC_SOC_NUMBER0);
    pADCData->I_A.value[0] = value * current_sf;

    // convert phase C current       PGA6_OF->ADCA8->RA0
    value = (float32_t)ADC_readResult(obj->adcResult[0], ADC_SOC_NUMBER0);
    pADCData->I_A.value[1] = value * current_sf;

    // convert phase A current       PGA2_OF->ADCB8->RB0
    value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER0);
    pADCData->I_A.value[2] = value * current_sf;

    // convert phase A voltage        ->RA1/A6
    value = (float32_t)ADC_readResult(obj->adcResult[0], ADC_SOC_NUMBER1);
    pADCData->V_V.value[0] = value * voltage_sf;

    // convert phase C voltage        ->RB1/B6
    value = (float32_t)ADC_readResult(obj->adcResult[1], ADC_SOC_NUMBER1);
    pADCData->V_V.value[1] = value * voltage_sf;

    // convert phase B voltage        ->RC1/C14
    value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER1);
    pADCData->V_V.value[2] = value * voltage_sf;

    // convert dcBus voltage          ->RC2/C1
    value = (float32_t)ADC_readResult(obj->adcResult[2], ADC_SOC_NUMBER2);
    pADCData->dcBus_V = value * voltage_sf;
#endif

您希望在此主题中解决哪些问题？ 电机识别必须 无负载运行。

在这个主题帖或您发布的其他主题帖中回复您。 我们希望确保您设计的硬件板首先适合电机驱动。 我认为您上面提到的这些内容与 instaspin foc, instaspin foc/fast 对于大多数通用电机应该是可以的.  

您能否创建一些新主题以发布您的问题？ 我们很难关注和理解您在本主题中的问题。

继续思考、也许会有这样的路。

这一点已经很好地证明它没有被加载。 然而、Vsense (B、C) ADC 输入仍然是交叉的 BoostXL-drv8320rs SDK 代码。 还说明了 LAB5 ID 如何烧断 Nidec 电机绕组极小的输入电流振动会剧烈振动电机。 当连接到 launchXL 的外部 VSI 拒绝启动更大的电机时、就会变得很明显。 更改 ADC 输入顺序 Vsense (C、B)、然后 LAB5完成 ID、而不会剧烈振动电机、这仅证明了在到 Clarke 的 BoostXL ADC 输入中存在不正确的情况。

那么、您拒绝 回答有关卡克变换的问题吗？ 据说是开放源码、但遗漏了所有文档或注释、这对社区健康而言并不是一个好兆头。 同样、Clarke 调用和格式的 SDK 代码不遵循定义的块布局、即 SPRUHJ1H–2013年1月–2019年6月修订版和其他实验室指南、其中显示了 FAST 估算器的两个不同输入块的图。

假设用于参数、则指令解码时序闪存存储器等待状态显示为上面不连续电流中所述的1/2波脉冲。 如果没有清晰的文档来快速处理 Clarke 输入、有人会如何解决此问题？ 当电流振荡时、磁链会变得不稳定。 随着速度 PI 控制变得不稳定 Lab7、快速角度估算会作为磁链中的函数发生变化。 注意到另一个后相位 A 波具有角度形状、似乎是 Clarke 处理 Isense 和 Vsense、这是一个疑似原因。

我用很多次的时间用详细的文档格式来阐述问题、但您仍然拒绝理解 SDK、因为有一些设计错误需要注意。 或许让您的主管留出更多的实验时间来检查报告的奇怪问题、不仅是我报告的问题、而且还有其他一些海报。 同样、相电流(A、B、C)不应具有梯形调制、BoostXL 也会产生上述捕捉。 该电流应主要是正弦、具有非常小的甚至任何梯形调制模式。 请注意、我的 VSI 电流捕获优于 BoostXL、VSI 肯定符合 DPWM Mi 0.7索引鉴定标准。 眼见为实。

如果您使用的是 TI EVM 套件、则 ADC 配置应适用于克拉克输入的电流和电压感应。 如果您使用自己的电路板、则必须相应地更改 ADC 配置、或者将其他逆变器连接到 TI 套件。

我想对于 motorControlSDK 中的克拉克变换函数没有任何问题、它只是典型的 FOC 函数。 输入是 a/b/c 帧上的三相电流或电压、输出是 alpha/Beta 帧上的电流/电压值。

我认为电机 controlSDK 中没有您提到的明显设计错误。 可能、instaspin focs 无法在某些电机上正常运行、例如 IPM 电机低速运行、或者低电感电机高速运行、这需要在示例实验中进行微调。  您可以查看一些有关 FOC 技术的教科书、这些教科书可以展示采用正弦 FOC 的 PMSM 驱动与采用梯形控制的 BLDC 驱动之间的区别。  

同样重要的是、DRV8320rs 配置已经反转了 Vsense B 和 Vsense C、从而严重损坏了几个经过测试的电机的电机 ID！  

这是一个观点、SDK Clarke 变换似乎是为快速估算器 α β 输入定制的。 上面显示了典型的 Clarke 变换发现的成熟的 ARM CMSIS 代码、为什么忽略？ 请注意、CMSIS 与 SDK 中提供的 Clarke 变换差别很大、原因是什么？

还是有关 Clarke 传输方法的 TI 文档、以证明 LD/LQ 间距 α/β 波的正确性？ TI 将两个 Clarke 块组合到最后一个调用并将 I/V 函数分离为两个调用的推理或理论？ 其他供应商不使用与 TI 用于 Clarke 变换的方法相同的方法、这是一种范围。 SVM 电机控制系统的其他供应商只有一个 Clarke 块、而不是两个。

这一点已经过充分的记录、SDK FOC 无法满足许多标准。 继续接受 SDK 生成的波形波形波形波形也不会赢得诺贝尔奖。 同样、也有直流脉冲注入交流电流、任何地方都不接受该文本簿。 C2000应该是卓越的、但会受到多个 SDK 代码点的阻碍。 如 TRM 中所述、一个省略主从同步时序的 ePWM 配置可保持 SW 旋转矢量的适当 LD/LQ 帧间隔。 始终尝试改进 DSP 的 PWM 控制、这是 Beast 的核心！

但是、SDK 尝试使用相同的转换公式来计算相对于 DPWM1/ DPWMIMn 的快速角度。 SDK 实验方法应中止 FWC、可能会留下 MTPA、坚持基础知识并在没有 PI 振荡的情况下形成干净的正弦波形。  

例如、Lab07示例的惯性 BW 增量计算是经过爪卡处理的、导致大转子(>1Kg2)达到最大速度、而不会使轨迹/电流节拍计数崩溃。 最后立即测试极高积分(KI_SPD)、您知道 PI 的速度为140Hz、但电 感大于 BoostXL ID 所找到的 ld/LQ。 现在，通过激光目标，电机实现了几乎相同的6步梯形速度(190Hz)，实际为135Hz 435rpm 。 PI 积分被设置得非常严格的 Lab7、而惯性算法(labs.h)只是一个最佳猜测、但却是非常错误的。 我发布的 labs.h 更改代码对于大于0.3 Kgm2的重转子质量用户输入惯性似乎很好。 特斯拉、福特或 GM 也可能使用 x49c MCU 来驱动这些重转子负载。   

可改进 Clarke 和 ADC 输入滤波器旋转算法、从而在没有 FWC 的情况下最大限度地提高转子速度。 尝试在零计数或周期时采用影子 CMPA 加载似乎同样好、请在 CMPA 加载之前检查影子满标志。 点是所有相位上的正弦波形应该是一致的并且没有 ADC Vsense 锁定显示在驱动电流的3次谐波之上。 C2000实现了 GDPWM 更高效率和更低 THD 的承诺。

//
// Added My motors inertia value user.h
//
#if(USER_MOTOR_INERTIA_EN)
    	/* Lab7 determined BW required for Kp_spd/Ki_spd */
        pUserParams->BWc_rps = MATH_TWO_PI * (float32_t)150.0; //Filter pole: rads/sec
        pUserParams->BWdelta = (float32_t)38.0; //55.98

#endif

// Arm CMSIS Clarke transform was current related:


  /**
   *
   * @brief  Floating-point Clarke transform
   * @param[in]  Ia       input three-phase coordinate <code>a</code>
   * @param[in]  Ib       input three-phase coordinate <code>b</code>
   * @param[in]  Ic       input three-phase coordinate <code>b</code>
   * @param[out] pIalpha  points to output two-phase orthogonal vector axis alpha
   * @param[out] pIbeta   points to output two-phase orthogonal vector axis beta
   * @return        none
   */
  __STATIC_FORCEINLINE void arm_clarke_f32(
  float32_t Ia,
  float32_t Ib,
  float32_t Ic,
  float32_t * pIalpha,
  float32_t * pIbeta)
  {
    /* Calculate pIalpha using the equation, pIalpha = Ia */
    *pIalpha = Ia;

    /* Calculate pIbeta using the equation,
     * 	pIbeta = (1/sqrt(3)) * Ia + (2/sqrt(3)) * Ib + (3/sqrt(3)) * Ic  */
    *pIbeta = (((((float32_t) 0.57735026919) * Ia) +
    		     ((float32_t) 1.15470053838) * Ib) +
			     ((float32_t) 1.73205080757) * Ic);
  }

速度和电流 PI/PID 稳压器的增益均根据电机参数计算得出、仅供通用电机参考、最好根据实际系统调整这些参数。

您提到的 Clark 应该是相同的、因为三相电机中的 IA+IB+IC=0。

VBus_SF 小数点被右移1位、使2.06 SF 变为20.6xxxx。 奇怪的是、α β 是较小的值、但 Clarke 的 ADC Vsense 输入会缩放非常高的输入值。 V_V-SF 小数点是 CCS 调试问题吗？ 奇怪的负 Vsense 实际上是正值(实时)调试观察表达式。 ADC100.0V 值是否与 Clarke 一样高、角度计算的最大输入值是多少？

Kgm^2算法(labs.h)同样不适用于大多数大于1Kg 转子密度的用户电机！ 用于查找 PI series_ki/KP 值的 Lab07公式 不 能正常工作(如果完全如此)。 默认情况下、将 PI 比例保持在较高的水平、从而在峰值加速过程中使电机磁通崩溃并使电机失速。

PI 系统 kgm^2编码(labs.h)似乎只能与虚构的或非常小的惯性值一起工作、需要更新。  kgm^2算法(user.c)不得与添加的用户电机惯性值(user.h)一起使用、BWdelta (默认值)是刚性紧密碰撞磁通。 最好将 user.c 设置为 BWC_rps/BWDelta 默认/用户条目的两个选择定义。 查看 SDK v3.01上述相同的 kgm^2惯性问题退出了 SDK v2.01。 我们都不知道是什么导致了电机磁通崩溃  

由于 PGA 或 INA240的输出分别以+1.65v 和零星=2048计数为中心、因此不需要电流(双极)偏移。 似乎通道偏移应该为(<1V)减去结果、而不是(IA_OFFSET_A/B/C)。 但是、Vsence SF 偏移我指的过高。 与20.54相比、将 VSF 更改为静态值(2.054)没有任何影响。 Clarke 似乎未按预期处理 Vdq 信号。  

也许您应该在前面提到 Clarke 变换时分享、以某种方式逆转为 BoostXL-drv8320rs 记录的 Vsense 通道。

我很抱歉给您带来不便、但希望电机运行与6步梯形 PI 控制换向相似的过程不会带来太多麻烦。 您仍然没有提供有关 FAST 估算器 alpha/beta 输入预期值的文档。

为什么很难围绕 ROM 嵌入式快速控制块的边缘进行公开披露？ SDK FOC 最低要求文档 要求用户 做出假设。 然而、SDK FOC 方法与其他供应商在相同市场份额中披露的方法有很大不同。 花了几个星期的时间来尝试驯服这只老虎，也许有点聪明，尽管一路上只拍了几次脚 。

感谢您的帮助、PI 系列控制数学(实验室指南)充其量也是奇怪的。 与之前的 PI 控制(比例、积分)相比、产生的下冲/过冲速度更低、并且从不会将占空比完全崩溃到加速轨迹中。 也许应该归咎于 Vsense SF。  

我可以解释从读取结果中减去电流偏移或 ADC 2048或虚0v 的逻辑。 尽管对于 Vsense 输入、如果通道电压偏移>0V (浮点数)、浮点值顶部将变为新阈值(虚0v)、然后将偏移量添加到读取结果中。 减去偏移量将从读取结果中删除虚部0V、从而产生比实际采样的通道悬空值更小的值。 通过这种方式、电流角度也更加稳定。

快速通道输入规格不是专有披露、而是强制要求。 任何工程师都不会对 涉及逻辑的神秘表示疑惑。